De letterlijke vertaling van het Engelse woord Ingress is toegang. Binnen de wereld van containers (en dan specifiek Kubernetes) regelt dit API-object externe toegang tot services in het Kubernetes cluster. Ingress is daarbij de laag tussen die services en het externe netwerk (zoals Internet). Maar Ingress is ook op andere manieren te gebruiken: als load balancer bijvoorbeeld, of voor de terminatie van SSL-verkeer.
Om Ingress te laten werken in Kubernetes is een aparte Ingress controller (een reverse proxy) nodig, die in een eigen pod draait. De controller bevat verkeersregels en een daemon om die regels uit te voeren. Daarmee is het een relatief eenvoudige, ingebouwde variant waarmee een load balancer beschikbaar is. Services in het Kubernetes cluster zijn zo via subdomein (subdomain.foo.com) of pad (foo.com/bar) toegankelijk.
Er zijn verschillende soorten externe Ingress controllers, zoals bijvoorbeeld vermeld in de documentatie van Kubernetes. De daar genoemde producten zijn die van F5, Kong, GCE en NGINX. Vooral NGINX wordt veel gebruikt als (eenvoudige) Ingress controller.
En eigenlijk is Ingress niet de enige manier om toegang te krijgen: het is ook mogelijk om met servicetype NodePort een specifieke poort aan te wijzen (of door Kubernetes aan te laten wijzen als het veld nodePort in de yaml-configuratie leeg is) waardoor een service met de buitenwereld kan praten. Dat heeft als nadeel dat het nodig is ergens bij te houden welke poort voor welke service wordt gebruikt, op welke omgeving. Eén service per poort maximaal en dan ook nog in de range tussen 30000 en 32767. Niet ideaal.
Daarnaast wordt met servicetype LoadBalancer een Cloud-gebaseerde load balancer aangemaakt, maar alleen in een public cloud als Amazon of Google. Iedere service die met een load balancer wordt geopend naar de buitenwereld krijgt zijn eigen IP-adres. Bij veel verschillende services is het daarom belangrijk de kosten in de gaten te houden. Het is overigens ook mogelijk een lokale load balancer te gebruiken in combinatie met servicetype LoadBalancer, bijvoorbeeld met MetalLB.
In dit artikel drie controllers die niet in de documentatie van Kubernetes voorkomen: Istio, Contour en Traefik. Istio en Contour maken gebruik van de Envoy proxy van Lyft, waarmee de afzonderlijke microservices in de pods bestuurd worden. Misschien is het vergelijk tussen Istio en de andere twee niet helemaal fair, want Istio is veel meer dan een (edge) proxy. Istio is echter wel zo te configureren dat het als Ingress controller dient en tot die functionaliteit beperkt dit artikel zich.
Het open source product Istio van Google, IBM en Lyft is relatief nieuw: het is in mei 2017 aangekondigd. Het is veel meer dan een Ingress controller, namelijk een platform voor het beheer (en beveiligen) van microservices. Onderdeel daarvan is routing en (layer 7) load balancing.
Istio wordt gebruikt voor het beheer van services in een zogenaamd service mesh, een term uit de wereld van microservices waarmee een transparant, overkoepelend (maar geen overlay) netwerk wordt aangeduid dat communicatie (registry en discovery) tussen microservices mogelijk maakt. Het mesh draagt zorg voor het afleveren van berichten tussen microservices, waarbij het mesh onder andere rekening houdt met fouten (microservices of de containers waarin deze draaien zijn er immers niet altijd). Een mesh en de software die het mesh bestuurt zijn complexe systemen. De werking daarvan is iets voor een volgend artikel.
Het is mogelijk de functionaliteit van Istio verder uit te breiden met Ambassador, een API-gateway waarmee bijvoorbeeld authenticatie op microservices mogelijk wordt.
Het open source product Contour (ook uit 2017) van Heptio (opgericht door twee voormalige medewerkers van Google die aan de basis van Kubernetes stonden) is een eenvoudige, lichtgewicht Ingress controller voor Kubernetes. Contour is daarmee niet te gebruiken als load balancer en ook niet bedoeld als concurrentie voor Istio.
In de huidige vorm biedt Contour nog relatief beperkte functionaliteit. De vergelijking met bijvoorbeeld NGINX of HaProxy wordt vaak gemaakt. Het verschil zit op dit moment vooral in het gebruik van Envoy als proxy.
Traefik (en ook dit is uit 2017) is een reverse proxy en load balancer. In tegenstelling tot Istio en Contour is Traefik niet specifiek voor Kubernetes ontwikkeld en ondersteunt bijvoorbeeld ook Docker Swarm en Mesos. Traefik gebruikt de concepten frontend (een set aan regels die bepaalt hoe inkomend verkeer wordt gerouteerd naar een backend) en backend (de te ontsluiten microservice). Een voordeel van Traefik is dat het tool dynamisch is – alle Docker containers die voorzien zijn van een specifiek Traefik-label zijn bijvoorbeeld automatisch ontsloten. Bij Kubernetes is het voldoende om (per service) een Ingress-rule aan te maken, die Traefik dan automatisch oppikt en uitvoert.
Niels Goossens