In de wat meer traditionelere hostingplatformen heb je een proxy server zoals bijvoorbeeld Haproxy of Nginx. De configuratie daarvan gebeurt in het gunstigste geval met behulp van configuratie management systemen als Puppet of Ansible. In andere gevallen wordt er gebruik gemaakt van een appliance. Hoe het ook gebeurt, het is meestal een statisch verhaal. Een verhaal dat niet goed aansluit bij de dynamische wereld van Kubernetes waarin je vaak niet weet hoeveel containers er schuil gaan achter achter die ene URL. Binnen Kubernetes is daar een oplossing voor: Ingress. Deze oplossing past zich automatisch aan naar de wijzigingen op het platform en de configuratie kan uitbesteed worden aan iemand met de juiste rechten op de Kubernetes API.
Concepten van Ingress
Ingress bestaat uit de zogenaamde Ingress controller en Ingress Resources. De controller is de te gebruiken proxy software. De resources zijn de proxy configuraties die via de Kubernetes API te configureren zijn. Dat deze twee zaken van elkaar ontkoppeld zijn past helemaal binnen de filosofie van Kubernetes. De proxy configuratie kan op een Kubernetes standaard manier geconfigureerd worden. Via specifieke “annotations” in je yaml definities kunnen configuraties gemaakt worden die specifiek werken op een specifieke ingress controller.
Zie hieronder een screenshot van hoe zo’n ingress resource er uit ziet. Je ziet de “annotations” waarmee de Traefik specifieke configuratie gemaakt kan worden. Daarnaast is te zien hoe de private key en het certificaat uit een Kubernetes gebruikt kunnen worden.
Ook geheel in stijl van Kubernetes, heb je vrijheid in de keuze van de Ingress controller. Verschillende vendoren van proxy software hebben hun applicatie dan ook geschikt gemaakt Voor Kubernetes. De grootste wijziging in de software is dan dat de software via een Kubernetes serviceaccount in staat moet zijn om Ingress resources uit te lezen en vervolgens te configureren. Daarnaast is er ook nog de mogelijkheid om de proxy software niet als container te draaien maar het uit te besteden aan een appliance zoals bijvoorbeeld de BIG-IP van F5 Networks.
Vrijheid
Verschillende proxy systemen zijn beschikbaar gesteld als Ingress controller. Hier wordt het dan ook lastig. Wat kies je? Haproxy is beschikbaar als ingress controller maar juist de kubernetes koppeling wordt weer niet door de makers van Haproxy zelf gebouwd. Het werkt overigens goed maar het voelt alsof de functionaliteit er later ingebouwd is. Bij Nginx zie je daarnaast dat er zowel een community initiatief is als de versie van nginx.com zelf. Om de keuzestress nog wat verder te vergroten zijn er naast Nginx en Haproxy nog meer mogelijkheden. Denk bijvoorbeeld aan Traefik. Deze relatief nieuwe speler heeft native support voor Kubernetes en kan “out of the box” al goed geïntegreerd worden met bijvoorbeeld Jaeger (zie een van mijn vorige items: https://denit.nl/media/technische-blogs/tracing-met-jaeger/ ) Bij het zien van zo’n nieuw Proxy pakket krijg je gemengde gevoelens. Nginx en Haproxy hebben jaren lang uitstekend werk geleverd. Hoe verstandig is het om je oude vertrouwde gereedschap in te ruilen voor het ogenschijnlijk hippere alternatief? En maakt het überhaupt nog wat uit als je voor de configuratie generieke Ingress rules met wat specifieke annotations kan maken? Zelf heb ik inmiddels gezien dat bijvoorbeeld Traefik een goed alternatief is gebleken. De standaard beschikbare integratie met Kubernetes, gecombineerd met de makkelijke koppeling aan jaeger hebben mijn interesse gewekt en tot nu toe ben ik nog zeker niet teleurgesteld.
Bereikbaarheid van buitenaf
De eerder besproken proxy alternatieven worden bijvoorbeeld als Daemonset geïnstalleerd. Dat is leuk voor je bereikbaarheid en het verdelen van load maar aan de buitenkant wil je 1 ip adres waarop je applicatie/website bereikbaar moet zijn. Bovenstaande software heeft hier nog geen oplossing voor! Het alternatief is dat je bijvoorbeeld kiest voor de BIG-IP van F5 Networks. De Ingress controller wordt dan uitbesteed aan een appliance die gelijk een publiek IP kan bevatten. Je kan de BIG-IP onderdeel laten worden van je Flannel vxlan overlay netwerk zodat het naadloos integreert met je cluster en direct met achterliggende pods kan praten. met Ingress resources kan de BIG-IP voorzien worden van een basisconfiguratie en verdere zaken zijn altijd nog in te stellen via de web interface of de advanced (tmsh) shell. Zo’n BIG-IP heeft natuurlijk een kostenplaatje. Er zijn ook Open source alternatieven die misschien wel exact doen wat je nodig hebt. Hieronder staan een paar voorbeelden:
TCP Loadbalancing
Alternatief 1 is bijvoorbeeld een Loadbalancer die op laag 4 zonder SSL offloading of slimme technieken op de laag 7 ingezet wordt en de verzoeken verdeelt over de nodes op de nodePort waarop de proxy software HTTP/HTTPS aanbiedt.
BGP routering
Met de netwerkplugin Calico is het mogelijk om pod ip’s via BGP te routeren en sinds Calico release 3.4 geldt dat ook voor de kubernetes service IP’s. Op deze manier kunnen requests eenvoudig vanaf een router je cluster in gerouteerd worden.
Tot slot
Clouds als Amazon bieden je vaak de mogelijkheid om gebruik te maken van hun Loadbalancer as a service oplossing. Je hoeft je dan binnen Kubernetes niet druk te maken over dit vraagstuk. Voor de “on premise” clusters zijn er gelukkig genoeg mogelijkheden om het zelfde of misschien wel meer te bieden. Het begint bij een goed design. Niet elke netwerkplugin ondersteunt VXLAN of BGP en soms is een budget niet toereikend genoeg voor het inzetten van een F5. In eigenlijk alle gevallen is er wel een mooie oplossing te vinden die aansluit op de wensen. Het mooie is dat zowel closed als open source technologieën je hierbij kunnen helpen.
Auteur: Geurt Hakfoort – Cloud Specialist Denit
