AKS for Azure Developers

Azure Kubernetes Service (AKS) is a managed container orchestration service based on the open-source Kubernetes system. Kubernetes, often abbreviated as K8s, is a platform for automating the deployment, scaling, and management of containerized applications. AKS abstracts the complexity of managing the Kubernetes control plane, which is fully managed by Azure. This means you do not need to worry about the API server, etcd, scheduler, or controller manager – Azure handles their availability, scaling, and patching. You only manage the worker nodes (agent nodes) and your applications.

AKS exists because running a production-grade Kubernetes cluster is operationally intensive. You need to manage the control plane, handle upgrades, patch nodes, and ensure high availability. AKS reduces this burden by providing a managed control plane, automated node upgrades, self-healing (node repair), and integration with Azure Active Directory, Azure Policy, and Azure Monitor. For the AZ-204 exam, you need to understand how to create an AKS cluster, deploy applications, configure scaling, and integrate with other Azure services like Azure Container Registry (ACR) and Azure DevOps.

AKS deploys a Kubernetes cluster where Azure manages the control plane (master components) and you manage the worker nodes. The control plane is hosted in a separate Azure subscription and is not directly accessible to you. You interact with it through the Kubernetes API server endpoint, which is exposed over the internet or via a private endpoint. The worker nodes are virtual machines (VMs) that run the kubelet, kube-proxy, and container runtime (containerd).

When you create an AKS cluster, you specify the number and size of worker nodes. Azure deploys these VMs into a virtual network (VNet) that you can control. The nodes automatically register with the control plane. You then use kubectl to deploy your containerized applications as Kubernetes resources: pods, deployments, services, etc.

Create an AKS cluster (Azure CLI):

az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --node-count 3 \
  --enable-addons monitoring \
  --generate-ssh-keys

Get credentials to connect to the cluster:

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Verify nodes:

kubectl get nodes

Deploy an application (using a deployment YAML):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Expose the deployment as a service:

kubectl expose deployment nginx-deployment --type=LoadBalancer --name=nginx-service --port=80 --target-port=80

Check service:

kubectl get service nginx-service

Scale the deployment:

kubectl scale deployment nginx-deployment --replicas=5

Upgrade the cluster:

az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version 1.21.2

A financial services company migrated from a monolithic application to microservices using AKS. They had 50+ microservices, each deployed as a separate deployment in a dedicated namespace. They used Azure DevOps for CI/CD, building container images and pushing to ACR, then deploying to AKS via Helm charts. They configured cluster autoscaler to handle peak trading hours, scaling from 5 to 20 nodes. They used Azure Policy to enforce pod security standards (e.g., disallow privileged containers). Network policies restricted traffic between services. They used Azure CNI for direct pod-to-Azure SQL connectivity. A common issue was IP exhaustion – they had to plan the VNet CIDR carefully. They also set up pod disruption budgets to ensure high availability during upgrades.

A media processing company used AKS for batch video transcoding. They had a baseline cluster of 3 nodes for the control plane and management workloads. For burst processing, they enabled virtual nodes (ACI) which allowed pods to run on Azure Container Instances without provisioning new VMs. They used a node selector to schedule transcoding pods on virtual nodes. This saved costs because ACI charges per second. They used Azure Files for shared storage. The challenge was that virtual nodes have limitations (e.g., no host networking, no privileged containers). They also had to ensure the ACI subnet had enough IPs.

A large e-commerce retailer used AKS for their web application and order processing. They had a multi-region deployment for disaster recovery. They used Azure Traffic Manager to route traffic to the closest region. Each region had an AKS cluster with Application Gateway Ingress Controller (AGIC) for SSL termination and WAF. They used Azure Redis Cache for session state and Azure SQL Database for persistent data. They used Helm for deployments and Azure Policy for compliance. They encountered issues with slow rolling updates due to health probe timeouts – they tuned liveness and readiness probes. They also used pod anti-affinity to spread pods across nodes for high availability.