AKS

Azure Kubernetes Service is managed control-plane Kubernetes with Azure-native networking, identity, storage, and observability integrations. Node pools separate system and user workloads; cluster autoscaler adds nodes; workload identity replaces long-lived secrets for pod-to-Azure access.

| Area | Azure-specific hook | |------|---------------------| | ACR | Pull images with managed identity or attach registry | | Azure CNI | Pods get VNet IPs; plan IP space carefully | | Application Gateway Ingress | L7 routing with WAF option | | Azure Monitor | Container Insights for metrics and logs |

					apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  template:
    spec:
      serviceAccountName: api-sa
      containers:
        - name: node
          image: myacr.azurecr.io/api:1.0.0
				

On interviews: when AKS beats App Service; node pool sizing and upgrades; pod identity vs service principal secrets; network policy defaults; and how you would debug CrashLoopBackOff in production.

Common pitfalls: undersized IP ranges with Azure CNI; running everything in the default node pool; no Pod Disruption Budgets during upgrades; and cluster-admin kubeconfig shared broadly in CI.

The trade-off is Kubernetes portability and fine-grained control versus operational complexity, upgrade cadence, and the cost of skilled platform ownership.

Checklist:

• Separate system and user node pools.
• Use workload identity for Azure resource access.
• Set requests/limits and readiness probes on every app.
• Plan VNet IP capacity before scale-out.
• Automate cluster and node image upgrades with rollback.