Azure Kubernetes Service (AKS) is een beheerde Kubernetes-dienst voor teams die een containerapplicatie niet alleen lokaal willen draaien, maar ook betrouwbaar, schaalbaar en veilig in Azure moeten plaatsen. Daarbij komen dezelfde vragen snel op: waar staat het containerimage, wie beheert de nodes, hoe wordt verkeer verdeeld en wat gebeurt er wanneer een pod uitvalt?
Azure Kubernetes Service, meestal AKS genoemd, is de beheerde Kubernetes-dienst van Microsoft Azure voor het draaien van gecontaineriseerde applicaties op een cluster van virtuele machines. Microsoft beheert het Kubernetes-controlevlak, terwijl het team verantwoordelijk blijft voor de worker nodes, workloads, netwerkkeuzes, toegangsrechten, observability en kosten.
Voor beginners is dat onderscheid belangrijk. AKS neemt een deel van de Kubernetes-complexiteit weg, maar het maakt Kubernetes niet onzichtbaar. Wie AKS inzet, kiest nog steeds voor een platform waarbij deployments, services, ingress, nodepools, autoscaling, storage, identity en upgrades bewust ontworpen moeten worden. De officiële productpagina van Azure Kubernetes Service beschrijft AKS als een beheerde Kubernetes-service; in de praktijk betekent dit vooral dat het clusterbeheer eenvoudiger wordt, niet dat applicatie- en platformbeheer verdwijnen.
Wat Kubernetes oplost voordat AKS erbij komt
Kubernetes is een orkestratieplatform voor containers. Een container verpakt een applicatie met de runtime en afhankelijkheden die nodig zijn om die applicatie consistent uit te voeren. Kubernetes zorgt vervolgens dat containers worden gepland op nodes, opnieuw worden gestart bij fouten, bereikbaar blijven via services en kunnen opschalen wanneer de vraag stijgt.
De kernbegrippen keren in bijna elk AKS-project terug. Een pod is de kleinste eenheid die Kubernetes uitvoert en bevat meestal één applicatiecontainer. Een deployment beschrijft hoeveel replica’s van die pod gewenst zijn en hoe updates worden uitgerold. Een service geeft pods een stabiel netwerkadres, omdat pods zelf tijdelijk zijn en bij vervanging een ander IP-adres krijgen.
Daarboven ligt het controlevlak. Dit is het deel van Kubernetes dat de gewenste status vergelijkt met de werkelijke status en bijstuurt wanneer er iets afwijkt. In een zelfbeheerd Kubernetes-cluster moet een team dat controlevlak installeren, beveiligen, upgraden en beschikbaar houden. In AKS wordt dat controlevlak als managed service aangeboden, waardoor de dagelijkse aandacht verschuift naar de nodes, configuratie en workloads.
Wanneer AKS een logische keuze is
AKS past vooral wanneer een applicatiearchitectuur baat heeft bij Kubernetes zelf. Dat geldt bijvoorbeeld voor microservices met verschillende releasecycli, workloads die sterk kunnen variëren in capaciteit, platformteams die een gedeelde containerbasis voor meerdere teams willen aanbieden, of omgevingen waar netwerkisolatie, policy enforcement en integratie met bestaande Azure-netwerken belangrijk zijn.
Daar staat tegenover dat AKS niet automatisch de eenvoudigste of goedkoopste route is. Azure Container Apps kan aantrekkelijker zijn wanneer een team containers wil draaien zonder zelf met nodes, clusterupgrades en Kubernetes-objecten bezig te zijn. App Service for Containers kan voldoende zijn voor een webapplicatie met een eenvoudiger hostingmodel. Het verschil zit minder in de container zelf en meer in de operationele verantwoordelijkheid: AKS biedt veel controle, maar die controle vraagt ontwerpkeuzes, beheerdiscipline en monitoring.
Een nuttig besliskader is daarom om eerst naar de applicatie en het team te kijken. Als de workload vooral HTTP-verkeer verwerkt, weinig clustermaatwerk vraagt en snel beheerd moet worden, kan een hoger abstractieniveau beter passen. Als de workload meerdere services, specifieke netwerkregels, eigen ingress-configuratie, meerdere nodepools of Kubernetes-native tooling nodig heeft, komt AKS eerder in beeld. Wie de basis wil verbreden, kan ook zoeken naar aanvullende Kubernetes-leerbronnen, maar de keuze voor AKS hoort altijd te beginnen bij het operationele model.
De bouwstenen van een AKS-cluster
Een AKS-cluster bestaat uit een beheerd controlevlak en één of meer nodepools. Een nodepool is een groep virtuele machines met dezelfde configuratie. In productieomgevingen is het verstandig om system workloads en applicatieworkloads te scheiden. De system nodepool draait onderdelen die het cluster nodig heeft, terwijl user nodepools bedoeld zijn voor applicaties.
Die scheiding voorkomt dat applicaties de resources van kritieke clustercomponenten verdringen. Het maakt ook kostenbeheer praktischer, omdat user nodepools anders kunnen schalen dan system nodepools. Voor tijdelijke of fouttolerante workloads kan een spot nodepool interessant zijn, maar alleen wanneer de applicatie kan omgaan met onderbrekingen. Voor stabiele basisservices blijft een reguliere nodepool passender.
AKS gebruikt containerd als moderne container runtime. Containerimages worden vaak opgeslagen in Azure Container Registry, zodat het cluster images uit een private registry kan ophalen zonder publieke distributie. Deze koppeling is een van de redenen waarom AKS prettig werkt binnen Azure, maar de configuratie van identity en rechten blijft belangrijk: een cluster mag niet meer toegang krijgen dan nodig is.
Een eerste AKS-cluster en applicatie uitrollen
Een beginnersopstelling kan klein blijven zolang de structuur realistisch is. De volgende voorbeelden gaan uit van Azure CLI, kubectl, Azure Container Registry en een eenvoudige webapplicatie. In een echte omgeving moeten namen, regio, netwerkbereiken en policies aansluiten op de organisatie, maar de volgorde laat zien hoe de onderdelen samenkomen.
Een praktische start bestaat uit een containerregistry, een AKS-cluster dat images uit die registry kan trekken, en een Kubernetes deployment met een service. Daarna kan autoscaling worden toegevoegd op basis van CPU-aanvragen. De belangrijkste stappen zijn:
- Maak een resourcegroep en Azure Container Registry aan.
- Maak een AKS-cluster met koppeling naar de registry.
- Haal de Kubernetes-credentials lokaal op met Azure CLI.
- Deploy de applicatie met YAML en publiceer deze via een service.
- Voeg resource requests, limits en Horizontal Pod Autoscaler toe.
Gebruik dit voorbeeld wanneer het doel is om de minimale infrastructuur voor een eerste AKS-testomgeving neer te zetten. De commando’s gebruiken Azure CLI en vermijden hardcoded geheimen; authenticatie gebeurt via de actieve Azure-sessie.
Example — AKS en Azure Container Registry aanmaken
az group create \
--name rg-aks-start \
--location westeurope
az acr create \
--resource-group rg-aks-start \
--name acraksstartdemo \
--sku Basic
az aks create \
--resource-group rg-aks-start \
--name aks-start-demo \
--node-count 2 \
--enable-managed-identity \
--attach-acr acraksstartdemo \
--generate-ssh-keys
az aks get-credentials \
--resource-group rg-aks-start \
--name aks-start-demo
kubectl get nodes
Hiermee ontstaat een klein cluster in West Europe met een gekoppelde containerregistry. Controleer na afloop of kubectl nodes teruggeeft en of de lokale context naar het juiste cluster wijst. Voor productie is dit nog geen volledig ontwerp; netwerkmodel, private toegang, monitoring, policies en upgrade-instellingen horen dan expliciet mee te gaan.
De applicatie zelf wordt in Kubernetes beschreven met YAML. In het voorbeeld krijgt de container requests en limits mee, omdat autoscaling zonder resource requests vaak tot verwarrend gedrag leidt. Dit is een veelgemaakte fout bij beginnende AKS-teams: pods worden wel uitgerold, maar Kubernetes krijgt onvoldoende informatie om plaatsing en schaalgedrag betrouwbaar te bepalen.
Example — Deployment en service publiceren
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
spec:
replicas: 2
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
containers:
- name: webapp
image: acraksstartdemo.azurecr.io/webapp:1.0.0
ports:
- containerPort: 8080
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "256Mi"
---
apiVersion: v1
kind: Service
metadata:
name: webapp-service
spec:
type: LoadBalancer
selector:
app: webapp
ports:
- port: 80
targetPort: 8080
Deze YAML maakt replica’s van de webapp en publiceert ze via een Azure Load Balancer. Controleer met kubectl get pods en kubectl get service of de pods gezond zijn en of de service een extern adres krijgt. In interne of streng gereguleerde omgevingen is een publieke Load Balancer vaak niet gewenst; dan ligt een interne load balancer, private ingress of private clusterontwerp meer voor de hand.
Autoscaling is pas zinvol wanneer de applicatie resource requests heeft en wanneer metrics beschikbaar zijn. De Horizontal Pod Autoscaler schaalt pods, terwijl de cluster autoscaler nodes kan toevoegen of verwijderen wanneer er onvoldoende capaciteit is. Beide lossen een ander probleem op en moeten daarom samenhangend worden ingesteld.
Example — Horizontal Pod Autoscaler toevoegen
kubectl autoscale deployment webapp \
--cpu-percent=60 \
--min=2 \
--max=6
kubectl get hpa webapp
De HPA probeert het aantal podreplica’s aan te passen op basis van CPU-gebruik. Als pods niet kunnen worden ingepland omdat de nodes vol zijn, is daarnaast node-autoscaling nodig. In productie hoort dit samen te gaan met loadtests, duidelijke limieten en alerts, omdat agressieve schaalinstellingen kosten en instabiliteit kunnen veroorzaken.
Netwerkkeuzes die later moeilijk te herstellen zijn
Netwerken is een van de AKS-beslissingen die beginners vaak onderschatten. Het gekozen netwerkmodel beïnvloedt IP-adressering, integratie met bestaande virtuele netwerken, connectiviteit naar databases, firewallregels, private endpoints en soms ook kosten. Voor Belgische en Europese organisaties komt daar vaak de vraag bij hoe het cluster past binnen bestaande segmentatie, logging en complianceprocessen.
AKS ondersteunt verschillende netwerkopties, waaronder kubenet en Azure CNI-varianten. Bij klassiek Azure CNI krijgen pods IP-adressen uit het virtuele netwerk, wat integratie eenvoudig kan maken maar veel IP-adressen kan reserveren. Overlay-netwerken verminderen de druk op het virtuele netwerk doordat pod-IP’s anders worden behandeld. Dat kan aantrekkelijk zijn wanneer IP-ruimte schaars is of wanneer meerdere clusters naast elkaar moeten bestaan.
Een private cluster beperkt de publieke bereikbaarheid van de Kubernetes API-server. Dat kan goed passen bij strengere netwerkmodellen, maar het maakt beheer ook afhankelijker van private DNS, jump hosts, VPN, ExpressRoute of beheerde build agents binnen het netwerk. Private is dus geen vinkje dat alleen beveiliging toevoegt; het verandert de manier waarop engineers, CI/CD-systemen en beheertools met het cluster praten.
Network Policy verdient eveneens vroege aandacht. Zonder netwerkbeleid kunnen pods binnen een cluster vaak ruimer met elkaar communiceren dan gewenst. Door beleid te ontwerpen op basis van noodzakelijke verkeersstromen ontstaat een betere basis voor segmentatie. Dit vraagt wel kennis van applicatieverkeer; te strakke regels zonder observability leiden snel tot storingen die moeilijk te diagnosticeren zijn.
Beveiliging begint bij identiteit en minimale rechten
Een goede AKS-baseline combineert Kubernetes RBAC, Microsoft Entra ID-integratie, managed identities en policy enforcement. Toegang tot het cluster moet worden gekoppeld aan rollen en groepen, niet aan gedeelde kubeconfig-bestanden die onbeperkt rondgaan. Voor workloads die Azure-resources moeten benaderen, is Microsoft Entra Workload ID de moderne aanpak; oudere patronen zoals Pod Identity horen niet meer het uitgangspunt te zijn.
Secrets verdienen een eigen ontwerp. Kubernetes Secrets zijn bruikbaar voor eenvoudige scenario’s, maar gevoelige waarden worden in Azure-omgevingen vaak beter beheerd via Azure Key Vault en de Secrets Store CSI Driver. Daarmee blijft het geheimbeheer dichter bij de centrale governance van Azure, terwijl pods de waarden kunnen gebruiken zonder dat teams secrets in manifests of repositories plaatsen.
Azure Policy kan helpen om ongewenste configuraties te blokkeren of te signaleren, zoals containers zonder resource limits, privileged containers of images uit niet-goedgekeurde registries. Policy is echter geen vervanging voor ontwerp. Teams moeten nog steeds bepalen welke namespaces bestaan, wie deployments mag wijzigen, welke registries vertrouwd zijn en hoe uitzonderingen worden behandeld.
Operations: upgrades, monitoring en herstel
AKS is een beheerde dienst, maar clusters hebben nog steeds een operationele lifecycle. Kubernetes-versies raken verouderd, node images krijgen patches, add-ons veranderen en applicaties moeten compatibel blijven met API-versies. Een stabiel AKS-platform heeft daarom een upgradeproces nodig dat in een testcluster wordt gevalideerd voordat productie volgt.
Gecontroleerde upgrades gebruiken vaak surge-capaciteit, zodat nieuwe nodes kunnen worden toegevoegd terwijl oude nodes worden leeggemaakt. Applicaties moeten daarvoor readiness probes, liveness probes, voldoende replica’s en Pod Disruption Budgets hebben. Zonder die basis kan een technisch correcte clusterupgrade alsnog applicatieonderbrekingen veroorzaken.
Monitoring begint met Azure Monitor, Container Insights en logverzameling, maar de kosten van logging kunnen oplopen wanneer alle stdout, events en metrics onbeperkt worden bewaard. Een volwassen inrichting maakt onderscheid tussen operationele logs, auditgegevens en applicatiediagnostiek. Niet alles hoeft even lang bewaard te worden, en niet elke namespace heeft hetzelfde detailniveau nodig.
Herstelstrategie wordt vaak pas besproken na de eerste storing. Voor stateless workloads is herstel vooral een kwestie van opnieuw deployen uit CI/CD en containerregistry. Stateful workloads vragen meer: storage classes, snapshots, back-ups, restore-tests en een besluit over waar databases horen te draaien. Een relationele database zonder doordacht storage- en HA-ontwerp in het cluster plaatsen is voor beginners meestal een risico; beheerde databasediensten zijn vaak eenvoudiger te beheren.
Kosten: waar de rekening werkelijk ontstaat
Bij AKS worden kosten niet alleen bepaald door het clusterobject. De nodepools draaien op virtuele machines en die kosten lopen door zolang de nodes actief zijn, ook wanneer er weinig of geen applicatiepods draaien. Daarnaast kunnen Load Balancers, public IP’s, managed disks, egress-verkeer, containerregistries en logging bijdragen aan de totale rekening.
Autoscaling helpt alleen wanneer het zorgvuldig wordt ingesteld. Een cluster autoscaler kan user nodepools verkleinen wanneer workloads verdwijnen, maar system pools blijven nodig voor de basis van het cluster. Spot nodepools kunnen kosten drukken voor batchtaken of niet-kritieke workloads, terwijl productiecomponenten die continu beschikbaar moeten zijn beter op reguliere nodes draaien.
Een praktische kostenaanpak begint met scheiding tussen system en user pools, requests en limits per applicatie, realistische minimumcapaciteit en logretentie die past bij het doel. Daarna kan worden gekeken naar reserved capacity, geschikte VM-series en het verplaatsen van taken naar platformdiensten wanneer Kubernetes daar geen duidelijke waarde toevoegt.
Veelgemaakte fouten bij de eerste AKS-implementatie
De meeste AKS-problemen ontstaan niet omdat het cluster niet kan wat nodig is, maar omdat keuzes te laat worden gemaakt. Een cluster dat snel als test begint, groeit soms door naar een gedeelde omgeving zonder helder netwerkontwerp, zonder eigenaarschap van namespaces en zonder afspraken over upgrades. Daardoor worden latere wijzigingen duurder dan nodig.
Een terugkerende fout is het mengen van system en user workloads in dezelfde pool. Dat lijkt eenvoudig bij de start, maar maakt capaciteitsbeheer en incidentanalyse lastiger. Een andere fout is het overslaan van resource requests, limits en HPA, waardoor Kubernetes onvoldoende signalen heeft om pods goed te plaatsen of te schalen. IP-planning wordt ook vaak te laat bekeken; zodra subnetten vol raken, is herstel veel ingrijpender dan vooraf een passend netwerkmodel kiezen.
Ook beveiliging wordt soms behandeld als iets dat na de applicatie komt. In AKS werkt dat zelden goed. RBAC, registrypolicies, Workload ID, Key Vault-integratie en Network Policy raken direct aan hoe applicaties worden gebouwd en uitgerold. Teams die deze onderwerpen vroeg meenemen, hoeven minder manifests, pipelines en rechtenmodellen achteraf te herstellen.
Waar training en officiële documentatie elkaar aanvullen
De beste manier om AKS te leren is een combinatie van bouwen, breken en verklaren. Officiële Microsoft-documentatie en architectuurrichtlijnen zijn nuttig voor actuele productdetails, terwijl hands-on training helpt om keuzes in context te plaatsen. Microsoft biedt ook een overzicht van Kubernetes-training en certificeringsbronnen voor wie het onderwerp vanuit Azure verder wil structureren.
Readynez kan in dat leerpad een rol spelen wanneer teams de stap willen maken van losse commando’s naar beheerbare Azure- en Kubernetes-praktijken. Daarbij is het zinvol om AKS niet als geïsoleerde technologie te behandelen, maar naast Azure networking, identity, security monitoring en DevOps-processen te leren. Het bredere Microsoft-aanbod van Readynez staat op de pagina met Microsoft-trainingen.
Een realistische eerste stap met AKS
AKS is een krachtige keuze wanneer een organisatie Kubernetes-controle nodig heeft binnen Azure, maar het vraagt meer dan een werkend cluster. De kwaliteit van een AKS-omgeving wordt bepaald door netwerkontwerp, identity, nodepoolstrategie, resourcebeheer, observability, upgrades en kostenbewaking. Beginners die deze onderwerpen vanaf het eerste cluster meenemen, bouwen minder technische schuld op.
De meest praktische volgende stap is een kleine testomgeving maken met ACR, AKS, een deployment, een service en autoscaling, en die daarna bewust uitbreiden met private networking, RBAC, Workload ID, Key Vault, monitoring en upgradeprocedures. Zo ontstaat geen losse demo, maar een leeromgeving die lijkt op de keuzes die in productie echt terugkomen.
