0Pricing
Cloud & IT Cert Prep · Lesson

Deploying Workloads on AKS

Create an AKS cluster, deploy a multi-container application using kubectl and Helm charts, and expose it externally with an Azure Load Balancer service.

Deploying Workloads on AKS is a free Cloud & IT Cert Prep lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cloud & IT Cert Prep learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What Is Azure Kubernetes Service?

Azure Kubernetes Service (AKS) is a managed Kubernetes offering where Microsoft operates and maintains the control plane (API server, etcd, scheduler) at no cost. You only pay for the worker nodes (VMs). AKS handles Kubernetes version upgrades, node OS patching, control plane scaling, and integration with Azure networking, storage, and identity. This dramatically reduces the operational overhead of running Kubernetes in production.

Creating an AKS Cluster

Create an AKS cluster with az aks create, specifying the node count, VM size, and networking options. AKS automatically creates a node resource group containing the VMs, managed disks, NICs, and load balancers. The recommended networking mode is Azure CNI — each pod gets a real VNet IP address, enabling direct connectivity with other Azure services without NAT.

# Create an AKS cluster with 3 nodes
az aks create \
  --name myAKSCluster \
  --resource-group MyRG \
  --location eastus \
  --node-count 3 \
  --node-vm-size Standard_D2s_v3 \
  --enable-managed-identity \
  --attach-acr mycontainerregistry \
  --network-plugin azure \
  --generate-ssh-keys

# Get kubectl credentials
az aks get-credentials --name myAKSCluster --resource-group MyRG

Node Pools

AKS clusters can have multiple node pools — groups of VMs with the same configuration. The system node pool runs critical Kubernetes system components (kube-system pods). User node pools run your application workloads. Separate pools allow you to mix VM SKUs — a general-purpose pool for web apps and a GPU pool for ML workloads — and scale each independently.

# Add a GPU node pool for ML workloads
az aks nodepool add \
  --cluster-name myAKSCluster \
  --resource-group MyRG \
  --name gpupool \
  --node-count 2 \
  --node-vm-size Standard_NC6s_v3 \
  --node-taints sku=gpu:NoSchedule

# List node pools
az aks nodepool list \
  --cluster-name myAKSCluster \
  --resource-group MyRG \
  -o table

Deploying a Multi-Container Application

Deploy a multi-tier application to AKS by writing separate Kubernetes manifest files for each tier and applying them with kubectl apply. A typical deployment includes a Deployment for the web tier, a Deployment for the API tier, Services to connect them, a ConfigMap for environment configuration, and an Ingress resource to expose the app externally via a single hostname.

# Apply all manifests in a directory
kubectl apply -f k8s/

# Or apply individual files
kubectl apply -f frontend-deployment.yaml
kubectl apply -f frontend-service.yaml
kubectl apply -f api-deployment.yaml
kubectl apply -f api-service.yaml
kubectl apply -f ingress.yaml

# Watch rollout status
kubectl rollout status deployment/frontend
kubectl rollout status deployment/api

Ingress and Application Gateway

An Ingress resource defines HTTP routing rules that map hostnames and URL paths to backend services. Unlike a LoadBalancer service (one external IP per service), a single Ingress controller handles all external HTTP traffic and routes it based on rules. In AKS, use the NGINX Ingress Controller or the Application Gateway Ingress Controller (AGIC) to terminate TLS and route traffic to multiple services.

# Ingress routing traffic to two services by path
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
  - hosts: [myapp.contoso.com]
    secretName: myapp-tls
  rules:
  - host: myapp.contoso.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service: {name: api-svc, port: {number: 80}}
      - path: /
        pathType: Prefix
        backend:
          service: {name: frontend-svc, port: {number: 80}}

Helm Charts for Application Packaging

Helm is the package manager for Kubernetes. A chart bundles all the Kubernetes manifests for an application (Deployments, Services, Ingress, ConfigMaps) into a single versioned, parameterisable package. helm install deploys a chart with environment-specific values. The Helm repository on Artifact Hub hosts thousands of pre-built charts for common infrastructure (NGINX, cert-manager, Prometheus, Redis).

# Add the NGINX Ingress Controller chart repo
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Install NGINX Ingress Controller
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace \
  --set controller.replicaCount=2

# Install your own app chart with custom values
helm install myapp ./charts/myapp -f values-prod.yaml

Rolling Updates and Rollbacks

Update a Deployment by changing the container image tag — Kubernetes performs a rolling update, creating new pods with the updated image and terminating old ones gradually, keeping the application available throughout. If the new version is broken, roll back instantly to the previous revision using kubectl rollout undo. Kubernetes keeps a configurable history of revisions for each Deployment.

# Update the image to a new version
kubectl set image deployment/myapp \
  myapp=mycontainerregistry.azurecr.io/myapp:v2.0

# Watch the rollout progress
kubectl rollout status deployment/myapp

# View rollout history
kubectl rollout history deployment/myapp

# Rollback to the previous version
kubectl rollout undo deployment/myapp

# Rollback to a specific revision
kubectl rollout undo deployment/myapp --to-revision=2

Cluster Autoscaler

The Cluster Autoscaler automatically adds or removes worker nodes from an AKS node pool based on pending pod scheduling and node utilisation. When pods cannot be scheduled because all nodes are full, the Cluster Autoscaler provisions new nodes. When nodes are underutilised and pods can be consolidated, it drains and removes nodes. This complements the Horizontal Pod Autoscaler — HPA scales pods, Cluster Autoscaler scales nodes.

# Enable Cluster Autoscaler on the default node pool
az aks update \
  --name myAKSCluster \
  --resource-group MyRG \
  --enable-cluster-autoscaler \
  --min-count 2 \
  --max-count 10

# Update autoscaler bounds on a specific node pool
az aks nodepool update \
  --cluster-name myAKSCluster \
  --resource-group MyRG \
  --name nodepool1 \
  --enable-cluster-autoscaler \
  --min-count 3 \
  --max-count 20

AKS Monitoring with Azure Monitor

Enable Azure Monitor Container Insights to collect logs and metrics from your AKS cluster without deploying third-party monitoring tools. Container Insights provides pre-built dashboards for cluster health, node and pod CPU/memory, container logs, and live pod streaming. It integrates with Prometheus for custom metrics scraping and allows querying all data using KQL in Log Analytics.

# Enable Azure Monitor Container Insights on AKS
az aks enable-addons \
  --addons monitoring \
  --name myAKSCluster \
  --resource-group MyRG \
  --workspace-resource-id /subscriptions/.../workspaces/MyLogAnalytics

# Stream live logs from a running pod
kubectl logs -f deployment/myapp -c myapp

# Query pod resource usage
kubectl top pods --namespace default

AKS RBAC and Azure Active Directory

Integrate AKS with Microsoft Entra ID to use Azure AD users and groups for Kubernetes RBAC. Instead of managing separate Kubernetes user accounts, you assign ClusterRole or Role bindings to Entra ID object IDs. When a developer runs kubectl, AKS validates their Entra ID token. This provides centralised identity management and integrates with conditional access and MFA policies.

# Enable Entra ID RBAC on an AKS cluster
az aks update \
  --name myAKSCluster \
  --resource-group MyRG \
  --enable-azure-rbac

# Assign a built-in AKS role to an Entra group
az role assignment create \
  --role 'Azure Kubernetes Service RBAC Reader' \
  --assignee '<Entra-Group-Object-ID>' \
  --scope /subscriptions/.../resourceGroups/MyRG/providers/Microsoft.ContainerService/managedClusters/myAKSCluster

Network Policies for Pod-Level Security

Network policies are Kubernetes resources that control which pods can communicate with each other. By default, all pods in a cluster can reach all other pods — network policies provide a firewall at the pod level. On AKS, enable Azure network policy or Calico to enforce policies. A common pattern is a default-deny policy that blocks all inter-pod traffic, then explicit allow policies for the specific paths your app needs.

# Default deny all ingress to pods in namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}  # Matches all pods
  policyTypes:
  - Ingress

# Allow API pods to receive from frontend pods only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-frontend
spec:
  podSelector: {matchLabels: {app: api}}
  ingress:
  - from:
    - podSelector: {matchLabels: {app: frontend}}

Quick Check

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

Lesson Recap

In this lesson you learned: AKS is a managed Kubernetes service where Microsoft operates the control plane, Helm charts package multi-resource Kubernetes applications for repeatable deployment, and the Cluster Autoscaler dynamically adds and removes nodes based on pod scheduling demand. Next up we explore Azure Functions triggers and bindings.

Frequently asked questions

Is the “Deploying Workloads on AKS” lesson free?

Yes — the full text of “Deploying Workloads on AKS” is free to read here on the web, and the Cloud & IT Cert Prep course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cloud & IT Cert Prep course, upgrade to CoddyKit PRO.

What will I learn in “Deploying Workloads on AKS”?

Create an AKS cluster, deploy a multi-container application using kubectl and Helm charts, and expose it externally with an Azure Load Balancer service. You practise Cloud & IT Cert Prep with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Cloud & IT Cert Prep?

No prior experience is required. Cloud & IT Cert Prep on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Deploying Workloads on AKS” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Cloud & IT Cert Prep lesson?

Yes. Every Cloud & IT Cert Prep lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Azure Container Registry
  2. Azure Container Instances
  3. Kubernetes Concepts for Azure
  4. Deploying Workloads on AKS
← Back to Cloud & IT Cert Prep