Mastering Azure Kubernetes Services deel 3: AKS Netwerk

AKS Netwerk

Op netwerkgebied zijn er voor AKS belangrijke architectuurkeuzes te maken. Veel hangt ook af van het azure landschap waarin een AKS cluster ‘landt’. Wanneer er gebruik gemaakt wordt van de Azure enterprise scale landing-zone architectuur zullen de nodepools van het AKS cluster in een spoke netwerk landen en via een hub netwerk communiceren met het internet en een on-premise omgeving.

Netwerk model

AKS kent drie netwerk modellen om uit kiezen, Kubenet, Azure Container Networking Interface (CNI) en Azure CNI Overlay. In elk model krijgt elke node een IP adres van een ‘eigen’ VNet of een managed VNet. Met Kubenet krijgen pods een IP adres uit een andere adresruimte (CIDR) onafhankelijk van het subnet van de nodes. Deze CIDR kan dus voor elk AKS cluster gebruikt worden. Door middel van een managed route table, gelinkt aan het subnet waar de nodes zich in bevinden, met routes naar pods via nodes, wordt intern AKS verkeer (pod naar pod op verschillende nodes) mogelijk gemaakt. Voordeel van kubenet is een makkelijkere IP planning, nadeel is de extra hop voor verkeer tussen pods op verschillende nodes.

Met Azure Container Networking Interface (CNI) krijgt elke pod een IP adres uit het subnet van de nodes en zijn daarmee direct benaderbaar binnen een AKS cluster. Elke node heeft een configuratie parameter voor het maximale aantal pods wat de node kan hosten en configureert daarvoor dit aantal IP adressen op de virtuele netwerk interface van de node. Deze methode vereist een zorgvuldige IP planning, wat lastig kan zijn wanneer vooraf niet duidelijk is hoeveel workloads gaan landen op het cluster.

Azure CNI Overlay werkt net als bij Kubenet met een aparte adresruimte voor de pods. Elke node krijgt een /24 adresruimte van dezelfde CIDR gecreëerd bij het aanmaken van het cluster. Met een apart routing domein in de Azure netwerk stack voor de private CIDR ruimte van de pods, wordt een overlay netwerk gecreëerd.

Tegenwoordig heeft CNI (Overlay) de voorkeur boven Kubenet in verband met de betere performance van Azure CNI (Overlay) en de beperkingen bij het gebruik van Kubenet. Kubenet ondersteunt bijvoorbeeld geen node pools voor windows containers en geen Azure Network Policy Manager (zie Pods en services verkeer).

De keuze tussen CNI en CNI overlay is lastiger te maken. In grote omgevingen met veel pods en vooral veel communicatie tussen de pods in het cluster heeft CNI overlay de voorkeur. Kleinere omgevingen kunnen vaak prima uit de voeten met CNI zonder overlay. Nieuwe AKS features komen vaak eerst beschikbaar voor CNI en later pas (of helemaal niet, bijvoorbeeld application gateway ingress controller) voor CNI overlay.

AKS verkeersstromen

AKS clusters kennen verschillende soorten netwerk verkeersstromen. Kubernetes-georiënteerd verkeer tussen de control plane en de workernodes, applicatie georiënteerd verkeer van buiten naar binnen het cluster aanwezige services, verkeer tussen services binnen het cluster en verkeer tussen pods onderling.

Pod en services verkeer

Communicatie tussen pods van verschillende services binnen het cluster gebeurt zowel voor Kubenet als Azure CNI via het statische CLUSTER-IP adres uit een kubernetes service CIDR van een service. Op de node draait kube-proxy om het verkeer met round robin vanuit het CLUSTER-IP te “proxyen” naar een pod. Het CLUSTER-IP is alleen beschikbaar binnen het cluster. Via een Azure load balancer met als backend pool, alle worker nodes, komt een service vervolgens beschikbaar buiten het cluster. (Zie figuur 1)

Figuur 1: Pod-service communicatie

Zowel bij een Kubenet netwerkmodel als CNI netwerkmodel krijgen alle pods in een kubernetes cluster een ip-adres uit één CIDR ruimte. Dit betekent dat alle pods, ook van verschillende namespaces ip technisch met elkaar kunnen communiceren. Met de kubernetes netwerk policy specificatie kun je regels maken voor het versturen en ontvangen van verkeer en deze vervolgens koppelen aan een collectie van pods die één of meerder gelijke “labels” hebben.

AKS ondersteunt twee netwerk policy opties, Azure Network Policy Manager (Azure’s eigen implementatie) en Calico Network Policy een open-source oplossing van Tigera. De te gebruiken methode configureer je bij het aanmaken van een AKS cluster en kan achteraf niet gewijzigd worden!

Calico Network Policy biedt een rijkere set aan mogelijkheden zoals prioriteren van rules, deny rules, en meer flexibele ‘match’ rules. Verder kunnen dit type policies niet alleen aan pods maar ook aan VMs en host interfaces toegekend worden.

Kubernetes verkeersstromen

Verkeer van de cluster nodes naar de control plane bestaat uit een TLS verbinding vanuit het IP-adres van de node, via de Azure load balancer naar de API-server in de control plane. Pods die willen communiceren met de control plane gebruiken de kubernetes service in de default namespace en via de kube-proxy op de node wordt het verkeer omgeleid naar het https endpoint (API-server). (Zie figuur 2)

Figuur 2: Node/pod naar control plane verkeer

De communicatie tussen de control plane en het cluster werkt via een secure tunnel, opgezet vanuit de ‘konnectivity agents’ (pods in kube-system namespace) naar een ‘konnectivity server’ in de control plane. Over deze connectie wordt een reverse tunnel van de control plane naar de nodes aangemaakt waar vervolgens al het verkeer van de control plane naar de nodes, services en pods doorheen gaat. (zie figuur 3)

Figuur 3: Secure tunnel tussen AKS control plane en worker nodes

De kubernetes konnectivity service vervangt de voorheen gebruikte  tunnelfront (free TIER) of tunnel-link (standard TIER) componenten.

Speciale aandacht verdient de netwerk toegang tot de control plane, die de kubernetes core componenten bevat en gebruikt wordt door een kubernetes beheerder, devops teams en release pipelines voor het uitrollen van applicaties. Standaard is de control plane (API endpoint) publiek benaderbaar (public cluster). In geval van een hub en spoke netwerk, waar al het outbound verkeer via een centrale firewall loopt, moet op de centrale firewall toegang verleend worden aan de AKS nodes naar de control plane. (zie figuur 4)

Figuur 4: Public cluster

Toegang tot de control plane vanuit het AKS cluster betreft een behoorlijk aantal firewall rules. Voor Azure firewall kan naast de benodigde netwerk rules, de application rule met  fqdn-tag ‘AzureKubernetesService’ gebruikt worden.

Voor het afschermen van het AKS control plane endpoint bestaan er, naast het whitelisten van specifieke publieke IP adressen, mogelijkheden om het endpoint deels of geheel af te schermen van het internet door een zogenaamd ‘private’ cluster uit te rollen. Met een private cluster communiceren de node pools en de API-server via een private link service in het API-server virtuele netwerk en een  private endpoint gepubliceerd in het subnet van het AKS cluster. Ook hier wordt een secure tunnel opgezet zoals bij een public cluster, maar gaat het verkeer over het Microsoft backbone netwerk en niet via het publieke internet. (zie figuur 5)

Figuur 5: Private cluster

Bij een private cluster heeft de control plane dus geen publiek benaderbaar endpoint. Dit betekent dat ook AKS beheerders en developers alleen via het private endpoint met het kubernetes API endpoint kunnen communiceren, met als gevolg dat voor pipelines self hosted agents nodig zijn. Verder is het whitelisten van IPs niet mogelijk met een private cluster en kan een public cluster niet omgezet worden naar een private cluster. Bezint eer ge begint!

Dan bestaat er nog een derde mogelijkheid, een AKS cluster met API-server VNet integratie, op het moment van schrijven van deze blog nog in public preview. Net als bij een private cluster gaat de communicatie niet via internet, maar het grote verschil bij deze architectuur zit hem in het feit dat er geen tunnel opgezet wordt. De API-server en AKS Cluster communiceren via een interne azure load balancer in een gedelegeerd subnet. De API-server pod IP-adressen worden ‘geprojecteerd’ in het gedelegeerde subnet. De communicatie is gebaseerd op private IP-adressen en er wordt in tegenstelling tot voorgaande opties geen gebruik gemaakt van DNS. Deze optie kan gebruikt worden met of zonder publieke toegang tot de API-server. (zie figuur 6)

Figuur 6: AKS cluster met API-server VNet integratie / public cluster

Met de “enable-api-server-vnet-integration” en “enable-private-cluster” opties gecombineerd is publieke toegang tot de API-server in principe niet meer mogelijk en kan de API-server alleen via de interne load balancer benaderd worden . (zie figuur 7)

Figuur 7: AKS cluster met API-server VNet integratie / private cluster enabled

Er bestaat echter nog een achterdeur voor toegang tot de API-server in een private cluster. Via de Azure CLI kan je remote met ‘command invoke’ commando’s naar de API-server sturen via de Azure API. Wanneer dit niet gewenst is kunnen beheerders deze mogelijkheid uitschakelen met Azure Policy.

Applicatie verkeersstromen

Applicatie verkeer onderscheidt zich in verkeer naar het AKS cluster (ingress) en verkeer geïnitieerd vanuit het AKS cluster (egress).

Egress verkeer

Egress verkeer kan op een 3-tal manieren geconfigureerd worden, load balancer (Standard ILB/PLB), NAT gateway of user defined routing (UDR). Zonder configuratie optie is de default public standard load balancer. (zie figuur 8)

Figuur 8: AKS cluster standaard ‘egress’ verkeer via public load balancer

De pods krijgen outbound toegang via de kube-proxy op de nodes en via de nodes gaat het uitgaand verkeer vervolgens via de Azure public load balancer naar het internet.

In grote omgevingen waar veel pods outbound connecties initiëren is het raadzaam om NATGateway als outbound type te configureren. Dit voorkomt source nate (SNAT) port exhaustion. AKS ondersteunt type managedNATGateway voor managed VNets en userNATGateway voor zelf beheerde VNets en een zelf te configuren NAT gateway.

In geval van een Azure enterprise scale landing-zone architectuur met een HUB en SPOKE netwerk topologie wordt al het uitgaand verkeer van een landing zone vaak beveiligd via een centrale firewall in het HUB netwerk. Voor een AKS landing zone gebruik je in dat geval outbound type “userDefinedRouting” bij de deployment configuratie van het cluster. Standaard wordt er bij de deployment van een AKS cluster een public load balancer aangemaakt. Met Outbound type “userDefinedRouting” wordt er geen outbound route op de load balancer geconfigureerd. Om asynchrone routes te voorkomen rol je een interne load balancer in plaats van een public load balancer uit en maak je DNAT rules aan op de centrale firewall in geval van publiek gepubliceerde services. (zie figuur 4)

Tegenwoordig kan je het AKS outbound type achteraf wijzigen (op het moment van schrijven van deze blog is deze feature nog in public preview). Dit resulteert in additionele en/of verwijderde resources, dus het is zaak om dit vooraf goed te testen.

Ingress verkeer

Kubernetes gebruikt het concept ‘services’ als methode om een applicatie draaiend op één of meerdere pods te publiceren buiten het cluster. Met de service-specificatie “LoadBalancer” rolt AKS een Azure Load Balancer uit, configureert een public of private IP-adres afhankelijk van het type load balancer, en verbindt alle nodes met de load balancer backend pool. (zie figuur 9)

Figuur 9: Frontend service gepubliceerd via load balancer

De kube-proxy ‘verbindt’ het frontend IP-adres van de Azure load balancer met het cluster-IP van de service (service-fe in bovenstaande tekening), die vervolgens de connectie maakt met een pod op basis van round robin.

De load balancer werkt op laag 4 van het OSI model, en dus niet in staat rekening te houden met een applicatie status of routeringen op basis van paden (path based routing). De Azure load balancer ondersteunt ook geen SSL offloading. Daarom wordt er vaak een ingress controller, werkend op laag 7 ingezet om verkeer naar de applicatie(s) te leiden.

Er zijn veel open source kubernetes ingress controllers beschikbaar zoals NGINX, HAProxy, Traefik en meer. Installatie, configuratie, en beheer van de ingress contoller komt in dat geval bij een beheerteam terecht.

Een veel gebruikte NGINX ingress controller bijvoorbeeld, bestaat uit pods gebubliceerd als een service via Azure load balancer. De overige services zitten ‘achter’ de NGINX service. Vanuit de NGINX ingress controller (pod) wordt vervolgens een connectie gemaakt met een (micro)service in het cluster op basis van laag 7. (zie figuur 10)

Figuur 10: Azure load balancer voor NGINX ingress controller

AKS biedt ook managed ingress controllers, waarbij het beheer uit handen genomen wordt door Microsoft.

De application gateway ingress controller (AGIC) add-on bijvoorbeeld, draait als een pod in het cluster, ‘consumeert’ kubernetes ingress resources en converteert deze via azure resource manager naar een application gateway specifieke configuratie, waarna de application gateway het verkeer verdeelt naar de pods. Let op deze ‘vertaling’ kost tijd en nadat bijvoorbeeld een pod verdwenen is duurt het 30 tot 40 seconden voordat dit aangepast is in de application gateway. Met deze configuratie wordt de Azure load balancer niet gebruikt. De application gateway communiceert direct met de pods en vereist dan ook een CNI netwerkmodel.

De application gateway kan gecombineerd worden met een web application firewall (WAF). In een omgeving met een Azure enterprise scale landing-zone architectuur en zero trust networking kan de configuratie er als volgt uit zien. (zie figuur 11)

Figuur 11: AKS cluster ingress zero trust verkeer via Application Gateway met WAF en firewall met IDPS

Ingress verkeer komt binnen via de centrale application gateway met WAF, wordt naar de centrale firewall geleid voor intrusion detection/prevention, eventueel TLS inspectie, en gaat van daaruit naar de application gateway die ‘gevoed’ wordt door de AGIC en het verkeer verdeelt naar de betreffende pods. De communicatie naar de pods gaat dus niet via de service CIDR!

De communicatie flow tussen AGIC en Azure Resource Manager is afhankelijk van de egress configuratie. De communicatie flow tussen de AGIC en de API-server is afhankelijk van de cluster configuratie (public/private).

Naast de application gateway ingress controller (AGIC) add-on biedt Microsoft momenteel twee managed alternatieven, beide op dit moment in public preview. Application Gateway for Containers is de opvolger van de AGIC add-on en biedt naast performance verbeteringen nieuwe features zoals mutual authenticatie (mTLS) naar de backend en maakt gebruik van de kubernetes gateway API. De kubernetes gateway API is de opvolger van de traditionele kubernetes ingress aanpak, kent aparte kubernetes objecten voor het maken van routes en de gateway zelf. Dit maakt een scheiding van beheer, van de gateway door het klusterbeheerteam, en het maken of aanpassen van routes door developers, mogelijk. De gateway API wordt bijvoorbeeld ook gebruikt door HAProxy.

Het tweede managed alternatief is web application routing add-on. Dit is de opvolger van de HTTP application routing add-on die inmiddels ‘retired’ is. De web application routing add-on bestaat uit twee componenten een publiek benaderbare managed nginx ingress controller met SSL termination en een optionele external dns-controller die bij nieuwe kubernetes ingress resources, DNS A records creëert in de cluster specifieke DNS zone. De web application routing add-on integreert ook met open service mesh (OSM), voor end-to-end encryptie (mTLS) tussen de ingress controller en de backend pods.

Zoals gezegd op AKS netwerkgebied zijn veel keuzes te maken wat afstemming vereist met security-, beheer-, en developmentteams. Zorg voor een architectuur die past bij het Azure landschap van de organisatie en maak de gekozen configuratie, met bijbehorende kaders en richtlijnen, duidelijk aan teams die AKS gaan gebruiken.

Lees verder:

Mastering Azure Kubernetes Services deel 4: Secure Identity & Access Management