EKS of AKS: welke managed Kubernetes voor Nederland
EKS en AKS zijn allebei managed Kubernetes. In beide gevallen beheert de cloudprovider het control plane en ben jij verantwoordelijk voor de nodes. Toch zijn er genoeg praktische verschillen om de keuze niet willekeurig te laten zijn.
Kosten: het eerste echte verschil
AKS rekent niets voor het control plane. Je betaalt alleen voor de VM’s die je nodes draaien. Er is wel een optie voor een betaald “Uptime SLA” dat de beschikbaarheidsgarantie voor het control plane verhoogt, maar de basis is gratis.
EKS rekent $0,10 per uur per cluster voor het control plane. Op jaarbasis is dat $876 per cluster. Als je meerdere clusters draait (dev, staging, productie) telt dat op. Het is geen enorm bedrag, maar het is een verschil bij vergelijkbare workloads.
Netwerken: VPC CNI versus Azure CNI
EKS gebruikt standaard de AWS VPC CNI. Pods krijgen echte IP-adressen uit je VPC-subnet. Dat maakt routering eenvoudig en security groups werken op pod-niveau. De keerzijde: je subnet-grootte moet groot genoeg zijn voor het maximum aantal pods dat je wilt draaien. IP-uitputting is een echt probleem bij grotere clusters als je het VPC-ontwerp niet goed plant.
AKS biedt Azure CNI en de recentere Azure CNI Overlay. De Overlay-variant lost het IP-probleem op door pods een apart adresruimte te geven dat via NAT loopt. Dat maakt IP-planning minder kritisch, maar voegt een laag toe die je bij troubleshooting moet begrijpen.
Node groups versus node pools
EKS gebruikt “managed node groups” of zelfbeheerde node groups. Karpenter is de aanbevolen auto-scaler: het maakt in seconden nieuwe nodes aan op basis van pod-aanvragen, kiest het goedkoopste instance-type dat past, en verwijdert nodes als ze niet meer nodig zijn.
AKS heeft “node pools” met een ingebouwde cluster autoscaler. De integratie met Azure Spot Instances voor kostenreductie werkt goed en is eenvoudiger in te stellen dan equivalente Spot-configuraties op EKS.
IAM-integratie
Op EKS gebruik je IRSA (IAM Roles for Service Accounts) of de nieuwere EKS Pod Identity om een IAM-rol te koppelen aan een Kubernetes-serviceaccount. Het werkt goed, maar de initiële configuratie heeft wat stappen.
Op AKS gebruik je Workload Identity, dat leunt op Azure Managed Identities en Entra ID. Als je organisatie al Entra ID gebruikt voor gebruikersbeheer, sluit dit naadloos aan. Groepen en rechten die je al hebt in Entra ID kun je direct toewijzen aan Kubernetes-rollen.
Volwassenheid en ecosysteem
EKS is ouder en heeft een groter ecosysteem aan tooling die er specifiek op gericht is. De meeste open source Kubernetes-tooling wordt als eerste getest op EKS. AWS heeft ook een dieper aanbod aan aanvullende diensten die integreren met EKS: ECR, App Mesh, X-Ray, en de integratie met Load Balancer Controller is goed gedocumenteerd.
AKS heeft de afgelopen twee jaar een inhaalslag gemaakt. Microsoft investeert zwaar in Kubernetes, mede omdat Azure Kubernetes Service een van hun snelst groeiende producten is. Features als KEDA (event-driven autoscaling), Dapr en de Azure Service Operator zijn allemaal afkomstig uit de Microsoft/CNCF-wereld.
Wanneer kies je wat
Kies AKS als je organisatie al op Azure zit, Entra ID gebruikt voor identiteitsbeheer en het gratis control plane een rol speelt in de kostenafweging. De integratie met de rest van het Azure-platform is simpelweg makkelijker als je toch al in dat ecosysteem werkt.
Kies EKS als je AWS-native bent, de meeste van je andere diensten op AWS draaien en je wilt profiteren van de bredere ecosysteemvolwassenheid en diensten als Karpenter en IRSA die al langer bewezen zijn.