Microsoft Azure
Intermediate 15 min read Microsoft Azure

Azure Kubernetes Service & Containers

Azure Kubernetes Service (AKS) is managed Kubernetes on Azure: you own the node pool configuration and your workloads, while Microsoft manages the control plane, upgrades and health. Container Registry stores your images close to the cluster. Learn what AKS manages, how node pools and namespaces work, and the basics of deploying a workload.

AKSKubernetescontainernode poolnamespacepoddeploymentserviceACRmanaged Kubernetesscaling
Prerequisites: Azure Virtual Network & Networking
Introduction

What is this?

Azure Kubernetes Service (AKS) is Microsoft's managed Kubernetes offering. It provisions the control plane for you — API server, scheduler and etcd — and lets you manage worker nodes through node pools. You deploy containerized apps as Kubernetes objects: Deployments (replica sets of Pods), Services (stable networking endpoints) and Ingress (routing). Azure Container Registry (ACR) stores the images Kubernetes pulls at deploy time.

Motivation

Why do you need it?

  • Managed Kubernetes removes the hardest ops burden — patching and operating the control plane.
  • Node pools let you scale compute independently, run spot instances, and pin GPU or memory-heavy nodes.
  • Kubernetes gives you self-healing: it restarts failed pods, spreads replicas and scales with the metrics server.
  • AKS is the default answer for 'run containers at scale' on Azure, and the top interview topic for platform work.
  • ACR plus AKS gives a fast, private image supply chain in one region.
Think about it

Mental model

Imagine

A hotel with managed housekeeping and self-run restaurants

Think of

AKS and your containers

AKS is the hotel chain: the building, lobby staff and key-card system (control plane) are run by the brand, while each floor's room service (worker nodes) is yours to staff and clean. A restaurant (your app) books a suite of rooms (Pods) via a floor manager (Deployment) and guests reach it through the front desk (Service). The kitchen larder (Container Registry) holds every recipe (image) the chefs (Pods) pull from when they open.

Mechanics

How it works

  • You create a cluster; Azure provisions the managed control plane and worker nodes in a default node pool.
  • A node pool is a group of identical VMs running containerd; you can add pools with different VM sizes or scale the pool.
  • You apply YAML defining Deployments, Services, and other objects; the scheduler places Pods onto nodes with spare capacity.
  • The kubelet on each node keeps its Pods healthy, restarting them on crashes and evicting them on node problems.
  • ACR stores and signs images; the cluster authenticates with managed identity and pulls them at deploy time.

Deploying a containerized app to AKS via ACR.

Push image to ACR
Cluster pulls the image
Deployment schedules Pods
Service exposes a stable IP
HPA scales replicas
Nodes self-heal
Reference

Key commands

az aks create --resource-group rg-aks --name dev-cluster --node-count 3 --enable-managed-identity

Create a managed AKS cluster with three nodes.

az aks get-credentials --resource-group rg-aks --name dev-cluster

Merge the cluster into your local kubeconfig.

kubectl get nodes

List the worker nodes and their status.

kubectl create deployment nginx --image nginx:1.27

Create a Deployment running nginx.

kubectl scale deployment nginx --replicas 5

Scale the Deployment to five replicas.

az acr create --name devregistry --resource-group rg-aks --sku Basic

Create an Azure Container Registry.

Hands-on

Examples

Create an AKS cluster and deploy a workload

Create an AKS cluster and deploy a workload
$ az group create --name rg-aks --location eastus
$ az aks create --resource-group rg-aks --name dev-cluster \
    --node-count 3 --enable-managed-identity
{
  "fqdn": "dev-cluster-xxxx.hcp.eastus.azmk8s.io",
  "nodeResourceGroup": "MC_rg-aks_dev-cluster_eastus",
  "powerState": "Running"
}
 
$ az aks get-credentials --resource-group rg-aks --name dev-cluster
Merged "dev-cluster" as current context in ~/.kube/config
 
$ kubectl create deployment nginx --image nginx:1.27
deployment.apps/nginx created

az aks create provisions a three-node cluster with a managed control plane. get-credentials merges the cluster into your local kubeconfig so kubectl works immediately. The final command deploys nginx as a Deployment; the scheduler places its Pod on a node and keeps it running.

Real world

In production

  • Run stateless web tiers as Deployments behind a Service and Ingress, with the Horizontal Pod Autoscaler attached.
  • Use separate node pools for general workloads, system Pods, and GPU or memory-intensive jobs.
  • Store images in ACR with geo-replication and vulnerability scanning so the cluster always pulls trusted builds.
  • Pin the cluster to a VNet for private networking and keep the control plane API behind an allowlist or private endpoint.
  • Enforce pod security and quotas at the namespace level so teams cannot consume unbounded resources.
Guidelines

Best practices

  • Set resource requests and limits on every container so the scheduler and HPA have real signals.
  • Use multiple node pools so a spot-pool eviction or a node-type failure does not take down the whole cluster.
  • Upgrade the cluster and node pools regularly and test one pool before rolling the rest.
  • Keep secrets in a managed store (Key Vault via CSI) rather than in ConfigMaps or plain YAML.
  • Apply namespace quotas and RBAC so tenant workloads cannot starve or read each other.
Watch out

Common mistakes

  • Running everything on a single-node cluster and losing the whole app when the node drains.
  • Deploying images tagged latest, so rollbacks and reproducibility become impossible.
  • Forgetting resource limits, then watching one noisy neighbor evict everyone else's Pods.
  • Exposing services as LoadBalancer one per app instead of using one Ingress.
  • Ignoring cluster and node-pool upgrades until a security patch forces a breakneck rollout.
Root cause analysis

Common issues

Error
ImagePullBackOff: ImagePullBackOff (image nginx:1.27)
Root cause

The image does not exist, the tag is wrong, or the cluster cannot authenticate to the registry.

Fix

Verify the image and tag locally with docker pull, then confirm the pull secret or managed identity grants access to ACR.

Error
CrashLoopBackOff on a new Deployment
Root cause

The container exits immediately — missing env, bad command, or a probe failing before readiness.

Fix

Read the previous logs with kubectl logs <pod> --previous and correct the startup command or health probe.

Error
Pods stuck in Pending
Root cause

No node has enough CPU or memory after limits, or a taint blocks scheduling.

Fix

Check kubectl describe pod for '0/3 nodes available' events, raise resources, or add a matching node pool.

When things break

Debugging tips

  • Start with kubectl get events to see why a Pod failed before reading container logs.
  • Use kubectl describe pod to see the status, image pulls and probe results for one Pod.
  • Check CrashLoopBackOff with kubectl logs <pod> --previous for the crashed attempt's output.
  • Verify image pull errors against ACR access — 401/403 usually means a missing managed identity or pull permission.
  • Inspect the node conditions and DiskPressure before blaming application code for Pod evictions.
Interviews

Interview checkpoint

Practice

Hands-on lab

Simulate Deployments, Replicas and Self-Healing
25 min · intermediate
In progress
Objectives
  • Model Pods, nodes and a Deployment as directories
  • Scale replicas and verify the counts
  • Simulate a Pod failure and watch the cluster restart it
  • Route traffic through a stable Service endpoint

Simulate Deployments, Replicas and Self-Healing

25 min · intermediate

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which component of an AKS cluster does Microsoft operate and patch for you?

2

A Deployment must have resource limits set for the Horizontal Pod Autoscaler to work on CPU utilization.

3

A Pod is stuck in Pending after a new Deployment. What is the most likely cause?

Quick reference

Cheat sheet

AKS objects
Node poolGroup of worker VMs, same size and config
PodSmallest unit, runs one or more containers
DeploymentDeclarative replicas of Pods
ServiceStable IP/DNS for a set of Pods
IngressL7 routing to Services
Operate the cluster
az aks get-credentialsMerge cluster into kubeconfig
kubectl scaleChange replica count
HPAAutoscale on utilization
ACRPrivate container registry
NamespaceIsolation + quotas per team
Go deeper

Official documentation

What is Azure Kubernetes Service?
docs
AKS concepts
docs
Node pools in AKS
docs
What is Azure Container Registry?
docs
Deploy an app to AKS
docs