Azure Kubernetes Service (AKS): deploy containers on Azure step by step.

AKS mental model: Azure runs the control plane; your workloads run on nodes

Azure Kubernetes Service is a managed Kubernetes service. Kubernetes still supplies the scheduling, reconciliation and service-discovery model, while Azure operates the cluster control plane. The API server accepts desired state, the scheduler selects a node for each pending pod, and controllers continually compare the actual state with the declared state.

Your application containers run on worker nodes in node pools. A system node pool hosts critical system pods; additional user node pools can isolate application workloads by operating system, VM size, availability requirements, labels and taints. Managed does not mean responsibility-free: you choose workload configuration, identity, network exposure, capacity, health probes, upgrade strategy, data protection and observability.

Follow the request and image paths through the architecture

Know what each Kubernetes object contributes

Five-stage workflow: image to running Azure application

1. Build and push a versioned image

Use a meaningful immutable tag such as a commit identifier rather than relying on latest. Scan the image, keep the runtime small and avoid embedding credentials. Push it to ACR, where the deployment pipeline and AKS identity can retrieve it.

az acr build --registry myregistry --image web:1.0.0 .

az acr repository show-tags --name myregistry --repository web --output table

2. Create AKS and authorize ACR pulls

The learning example below uses Azure CLI. Names, region, identity, networking and node sizing must be adapted to the environment. For production, evaluate the AKS baseline architecture instead of accepting quickstart defaults.

az group create --name rg-aks-study --location eastus

az aks create \
  --resource-group rg-aks-study \
  --name aks-study \
  --node-count 3 \
  --generate-ssh-keys \
  --attach-acr myregistry

az aks get-credentials --resource-group rg-aks-study --name aks-study
kubectl get nodes

--attach-acr configures registry pull integration for a supported setup. In controlled environments, explicitly verify the cluster identity and its least-privilege role assignment at ACR scope.

Declare the workload with a Deployment and Service

The Deployment below asks Kubernetes to keep three application replicas available. Readiness and liveness probes serve different purposes: readiness controls whether a pod receives traffic; liveness can restart a stuck container. Resource requests influence scheduling, while limits cap resource use.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: myregistry.azurecr.io/web:1.0.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet: { path: /ready, port: 8080 }
          livenessProbe:
            httpGet: { path: /health, port: 8080 }
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits: { cpu: 500m, memory: 512Mi }
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080
  type: LoadBalancer

Apply and observe the rollout instead of assuming success:

kubectl apply -f web.yaml
kubectl rollout status deployment/web
kubectl get pods -o wide
kubectl get service web
kubectl get events --sort-by=.lastTimestamp

Production readiness: go beyond a successful kubectl apply

Troubleshoot AKS from symptoms to evidence

kubectl describe pod POD_NAME
kubectl logs POD_NAME --previous
kubectl get deployment,replicaset,pod,service,endpoints
kubectl describe service web
kubectl top pods
kubectl get events --sort-by=.lastTimestamp

Change one hypothesis at a time. Scaling a broken image creates more broken replicas; opening every port hides the real network fault; increasing node size does not repair a selector mismatch.

AZ-104 decision cues for containers

• Managed Kubernetes orchestration: choose AKS when the requirement needs Kubernetes APIs, scheduling and cluster-level control.
• Image storage: choose ACR for private Azure container images and authorize pull access with an identity.
• Desired replicas and rolling updates: use a Deployment rather than creating individual pods.
• Stable pod access: use a Service; pod addresses are replaceable.
• HTTP host/path routing: evaluate an Ingress controller and Ingress rules.
• Pod demand versus node capacity: distinguish horizontal pod scaling from cluster/node-pool scaling.
• Operational evidence: use pod events, logs, metrics and Azure monitoring instead of guessing.

Frequently asked questions

Official Microsoft references

Use Microsoft documentation as the authority for current behavior and exam scope: the AKS core concepts, AKS Azure CLI quickstart, AKS shared-responsibility and support policies, and the current AZ-104 study guide.