Prerequisites
- Azure CLI installed and logged in (
az login) - kubectl installed (
az aks install-cli) - Sufficient quota for VM cores in target region
- Resource group created
Create the Cluster
Azure CLICreate AKS cluster
# Create resource group
az group create --name myRG --location centralindia
# Create AKS cluster (Standard_DS2_v2 nodes, 3 nodes, Azure CNI)
az aks create \
--resource-group myRG \
--name myAKSCluster \
--node-count 3 \
--node-vm-size Standard_DS2_v2 \
--network-plugin azure \
--enable-managed-identity \
--attach-acr myregistry2026 \
--zones 1 2 3 \
--generate-ssh-keys
# This takes 5-10 minutesKey Parameters Explained
| Parameter | What It Does |
|---|---|
--node-count 3 | 3 worker nodes in the system node pool |
--node-vm-size | VM size for worker nodes — affects CPU, memory, cost |
--network-plugin azure | Use Azure CNI — pods get real VNet IPs |
--enable-managed-identity | Use Managed Identity instead of service principal |
--attach-acr | Grant AKS permission to pull from this ACR |
--zones 1 2 3 | Spread nodes across 3 Availability Zones for HA |
Connect with kubectl
Azure CLIGet credentials and connect
# Get credentials — merges into ~/.kube/config
az aks get-credentials \
--resource-group myRG \
--name myAKSCluster
# Verify connection
kubectl get nodes
# Output:
# NAME STATUS ROLES AGE VERSION
# aks-nodepool1-12345678-vmss000000 Ready agent 5m v1.29.0
# aks-nodepool1-12345678-vmss000001 Ready agent 5m v1.29.0
# aks-nodepool1-12345678-vmss000002 Ready agent 5m v1.29.0az aks get-credentials This command downloads the cluster credentials and merges them into your local kubeconfig file (
~/.kube/config). After running this, kubectl commands target this AKS cluster automatically.Verify Cluster Health
kubectlVerify cluster health
# Check all nodes are Ready
kubectl get nodes
# Check system pods are running
kubectl get pods --namespace kube-system
# Check cluster info
kubectl cluster-info
# Check node resource usage
kubectl top nodesAdd a Node Pool
Azure CLIAdd user node pool for application workloads
# Add a user node pool with larger VMs for compute-intensive workloads
az aks nodepool add \
--resource-group myRG \
--cluster-name myAKSCluster \
--name appnodepool \
--node-count 2 \
--node-vm-size Standard_DS4_v2 \
--zones 1 2 3 \
--mode User
# List node pools
az aks nodepool list \
--resource-group myRG \
--cluster-name myAKSCluster \
--output tableUpgrade AKS Version
Azure CLICheck and apply AKS upgrades
# Check available upgrade versions
az aks get-upgrades \
--resource-group myRG \
--name myAKSCluster \
--output table
# Upgrade to a new version (control plane + all node pools)
az aks upgrade \
--resource-group myRG \
--name myAKSCluster \
--kubernetes-version 1.30.0Upgrade Causes Brief Disruption AKS upgrades nodes one at a time (rolling upgrade). With 3+ nodes, there is minimal disruption — one node is cordoned, drained, upgraded, then uncordoned before the next node is touched. Always test upgrades in a dev cluster first.
Key Decisions When Creating
| Decision | Recommendation |
|---|---|
| VM size | Standard_DS2_v2 for general workloads, larger for memory-intensive apps |
| Node count | Minimum 3 for HA — use auto-scale for variable workloads |
| Availability Zones | Always use zones 1, 2, 3 for production — protects against zone failure |
| Network plugin | Azure CNI for enterprise and VNet integration; Kubenet for simple clusters |
| Managed Identity | Always use — avoids managing service principal credentials |
AZ-104 Exam Tip Know that
az aks get-credentials configures kubectl to connect to the cluster. Know that --zones 1 2 3 enables zone-redundant node distribution. Know that upgrades are rolling — nodes are upgraded one at a time. Know that system node pools are required and user node pools are optional.