Azure Kubernetes Service
AKS is Microsoft’s managed Kubernetes. Azure runs the control plane; you run your workloads on node pools.
On this page · 5 min · Advanced
On this page
- Learning objectives
- Explanation
- Code example
- Step by step
- Real-world use
- Common mistakes
- Best practices
- Remember this
- Practice exercise
- Mini quiz
- Related topics
- My notes
- Reading time
- 5 min
- Difficulty
- Advanced
- Updated
- Oct 29, 2026
Related tutorials
Learning objectives#
- Create an AKS cluster attached to ACR
- Connect with kubectl
- Deploy a Deployment and a Service
- Scale pods and nodes
Explanation#
Kubernetes schedules containers (in pods) across a pool of VMs (nodes). AKS manages the control plane for you; you choose node sizes and counts.
A Deployment keeps a desired number of pod replicas running and handles rolling updates. A Service gives the pods a stable address; type LoadBalancer exposes it publicly.
Scale pods with kubectl scale or the Horizontal Pod Autoscaler; scale nodes with the cluster autoscaler.
AKS is powerful but demands Kubernetes skills. For simpler container hosting, consider Azure Container Apps first.
Code example: Deploying an API to AKS#
# az aks create -g rg-shop -n aks-shop --node-count 2 --generate-ssh-keys --attach-acr acrshop12345
# az aks get-credentials -g rg-shop -n aks-shop
apiVersion: apps/v1
kind: Deployment
metadata: { name: shop-api }
spec:
replicas: 3
selector: { matchLabels: { app: shop-api } }
template:
metadata: { labels: { app: shop-api } }
spec:
containers:
- name: api
image: acrshop12345.azurecr.io/shop-api:1.0.0
ports: [{ containerPort: 8080 }]
resources: { requests: { cpu: 100m, memory: 128Mi }, limits: { memory: 256Mi } }
---
apiVersion: v1
kind: Service
metadata: { name: shop-api }
spec:
type: LoadBalancer
selector: { app: shop-api }
ports: [{ port: 80, targetPort: 8080 }]
# kubectl apply -f shop-api.yaml && kubectl get svc shop-api
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) shop-api LoadBalancer 10.0.142.17 20.xxx.xxx.xx 80:31540/TCP
This example is illustrative. Copy or download it and run it in your own environment; the expected output is shown above.
Step-by-step explanation#
- --attach-acr lets the cluster pull from your registry.
- get-credentials configures kubectl for the cluster.
- The Deployment runs three replicas with resource requests and limits.
- The LoadBalancer Service gets a public IP and forwards port 80 to the containers’ 8080.
Real-world use case#
Large platforms with many services, custom networking or Kubernetes tooling (Helm, operators) use AKS.
Common mistakes#
Pods without requests make scheduling unpredictable and can starve neighbours.
Cluster management overhead is significant. Container Apps or App Service may be simpler.
Best practices#
- Set resource requests and limits
- Use managed identities and Entra integration
- Enable the cluster autoscaler
- Use an ingress controller with TLS for HTTP apps
Remember this#
Pod = running container(s). Deployment = keep N pods running. Service = stable address.
Azure runs the control plane; you run node pools.
Small app? Try Container Apps first.
Practice exercise#
Your task: Scale shop-api to 5 replicas and watch the pods.
Show solution
kubectl scale deployment shop-api --replicas=5
kubectl get pods -l app=shop-api -w
Mini quiz#
Which Kubernetes object gives pods a stable network address?
Want more? Practise all Microsoft Azure MCQs · Microsoft Azure interview questions
My notes#
Saved in this browser.