AKS Hands-On Lab

Your Namespace

—

10 min

Node Pools & Workload Separation

Step 2 — Inspect Node Pools

List all node pools:

az aks nodepool list \
  --resource-group $AKS_RG \
  --cluster-name $AKS_CLUSTER \
  --query "[].{Name:name, Mode:mode, VMSize:vmSize, Count:count}" \
  --output table

See how system nodes are tainted — user workloads can't be scheduled there:

kubectl get nodes -o custom-columns=\
"NAME:.metadata.name,\
ROLE:.metadata.labels.kubernetes\.azure\.com/role,\
TAINTS:.spec.taints"

List pods running on system nodes (kube-system):

kubectl get pods -n kube-system \
  -o wide --sort-by='.spec.nodeName' | head -20

Step 3 — Deploy a Workload to User Pool

Create a deployment in your namespace:

kubectl create deployment hello-aks \
  --image=mcr.microsoft.com/azuredocs/aks-helloworld:v1 \
  --replicas=2 \
  --namespace=$MY_NS

Verify the pods landed on user nodes, not system nodes:
```
kubectl get pods -n $MY_NS -o wide
```
Compare the node name to the system nodes listed in step 2.

Expose the deployment:

kubectl expose deployment hello-aks \
  --port=80 --target-port=80 \
  --type=ClusterIP \
  --namespace=$MY_NS

Step 4 — Try Forcing a Pod to the System Pool

Apply this manifest that tries to schedule on system nodes:

kubectl apply -n $MY_NS -f - <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: system-pool-attempt
spec:
  nodeSelector:
    kubernetes.azure.com/role: system
  containers:
  - name: test
    image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
EOF

Check the pod status — it should be Pending due to the system taint:

kubectl get pod system-pool-attempt -n $MY_NS
kubectl describe pod system-pool-attempt -n $MY_NS | grep -A5 Events:

Clean up:

kubectl delete pod system-pool-attempt -n $MY_NS --ignore-not-found

10 min

Managed System Pools & Upgrade Channels

Step 2 — Configure a Maintenance Window

Azure lets you schedule when upgrades happen. Best practice: Saturday early morning to avoid business hours.

Create a maintenance configuration:

az aks maintenanceconfiguration add \
  --resource-group $AKS_RG \
  --cluster-name $AKS_CLUSTER \
  --name aksManagedAutoUpgradeSchedule \
  --schedule-type Weekly \
  --day-of-week Saturday \
  --start-time "02:00" \
  --duration 4 \
  --utc-offset "+05:30"

Confirm the maintenance window was set:

az aks maintenanceconfiguration list \
  --resource-group $AKS_RG \
  --cluster-name $AKS_CLUSTER \
  --output table

Step 3 — Node OS Upgrade Channel

Check the current node OS upgrade channel:

az aks show \
  --resource-group $AKS_RG \
  --name $AKS_CLUSTER \
  --query "autoUpgradeProfile.nodeOsUpgradeChannel" \
  --output tsv

Understand the difference:

# NodeImage: updates the underlying VM OS image (security patches)
# SecurityPatch: only OS security patches, preserves node config
# None: manual OS upgrades only

With upgrade channels + maintenance windows, Azure handles:
- Kubernetes version patches (patch channel)
- Node OS security updates (NodeImage channel)
- At the scheduled maintenance window

Step 4 — Node Surge During Upgrades

AKS upgrades nodes by adding a surge node, draining the old node, then removing it. Increase max-surge to speed up upgrades at the cost of extra VM capacity.

See current max-surge setting:

az aks nodepool show \
  --resource-group $AKS_RG \
  --cluster-name $AKS_CLUSTER \
  --name systempool \
  --query "upgradeSettings" \
  --output json

Update max-surge to allow 1 extra node during upgrades:

az aks nodepool update \
  --resource-group $AKS_RG \
  --cluster-name $AKS_CLUSTER \
  --name systempool \
  --max-surge 1

20 min

AKS Automatic: Create & Compare

Step 2 — What Azure Pre-Configured

Check upgrade settings — should be rapid + NodeImage:

az aks show \
  --resource-group $AKS_RG \
  --name $AKS_AUTO \
  --query "{upgrade:autoUpgradeProfile, network:networkProfile.networkPlugin}" \
  --output json

Check Node Auto-Provisioning (NAP) is enabled:

az aks show \
  --resource-group $AKS_RG \
  --name $AKS_AUTO \
  --query "nodeProvisioningProfile" \
  --output json

Check built-in Azure Policy:

az aks show \
  --resource-group $AKS_RG \
  --name $AKS_AUTO \
  --query "addonProfiles.azurePolicy.enabled" \
  --output tsv

No static user pools — NAP provisions nodes on demand:

az aks nodepool list \
  --resource-group $AKS_RG \
  --cluster-name $AKS_AUTO \
  --output table

Step 3 — Deploy an App, Watch NAP Provision Nodes

Create your namespace on the Automatic cluster:

kubectl create namespace $MY_NS --dry-run=client -o yaml | kubectl apply -f -

Deploy the AKS Store demo:

kubectl apply -n $MY_NS -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/main/aks-store-quickstart.yaml

Watch NAP provision a node exactly sized for the app:

# In one terminal:
kubectl get nodes -w

# In another:
kubectl get pods -n $MY_NS -w

See what VM SKU NAP chose:

kubectl get nodes \
  -o custom-columns=\
"NAME:.metadata.name,\
INSTANCE:.metadata.labels.node\.kubernetes\.io/instance-type,\
ZONE:.metadata.labels.topology\.kubernetes\.io/zone"

Step 4 — Test Built-In Security Policies

Try deploying a privileged pod — should be denied:

kubectl apply -n $MY_NS -f - <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: priv-test
spec:
  containers:
  - name: test
    image: nginx:alpine
    securityContext:
      privileged: true
EOF

Azure Policy prevents this automatically. Clean up:

kubectl delete pod priv-test -n $MY_NS --ignore-not-found

15 min

Node Auto-Provisioning & Intelligent Scaling

Step 1 — Inspect the Karpenter NodePool CRD

Make sure you're on the Automatic cluster:

kubectl config current-context
# Should be aks-piquant-lab-auto

List Karpenter node pools:
```
kubectl get nodepools
```
Inspect provisioning policy:
```
kubectl describe nodepool default | head -60
```
Look for requirements (SKU families allowed), disruption (consolidation policy), and limits.

Step 2 — Deploy Workloads with Different Resource Profiles

Apply the scaling demo with three sizes:

kubectl apply -n $MY_NS -f - <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: small-app
spec:
  replicas: 3
  selector: {matchLabels: {app: small-app}}
  template:
    metadata: {labels: {app: small-app}}
    spec:
      containers:
      - name: app
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        resources:
          requests: {cpu: 100m, memory: 128Mi}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: large-app
spec:
  replicas: 1
  selector: {matchLabels: {app: large-app}}
  template:
    metadata: {labels: {app: large-app}}
    spec:
      containers:
      - name: app
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        resources:
          requests: {cpu: 2000m, memory: 4Gi}
EOF

Watch NAP provision different-sized nodes:

kubectl get nodes -w &
kubectl get pods -n $MY_NS -w

After pods are Running, compare the node types:

kubectl get nodes \
  -o custom-columns=\
"NODE:.metadata.name,\
INSTANCE:.metadata.labels.node\.kubernetes\.io/instance-type,\
CPU:.metadata.labels.karpenter\.azure\.com/sku-cpu,\
MEM:.metadata.labels.karpenter\.azure\.com/sku-memory-gb"

Step 3 — Scale-Out & Consolidation

Scale the large workload up — NAP adds nodes automatically:

kubectl scale deployment large-app \
  -n $MY_NS --replicas=5
kubectl get nodes -w

Scale back down — Karpenter consolidates in seconds:

kubectl scale deployment large-app \
  -n $MY_NS --replicas=1
# Watch nodes removed (vs 10+ min with cluster autoscaler)
kubectl get nodes -w

Verify consolidation events:

kubectl get events --all-namespaces \
  --field-selector reason=Disrupted \
  --sort-by='.lastTimestamp' | tail -10

Step 4 — Compare with Standard Cluster Autoscaler

Switch back to the standard cluster:

az aks get-credentials \
  --resource-group $AKS_RG \
  --name $AKS_CLUSTER \
  --overwrite-existing

See fixed node pool config — every node is the same SKU:

az aks nodepool list \
  --resource-group $AKS_RG \
  --cluster-name $AKS_CLUSTER \
  --query "[].{Name:name, MinCount:minCount, MaxCount:maxCount, VMSize:vmSize}" \
  --output table

With cluster autoscaler, you'd need a separate node pool for each VM SKU. NAP eliminates this entirely.

Getting Started

Your personal namespace is being provisioned on the AKS cluster. Follow these steps to connect kubectl from your terminal or cloud shell.

Download your kubeconfig

Click Download kubeconfig in the sidebar. This file contains a scoped token valid for 8 hours.

Install the kubeconfig

mkdir -p ~/.kube
mv ~/Downloads/kubeconfig-*.yaml ~/.kube/aks-lab.yaml
chmod 600 ~/.kube/aks-lab.yaml

Export environment variables

export KUBECONFIG=~/.kube/aks-lab.yaml
export MY_NS=aks-lab-...

Verify connection

kubectl get pods -n $MY_NS
kubectl auth can-i create deployments -n $MY_NS

Both commands should succeed. Now open E1 in the sidebar to begin Exercise 1.

Need Azure CLI access? Log in with the credentials your instructor provided:

az login --use-device-code
# Or if SP credentials were provided:
az login --service-principal -u $APP_ID -p $APP_SECRET --tenant $TENANT_ID

Lab Overview

Four exercises covering the AKS operational journey — 45–60 minutes total.

E1	Node Pools & Workload Separation — system vs user pools, scheduling constraints	10 min
E2	Managed System Pools & Upgrade Channels — patch/stable/rapid channels, maintenance windows	10 min
E3	AKS Automatic — `--sku automatic`, NAP on-demand nodes, built-in security policies	20 min
E4	Node Auto-Provisioning — Karpenter right-sizing, scale-out, consolidation vs cluster autoscaler	15 min

Resource Group	—
Location	—
Upgrade	patch channel
Node Scaling	Cluster autoscaler

Resource Group	RG-piquant-labs
SKU	automatic
Upgrade	rapid channel
Node Scaling	Node Auto-Provisioning (Karpenter)

Join the Lab

Getting Started

—

—

Lab Overview