Microsoft Azure — Azure Kubernetes Service (AKS)

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers azure kubernetes service (aks) with production-ready configurations, best practices, and hands-on examples.

Why AKS? The Case for Managed Kubernetes

Azure Kubernetes Service (AKS) is Microsoft's managed Kubernetes offering. It abstracts away control plane management, including etcd, API server, and scheduler, while letting you retain full control over worker nodes. The primary advantage is reduced operational overhead: you no longer need to patch the control plane, manage etcd backups, or handle API server scaling. However, managed doesn't mean hands-off. You still own node pool configuration, networking, storage, and security. AKS is ideal for teams that want Kubernetes without the burden of control plane maintenance, but it demands a solid understanding of Kubernetes fundamentals. If you're new to Kubernetes, start with a local cluster like Minikube before moving to AKS. The cost savings from reduced operational toil often outweigh the premium over self-managed clusters, especially at scale.

#!/bin/bash
# Create an AKS cluster with a system node pool and a user node pool
az group create --name myAKSResourceGroup --location eastus
az aks create \
  --resource-group myAKSResourceGroup \
  --name myAKSCluster \
  --node-count 3 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 10 \
  --node-vm-size Standard_DS2_v2 \
  --generate-ssh-keys
az aks get-credentials --resource-group myAKSResourceGroup --name myAKSCluster

Cluster Architecture: Node Pools, Availability Zones, and Scaling

AKS clusters consist of a managed control plane and one or more node pools. Node pools are groups of VMs with the same SKU and configuration. You can have system node pools (for critical add-ons) and user node pools (for your workloads). Availability zones distribute nodes across physically separated datacenters within a region, protecting against zonal failures. Enable them at cluster creation time—you cannot add them later. Cluster autoscaler automatically adjusts node count based on pending pods, but it's not instantaneous; it reacts to unschedulable pods, so plan for headroom. For burst scenarios, consider using Azure Container Instances (ACI) via virtual nodes, though they have networking limitations. Always set resource requests and limits on your pods; without them, the autoscaler cannot make informed scaling decisions.

#!/bin/bash
# Add a user node pool with availability zones and autoscaling
az aks nodepool add \
  --resource-group myAKSResourceGroup \
  --cluster-name myAKSCluster \
  --name userpool \
  --node-count 3 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 10 \
  --node-vm-size Standard_DS3_v2 \
  --zones 1 2 3

Networking: CNI Choices and Traffic Routing

AKS supports two primary network models: kubenet (basic) and Azure CNI (advanced). Kubenet is simpler and uses less IP addresses—each node gets a /24 subnet, and pods get IPs from a different virtual network. Azure CNI assigns each pod an IP from the VNet, enabling direct connectivity to other Azure services but consuming many IPs. For production, use Azure CNI with dynamic IP allocation (preview) to reduce IP waste. Calico is the default network policy engine; it enforces fine-grained traffic rules. Always plan your IP address space carefully: each node in Azure CNI reserves up to 110 IPs per node (configurable). Overlapping IPs with on-premises networks can cause routing nightmares. Use Azure Firewall or a third-party NVA for egress filtering; do not rely solely on NSGs.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Identity and Access Management: RBAC, Azure AD, and Managed Identities

AKS integrates with Azure AD for authentication and Kubernetes RBAC for authorization. Enable Azure AD integration at cluster creation; you cannot add it later. Use Azure AD groups to map to Kubernetes roles (e.g., cluster-admin, namespace-admin). For pod-level identity, use Azure AD Pod Identity or the newer Workload Identity (recommended). Workload Identity uses federated identity credentials and avoids the complexity of Pod Identity's CRDs and custom resource management. Never use service principal secrets in code; instead, use managed identities for Azure resources. For cross-cluster access, use Azure RBAC for Kubernetes (preview) to manage permissions at the subscription level. Audit all access via Azure Monitor and Kubernetes audit logs.

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: "<managed-identity-client-id>"
  name: my-sa
  namespace: default
---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: my-sa
  containers:
  - name: my-container
    image: my-image

Storage: Persistent Volumes, CSI Drivers, and Backup Strategies

AKS supports multiple storage options via Container Storage Interface (CSI) drivers: Azure Disk (block storage), Azure Files (SMB/NFS), and Azure NetApp Files (high-performance NFS). For stateful workloads, use Azure Disk with managed disks for low latency; for shared access, use Azure Files. Always use CSI drivers (not the legacy in-tree drivers) for better performance and features like volume snapshots and resize. Enable CSI driver at cluster creation. For backups, use Velero with the Azure Blob Storage plugin to backup both Kubernetes resources and persistent volumes. Test restores regularly. Avoid using hostPath or emptyDir for production data; they don't survive node failures.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-disk-pvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-csi
  resources:
    requests:
      storage: 10Gi

Security: Network Policies, Secrets Management, and Pod Security

Security in AKS is multi-layered. At the network level, enforce least-privilege network policies using Calico or Azure Network Policy. For secrets, never store them in ConfigMaps or environment variables. Use Azure Key Vault with the Secrets Store CSI driver to mount secrets as volumes or environment variables. For pod security, use Azure Policy for Kubernetes (built-in) or OPA/Gatekeeper to enforce standards like disallowing privileged containers or hostPath mounts. Enable Azure Defender for Kubernetes to detect threats. Regularly scan images with Azure Container Registry (ACR) or a third-party scanner. Rotate your cluster's service principal or managed identity credentials periodically.

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kvname
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "true"
    userAssignedIdentityID: "<managed-identity-client-id>"
    keyvaultName: "my-keyvault"
    objects: |
      array:
        - |
          objectName: my-secret
          objectType: secret
    tenantId: "<tenant-id>"

Monitoring and Logging: Azure Monitor, Container Insights, and Alerts

Enable Azure Monitor Container Insights at cluster creation to collect metrics and logs from nodes, pods, and containers. It sends data to Log Analytics, where you can query with KQL. Set up alerts for key metrics: node CPU/memory pressure, pod restarts, and OOMKilled events. For application-level monitoring, use Application Insights or Prometheus with Azure Monitor managed service for Prometheus (preview). Centralize logs using Fluentd or Fluent Bit to send to Azure Log Analytics or a third-party SIEM. Configure diagnostic settings to stream AKS control plane logs (kube-apiserver, kube-controller-manager) to Log Analytics. Without these, you're blind to API server issues.

// Find pods with high restart counts
KubePodInventory
| where TimeGenerated > ago(1h)
| where PodRestartCount > 5
| project TimeGenerated, ClusterName, Namespace, PodName, PodRestartCount, ServiceName

Upgrades: Cluster and Node Pool Version Management

AKS supports multiple Kubernetes versions; you must upgrade before Microsoft ends support (usually 12 months after release). Plan upgrades in advance: test in a non-production cluster first. Use az aks upgrade for control plane and node pools. Node pools can be upgraded independently, but they must be within the same minor version as the control plane. For zero-downtime upgrades, use surge upgrades: add extra nodes before draining old ones. Monitor pod disruption budgets to ensure availability during node drains. Automate upgrades with Azure Update Manager or GitHub Actions. Never skip minor versions; upgrade sequentially. After upgrade, verify all workloads and roll back if needed (by redeploying old version).

#!/bin/bash
# Upgrade control plane and node pools
az aks upgrade \
  --resource-group myAKSResourceGroup \
  --name myAKSCluster \
  --kubernetes-version 1.28.3 \
  --yes
# Upgrade a node pool with surge
az aks nodepool upgrade \
  --resource-group myAKSResourceGroup \
  --cluster-name myAKSCluster \
  --name userpool \
  --kubernetes-version 1.28.3 \
  --max-surge 1

Cost Management: Right-Sizing, Spot Instances, and Reserved Instances

AKS costs include control plane (free), worker nodes, storage, and networking. Optimize node sizing: use Azure's right-sizing recommendations or tools like Kubecost. For non-critical, fault-tolerant workloads, use spot node pools—they offer deep discounts but can be evicted. Combine spot with regular nodes for resilience. Use Azure Reserved Instances for predictable workloads to save up to 72%. Enable cluster autoscaler to avoid over-provisioning. Monitor costs with Azure Cost Management and set budgets. Consider using Azure Kubernetes Service (AKS) with Azure Arc for hybrid deployments to avoid egress costs. Always tag resources for cost allocation.

#!/bin/bash
# Add a spot node pool
az aks nodepool add \
  --resource-group myAKSResourceGroup \
  --cluster-name myAKSCluster \
  --name spotpool \
  --node-count 2 \
  --priority Spot \
  --eviction-policy Delete \
  --spot-max-price -1 \
  --node-vm-size Standard_DS3_v2

Disaster Recovery: Multi-Region Deployments and Backup

For critical workloads, deploy AKS clusters in multiple regions with traffic manager (Azure Front Door or Traffic Manager) for global load balancing. Use Azure Disks with zone-redundant storage (ZRS) or Azure Files with geo-redundant storage (GRS). For stateful workloads, replicate data asynchronously to the secondary region. Use Velero to backup cluster resources and persistent volumes to Azure Blob Storage in a secondary region. Test failover regularly. For control plane failures, AKS automatically recovers, but you may experience downtime. Have a runbook for manual failover. Consider using Azure Kubernetes Fleet Manager (preview) for multi-cluster management and update orchestration.

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces:
    - '*'
    storageLocation: azure-secondary
    volumeSnapshotLocations:
    - azure-secondary

CI/CD Integration: Deploying to AKS with GitHub Actions

Integrate AKS with your CI/CD pipeline using GitHub Actions, Azure DevOps, or GitLab. Use the azure/aks-set-context action to authenticate and set the kubectl context. Build and push images to Azure Container Registry (ACR), then deploy using kubectl or Helm. Use Helm for complex deployments; store charts in ACR as OCI artifacts. Implement deployment strategies like blue-green or canary using Argo Rollouts or Flagger. Always scan images for vulnerabilities before deployment. Use Azure Policy to enforce that only images from approved registries are deployed. For GitOps, use Flux v2 or Argo CD to sync cluster state from a Git repository.

name: Deploy to AKS
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/docker-login@v1
      with:
        login-server: myregistry.azurecr.io
        username: ${{ secrets.ACR_USERNAME }}
        password: ${{ secrets.ACR_PASSWORD }}
    - run: docker build -t myregistry.azurecr.io/myapp:${{ github.sha }} .
    - run: docker push myregistry.azurecr.io/myapp:${{ github.sha }}
    - uses: azure/aks-set-context@v3
      with:
        resource-group: myAKSResourceGroup
        cluster-name: myAKSCluster
    - uses: azure/k8s-deploy@v4
      with:
        manifests: |
          deployment.yaml
        images: |
          myregistry.azurecr.io/myapp:${{ github.sha }}

Troubleshooting Common AKS Issues

Common issues include: pods stuck in Pending (insufficient resources, PVC not bound), CrashLoopBackOff (application errors), and ImagePullBackOff (wrong image name, registry credentials). Use kubectl describe pod and kubectl logs to diagnose. For node issues, check kubectl get nodes and kubectl describe node. For networking, use kubectl run --rm -it --image=busybox -- sh to test connectivity. For AKS-specific issues, check Azure Resource Health and AKS diagnostics (via Azure Portal). Enable Kubernetes event streaming to Azure Monitor for real-time visibility. For control plane issues, check Azure status page. Always have a rollback plan: keep previous deployment manifests and images.

#!/bin/bash
# Diagnose a failing pod
POD_NAME=$(kubectl get pods -o jsonpath='{.items[0].metadata.name}')
kubectl describe pod $POD_NAME
kubectl logs $POD_NAME --tail=50
# Check events
kubectl get events --sort-by='.lastTimestamp'

AKS Automatic vs AKS Standard: Choosing the Right Cluster Mode

In 2026, AKS offers two cluster modes. AKS Automatic is a new opinionated mode that provides a production-ready baseline with preconfigured defaults for system node pools, security controls, networking, and upgrades. It reduces Day-2 platform management by auto-managing node pools, upgrades, and security baselines. AKS Standard gives you full control over every aspect—node pools, networking, upgrades, and add-ons. Choose AKS Automatic when you want a fast, secure, compliant starting point and are willing to accept opinionated defaults. Choose AKS Standard when you need deep control over cluster infrastructure—custom CNI, specific node pool configurations, or legacy workload compatibility. You cannot switch between modes after creation. For most new production workloads, AKS Automatic is the recommended starting point; you can always create a Standard cluster later if you hit limitations. The best practices apply to both modes, but implementation responsibility differs—Automatic handles more, Standard requires more operator configuration.

az aks create \
  --resource-group prod-rg \
  --name prod-aks-auto \
  --mode automatic \
  --node-count 3 \
  --enable-cluster-autoscaler \
  --min-count 3 \
  --max-count 10 \
  --generate-ssh-keys

Running AI/ML Inference Workloads on AKS

AKS is increasingly used for AI inference workloads. For GPU-based inference, add a GPU node pool with NC-series or ND-series VMs. Use NVIDIA's GPU Operator to manage GPU drivers, device plugins, and monitoring. For CPU-based inference with optimized libraries, use Standard_F-series compute-optimized VMs. For serving large language models, use vLLM or TensorRT-LLM on AKS with GPU node pools and persistent storage for model weights. Azure offers the AKS AI/ML inference add-on that simplifies deployment of models from Azure AI Model Catalog. For production, use horizontal pod autoscaling based on custom metrics (e.g., requests per second or GPU utilization). Use node taints and tolerations to ensure GPU pods only land on GPU nodes. For cost optimization, use spot GPU instances for batch inference. Store models in Azure Container Registry or Azure Blob Storage with the blob CSI driver. Monitor GPU metrics with Azure Monitor container insights or Prometheus with DCGM exporter.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: inference
  template:
    metadata:
      labels:
        app: inference
    spec:
      nodeSelector:
        accelerator: nvidia
      tolerations:
      - key: nvidia.com/gpu
        operator: Exists
        effect: NoSchedule
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        resources:
          limits:
            nvidia.com/gpu: 1
        env:
        - name: MODEL_NAME
          value: "mistral-7b"
        ports:
        - containerPort: 8000

Azure CNI Advanced Features: Dynamic IP and Subnet Scaling

Azure CNI is the recommended network plugin for AKS, and its advanced features in 2026 solve classic problems. Dynamic IP allocation (preview) separates pod IPs from the VNet subnet, reducing IP consumption. Previously, Azure CNI reserved up to 30 IPs per node—a /24 subnet supported only 8 nodes. With dynamic IP allocation, pods get IPs from a separate CIDR, and nodes only need one IP from the VNet. This allows much denser clusters. Subnet scaling allows you to increase the node subnet size after cluster creation—previously impossible without recreating the cluster. For dual-stack networking, AKS now supports IPv4/IPv6 dual-stack with Azure CNI overlay. For large-scale clusters, enable Azure CNI overlay mode which uses an overlay network for pods while keeping node IPs in the VNet. This supports up to 250 nodes and 25,000 pods. In production, use Azure CNI Overlay for large clusters (250+ nodes) and Azure CNI with dynamic IP for clusters needing direct pod-to-Azure-service connectivity.

az aks create \
  --resource-group prod-rg \
  --name prod-aks \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 10.244.0.0/16 \
  --service-cidr 10.0.0.0/16 \
  --dns-service-ip 10.0.0.10 \
  --node-count 3 \
  --enable-cluster-autoscaler \
  --min-count 3 \
  --max-count 50