AKS in productie: tien lessen na drie clusters

Het eerste AKS-cluster dat ik in productie zette werkte. Het tweede werkte beter. Het derde was voor het eerst echt goed opgezet. Dit zijn de tien dingen die ik sindsdien consequent doe, en de fouten die ik niet meer maak.

1. Gebruik Azure CNI, niet Kubenet

Kubenet is de default in sommige configuraties en het is verleidelijk omdat het eenvoudiger lijkt. Gebruik het niet voor productie. Met Kubenet zitten je pods achter een extra NAT-laag, wat problemen geeft met services die het werkelijke bron-IP-adres nodig hebben. Azure CNI geeft elke pod een echt IP-adres uit je VNet, wat integratie met private endpoints, Network Policies, en andere Azure-services een stuk betrouwbaarder maakt.

Het enige nadeel van Azure CNI is IP-planning: je hebt meer adressen nodig in je subnet. Plan voor het maximum aantal pods per node maal het maximum aantal nodes, plus ruimte voor rolling upgrades.

Bekijk AKS en Kubernetes trainingen

2. Pin de Kubernetes-versie

Als je de Kubernetes-versie niet vastlegt, kan een routine-upgrade je cluster breken doordat een deprecated API of add-on niet meer compatibel is. Leg de versie vast in je IaC-template en upgrade bewust, niet automatisch.

Microsoft geeft doorgaans 12 maanden support per minor versie in AKS. Houd een spreadsheet of Azure Policy bij om te weten wanneer je moet upgraden, en test altijd eerst in een non-prod cluster.

3. Stel de cluster autoscaler correct in

De cluster autoscaler werkt goed als je de limieten goed zet. Fouten die ik heb gemaakt: minimum node count op 0 zetten waardoor het cluster soms volledig leeg was bij lage belasting (cold start van 2-3 minuten per pod), en maximum te laag instellen waardoor piekverkeer onbeantwoord bleef.

Stel ook --scale-down-delay-after-add en --scale-down-unneeded-time in op waarden die passen bij je workload. Defaults zijn te agressief voor de meeste productie-scenarios.

4. Managed identities, geen service principals

Service principals hebben client secrets die verlopen. Als je dat op een vrijdagmiddag ontdekt, heb je een probleem. Managed identities hebben geen secrets die je hoeft te roteren. AKS ondersteunt al jaren managed identities voor de cluster-identity en kubelet-identity. Gebruik ze.

5. Log naar Log Analytics

Zet Container Insights aan bij aanmaak van het cluster, niet drie maanden later als je iets wilt debuggen maar de logs er niet zijn. Container Insights stuurt node-metrics, pod-metrics, en container-logs naar Log Analytics. Je betaalt per GB ingestie, maar voor een productie-cluster is dat acceptabel.

Stel ook een retentie in die past bij je compliancevereisten. De default van 30 dagen is voor veel teams te kort.

6. Gebruik Pod Security Standards

Pod Security Admission is ingebouwd in Kubernetes vanaf 1.25 en vervangt de afgeschafte PodSecurityPolicy. Stel per namespace een label in voor het gewenste niveau: restricted, baseline, of privileged. Begin met baseline voor applicatie-namespaces en restricted voor namespaces zonder legacy-workloads.

Dit is niet optioneel voor productie. Pods zonder beperkingen kunnen het hele cluster in gevaar brengen als er een beveiligingslek is.

7. Scheid system node pools van user node pools

Het AKS systeem-node-pool draait kritieke componenten: CoreDNS, kube-proxy, de metrics server. Als jouw applicatie-pods om resources concurreren met systeemcomponenten, kunnen beide het loozen.

Maak een dedicated system node pool (taint: CriticalAddonsOnly=true:NoSchedule) en minstens één user node pool voor applicaties. Het scheelt ook bij upgrades: je kunt de user-pool upgraden of vervangen zonder de systeemcomponenten aan te raken.

8. Plan voor upgrades voordat je ze dodig hebt

Kubernetes-upgrades in AKS werken via node-drain en node-recreate. Zorg dat je pods een PodDisruptionBudget hebben zodat er altijd minimaal één instantie beschikbaar blijft tijdens de drain. Test het upgradeproces in non-prod voordat je het in productie doet.

Automatische upgrades (--auto-upgrade-channel) kunnen nuttig zijn voor patch-versies, maar ik zet ze nooit aan voor minor-versie-upgrades in productie.

9. Monitor kosten per namespace

AKS-kosten zijn makkelijk te onderschatten: je betaalt voor de nodes, maar niet elke namespace verbruikt evenveel. Gebruik de Cost Analysis add-on in AKS (preview) of bouw een eigen oplossing met kubectl top gecombineerd met node-kosten om per team of applicatie te zien wat het kost.

Zonder die zichtbaarheid geeft niemand om efficiëntie, en zit je over zes maanden met een cluster dat voor 20% benut is maar voor 100% betaald wordt.

10. Vertrouw standaard netwerkbeleid niet

AKS maakt standaard geen NetworkPolicies aan. Dat betekent dat alle pods met alle andere pods kunnen communiceren, in alle namespaces. In productie wil je dat niet.

Schakel een Network Policy-engine in bij aanmaak (Azure Network Policy of Calico, afhankelijk van je CNI-keuze). Start met een deny-all policy per namespace en voeg expliciete toestemmingen toe voor de communicatie die je nodig hebt. Dit is werk bij de aanmaak van het cluster, maar het is niet te corrigeren zonder downtime als je het later wilt toevoegen aan een bestaand cluster.

De meeste problemen die ik in AKS-productieomgevingen heb gezien, zijn geen Kubernetes-problemen. Het zijn configuratieproblemen die vermijdbaar zijn als je ze van tevoren kent.