10 veelgemaakte fouten in Azure Kubernetes Service
1. Geen resource quotas en limits instellen
Zonder resource quotas en limits op pods en namespaces kan één applicatie alle cluster resources gebruiken. Hierdoor houdt de rest van het cluster onvoldoende resources over.
Dat kan leiden tot slechtere performance, instabiele applicaties en mogelijke uitval van andere workloads.
Wat je beter doet:
- Stel CPU- en memory requests en limits in op pod-niveau.
- Gebruik ResourceQuotas op namespace-niveau om resources eerlijk te verdelen over teams, omgevingen en applicaties.
- Gebruik LimitRanges om standaard-, minimum- en maximumwaarden voor CPU en memory in te stellen voor containers binnen elke namespace.
2. De default node pool gebruiken voor elke workload
Alle workloads op de default node pool draaien lijkt eenvoudig, maar beperkt je mogelijkheden om applicaties te isoleren en optimaliseren.
Verschillende workloads hebben vaak andere VM sizes, scaling-instellingen en beschikbaarheidseisen nodig. Als alles samen draait, kan een workload die veel resources gebruikt andere applicaties beïnvloeden die juist beschermd hadden moeten worden.
Wat je beter doet:
- Maak aparte node pools voor system components, productie-applicaties en batch jobs.
- Gebruik passende VM SKUs voor elke workload en pas taints, tolerations en affinities toe om workloads op de juiste nodes te houden.
3. Clusters draaien zonder monitoring en diagnostics
Zonder monitoring heb je nauwelijks zicht op wat er in je cluster gebeurt. Als Container Insights en diagnostic settings niet zijn ingeschakeld, mis je inzicht in cluster health, performance bottlenecks en security events.
Troubleshooting duurt daardoor langer en de gemiddelde hersteltijd bij incidenten neemt toe.
Wat je beter doet:
- Schakel Container Insights in en configureer diagnostic settings om logs naar een Log Analytics workspace te sturen.
- Monitor node health, pod restarts, resource usage, errors en cluster events vanaf dag één.
4. Secrets opslaan als plain text of in ConfigMaps
Gevoelige data hoort niet thuis in ConfigMaps of plain environment variables. Als credentials, tokens of connection strings op deze manier worden opgeslagen, kan iedereen met read access tot het cluster deze mogelijk bekijken.
Dat veroorzaakt directe security- en compliance-risico’s.
Wat je beter doet:
- Gebruik secrets voor productieomgevingen, bij voorkeur Azure Key Vault in combinatie met de Secrets Store CSI Driver.
- Gebruik Workload Identity of managed identity om toegang te krijgen tot Key Vault.
- Gebruik Kubernetes Secrets alleen wanneer dat nodig is, met encryption at rest en strikte RBAC.
5. De API server publiek beschikbaar maken
Een publiek beschikbare Kubernetes API server zonder IP whitelisting creëert een onnodig groot attack surface voor ongeautoriseerde toegangspogingen.
Ook met goede authenticatie blijft brede publieke toegang een extra risico.
Wat je beter doet:
- Kies waar mogelijk voor een private cluster design.
- Configureer authorised IP ranges wanneer een publieke API endpoint noodzakelijk blijft.
6. Network policies niet volledig instellen
Als network policies ontbreken of te ruim zijn ingesteld, kunnen pods mogelijk vrij communiceren met de rest van het cluster.
Als één pod wordt gecompromitteerd, kan unrestricted pod-to-pod communication ervoor zorgen dat het probleem zich als een virus door de omgeving verspreidt.
Wat je beter doet:
- Gebruik Kubernetes Network Policies om onnodige ingress en egress tussen pods te beperken.
- Kies bij nieuwe AKS-omgevingen waar passend voor Azure CNI Powered by Cilium.
- Pas zero-trust networking en microsegmentation toe, zodat workloads alleen communiceren wanneer dat nodig is.
7. Azure Policy en Pod Security Standards uitschakelen
Azure Policy for Kubernetes en Pod Security Admission helpen privileged containers te voorkomen, security contexts af te dwingen en workloads in lijn te houden met compliance-eisen.
Zonder deze controles kunnen onveilige of niet-compliant configuraties makkelijker je AKS-cluster bereiken. Daardoor wordt het lastiger om een consistente security posture te behouden wanneer het aantal workloads, teams en omgevingen groeit.
Wat je beter doet:
- Gebruik de Azure Policy add-on voor centrale governance, audit- en deny-effects en enterprise compliance.
- Gebruik Pod Security Admission met namespace labels voor Pod Security Standards.
Gebruik deze controles om risicovolle configuraties te blokkeren voordat ze het cluster bereiken.
8. latest of andere mutable image tags gebruiken in productie
Het gebruik van latest of andere mutable image tags maakt deployments onvoorspelbaar.
Een tag kan later naar een andere image verwijzen, terwijl het deployment file niet is gewijzigd. Dat kan deployments breken, kwetsbaarheden introduceren en rollbacks moeilijker maken.
Wat je beter doet:
- Gebruik specifieke immutable image tags of digest references.
- Zorg dat elke productie-deployment verwijst naar een bekende, geteste en reproduceerbare imageversie.
9. Single-zone deployments gebruiken voor productie-workloads
Single-zone AKS-deployments kunnen een één storingspunt vormen en bij een uitval van een availability zone mogelijk volledige uitval veroorzaken.
Wat je beter doet:
- Gebruik availability zones voor productie-workloads.
- Verdeel nodes over meerdere zones en gebruik pod topology spread constraints om te voorkomen dat replicas op één locatie worden geconcentreerd.
- Kies voor zone-aware storage.
10. Pod Disruption Budgets vergeten voor kritieke applicaties
Zonder Pod Disruption Budgets kunnen cluster maintenance- of scaling-events te veel pod replicas tegelijk verwijderen.
Dat kan leiden tot vermijdbare uitval tijdens upgrades, node drains of gepland onderhoud.
Wat je beter doet:
- Definieer Pod Disruption Budgets voor kritieke applicaties.
- Gebruik ze om de minimale beschikbaarheid te behouden tijdens upgrades, schaaloperaties en gepland onderhoud.
