CLOUD & DEVOPS / KUBERNETES / AKS
AKS Production Readiness Checklist
The questions worth answering before your first serious workload lands.
Key Insight: A default AKS cluster runs your workload fine on day one. Whether it survives day one hundred depends on decisions made before the first serious workload lands, most of which aren't visible until something goes wrong.
Standing up an AKS cluster and deploying to it is genuinely quick now — that speed is exactly why teams skip past decisions that are expensive to reverse later. This is the checklist I run before calling a cluster production-ready.
Networking: decide the model deliberately
Kubenet versus Azure CNI isn't a detail — it determines whether your pods get real, routable IPs from your VNet or not, which affects everything from network policy enforcement to how easily you integrate with on-premises networks via ExpressRoute or VPN. Azure CNI Overlay is the common modern default, giving you the flexibility of CNI without consuming a large chunk of VNet address space. Decide this deliberately at cluster creation — changing it later typically means rebuilding the cluster.
Confirm network policies are actually enforced (Azure Network Policy or Calico), not just defined. A NetworkPolicy manifest that exists but isn't enforced by the underlying CNI gives a false sense of segmentation.
Identity: Workload Identity, not stored secrets
If pods need to access Azure resources — Key Vault, Storage, a database — the production-ready answer is Microsoft Entra Workload ID, which lets a pod authenticate as a managed identity without any secret stored in the cluster. Clusters that still inject service principal credentials as Kubernetes secrets are carrying unnecessary risk and unnecessary operational burden (rotation, leakage). This is worth fixing before go-live — migrating identity model on a live cluster with running workloads is more disruptive than doing it upfront.
Autoscaling: at every layer, not just pods
Horizontal Pod Autoscaler handles pod-level scaling, but it needs the Cluster Autoscaler (or Node Auto Provisioning) underneath it to actually get new nodes when pods can't be scheduled — without it, HPA will happily try to scale pods that then sit Pending. Set resource requests and limits deliberately on every workload; without accurate requests, both the scheduler and the autoscaler are making decisions on bad information, leading to either wasted capacity or scheduling failures under load.
Upgrades: plan for them, don't discover them
AKS clusters need regular Kubernetes version upgrades, and unattended clusters drift out of support faster than teams expect. Before go-live, confirm: is the cluster on a supported upgrade channel, is there a tested process for upgrading node pools with acceptable disruption (surge upgrade settings, pod disruption budgets that actually protect availability during node drains), and does someone own watching for deprecated API versions before they're removed in an upcoming release. A cluster nobody upgrades until forced to is a cluster that eventually forces an emergency upgrade under pressure.
Observability: Container Insights plus your own signals
Enable Azure Monitor Container Insights as a baseline — it gives you cluster and node-level health without extra instrumentation. But cluster health isn't application health: make sure your workloads expose their own meaningful metrics (the ones specific to what they do, not just CPU and memory) and that logs are structured and queryable, not just captured. Confirm alerting exists for the things that actually predict an incident — node pressure, pod eviction rates, HPA hitting its max replica count — not just "is the cluster technically up."
Pod disruption budgets and resource limits, tested under real conditions
A PodDisruptionBudget that's too permissive doesn't protect availability during a node drain or cluster upgrade — it just exists. Test what actually happens when a node is cordoned and drained: does the workload stay available, or does it briefly go to zero replicas because the PDB math didn't account for how many replicas you actually run? This is worth verifying deliberately, not assuming.
Key takeaways
Choose your networking model (CNI, network policy enforcement) deliberately at cluster creation — it's expensive to change later. Use Workload Identity instead of stored credentials. Configure autoscaling at both the pod and node layer, backed by accurate resource requests. Have a real, tested upgrade process before you need one under pressure. Instrument application-level signals on top of cluster-level monitoring, and test your pod disruption budgets against an actual node drain before you rely on them during an incident.