Azure Kubernetes Service — Production Architecture Decisions
Azure Kubernetes Service (AKS) is Azure's managed Kubernetes offering. Microsoft manages the control plane — the API server, etcd, scheduler, and controller manager — at no additional charge. You provision and pay for the node pools (the worker VMs) and the Azure infrastructure those nodes consume. The result is Kubernetes without the operational overhead of running the control plane yourself, integrated deeply with Azure's networking, identity, monitoring, and storage services.
Cluster Architecture Fundamentals
An AKS cluster consists of a system node pool (running Kubernetes system components like CoreDNS and metrics-server) and one or more user node pools for application workloads. Separating system and user pools prevents application resource contention from impacting cluster operations — this is not optional in production.
Node pool design decisions that matter for production:
- VM SKU selection: Match SKU to workload type — compute-optimised (Fsv2) for CPU-bound, memory-optimised (Esv3) for in-memory workloads, GPU SKUs for ML inference. Avoid mixing workload types on the same node pool.
- Availability Zones: Spread node pools across three availability zones. AKS supports zone-aware deployments — use
topologySpreadConstraintsto ensure pods distribute across zones. - Cluster Autoscaler: Enable it on every user node pool. Set min and max node counts conservatively at first — autoscaler reacts to pending pods, not resource utilisation directly.
Networking — Azure CNI vs. Kubenet
Azure CNI assigns pods real Azure VNet IP addresses, enabling direct pod-to-pod communication across VNet boundaries and integration with Azure Network Security Groups. It is the right choice for enterprise deployments where pods need to be reachable from other VNets or on-premises networks. The trade-off is IP address consumption — plan your VNet CIDR ranges carefully.
Azure CNI Overlay (the newer variant) decouples pod IP addresses from the underlying VNet, reducing IP address consumption while retaining Azure CNI's networking capabilities. It is now the recommended default for most new clusters.
Identity — Workload Identity and RBAC
Workload Identity replaces the older Pod Identity (AAD Pod Identity) approach. It integrates Kubernetes service accounts with Entra ID federated credentials, allowing pods to authenticate to Azure services using managed identity without any secrets in the pod configuration. This is the correct, current pattern for AKS pod authentication to Azure Key Vault, Azure Storage, and other Azure services.
AKS supports both Azure RBAC for Kubernetes authorisation (managing who can do what within the cluster via Azure role assignments) and native Kubernetes RBAC. Azure RBAC integration is the preferred approach in enterprise environments where Entra ID is the authoritative identity source.
Monitoring and Observability
Container Insights (Azure Monitor for containers) collects node and pod metrics, container logs, and performance data from AKS clusters and surfaces them in Azure Monitor and Log Analytics. Enable it on every production cluster. The managed Prometheus and Grafana integration (Azure Managed Grafana) provides the open-source observability stack without infrastructure management overhead.
Key Takeaways
- Separate system and user node pools — system pool contamination from application workloads causes cluster instability
- Deploy across availability zones and use topology spread constraints for pod-level zone distribution
- Use Azure CNI Overlay for new clusters — better IP efficiency than classic Azure CNI
- Adopt Workload Identity for pod authentication to Azure services — no secrets, no rotation overhead
- Enable Container Insights and managed Prometheus from day one — retrofitting observability is harder than enabling it at creation
