0Pricing
Cloud & IT Cert Prep · Lesson

Kubernetes Concepts for Azure

Review core Kubernetes constructs — pods, deployments, services, and namespaces — and understand how AKS manages the control plane on your behalf.

Kubernetes Concepts for Azure is a free Cloud & IT Cert Prep lesson on CoddyKit — lesson 3 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 Kubernetes?

Kubernetes (K8s) is an open-source container orchestration platform originally developed by Google. It automates the deployment, scaling, and management of containerised applications. Rather than running containers manually, you declare the desired state of your application in YAML manifests, and Kubernetes continuously works to match the actual state to the desired state — restarting failed containers, scheduling workloads on healthy nodes, and scaling replicas.

Cluster Architecture: Control Plane and Nodes

A Kubernetes cluster consists of a control plane and worker nodes. The control plane contains the API server (entry point for all kubectl commands), etcd (distributed state store), scheduler (assigns pods to nodes), and controller manager (maintains desired state). Worker nodes run the kubelet (node agent), kube-proxy (network rules), and a container runtime (containerd). In AKS, Microsoft manages the control plane — you only manage the worker nodes.

# Kubernetes control plane components
# kube-apiserver    - REST API for all cluster operations
# etcd              - Distributed key-value store (cluster state)
# kube-scheduler    - Assigns pending pods to nodes
# kube-controller-manager  - Runs reconciliation controllers

# Worker node components
# kubelet           - Node agent, ensures containers run
# kube-proxy        - Network routing for services
# containerd        - Container runtime (runs containers)

Pods: The Smallest Deployable Unit

A pod is the smallest deployable unit in Kubernetes. A pod wraps one or more containers that share a network namespace (same IP address), storage volumes, and lifecycle. Containers within a pod communicate over localhost. Pods are ephemeral — when they fail, they are replaced by new pods with different IPs. You rarely create pods directly; instead you create higher-level resources that manage pods.

# Simple pod manifest
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: mycontainerregistry.azurecr.io/myapp:v1.0
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: '100m'
        memory: '128Mi'
      limits:
        cpu: '500m'
        memory: '512Mi'

Deployments: Managing Replica Sets

A Deployment is the standard way to run stateless applications in Kubernetes. It creates and manages a ReplicaSet that maintains the desired number of identical pod replicas. Deployments support rolling updates — gradually replacing old pods with new ones — and rollbacks to previous versions. You describe the desired pod template and replica count; Kubernetes handles the rest.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1       # Create 1 extra pod during update
      maxUnavailable: 0 # Never reduce below desired count
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: mycontainerregistry.azurecr.io/myapp:v1.0
        ports:
        - containerPort: 80

Services: Stable Network Endpoints

Since pods are ephemeral and their IPs change, Services provide a stable network endpoint that load-balances traffic across matching pods. The service uses a label selector to find pods. Service types: ClusterIP (internal only, default), NodePort (exposes a port on every node), LoadBalancer (provisions an Azure Load Balancer with a public IP), and ExternalName (DNS alias to an external service).

# Service exposing myapp pods externally
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  type: LoadBalancer  # Creates Azure Load Balancer
  selector:
    app: myapp        # Routes traffic to pods with this label
  ports:
  - port: 80          # Service port
    targetPort: 80    # Pod/container port

# After creation, check the EXTERNAL-IP (Azure LB public IP)
# kubectl get service myapp-svc

Namespaces for Multi-Tenancy

Namespaces partition a single Kubernetes cluster into multiple virtual clusters. Resources in different namespaces are isolated by name — you can have a myapp Deployment in both the development and production namespaces simultaneously. Namespaces are the primary unit for applying RBAC, resource quotas, and network policies to a team or environment. Default namespaces include default, kube-system, and kube-public.

# Create a namespace for the dev team
kubectl create namespace dev-team

# Deploy into a specific namespace
kubectl apply -f deployment.yaml --namespace dev-team

# List all resources in a namespace
kubectl get all --namespace dev-team

# Set default namespace for current context
kubectl config set-context --current --namespace dev-team

ConfigMaps and Secrets

ConfigMaps store non-sensitive configuration data as key-value pairs or files, injected into pods as environment variables or volume mounts. Secrets store sensitive data (passwords, tokens) base64-encoded (not encrypted by default — use Azure Key Vault Provider for Secrets Store CSI Driver for true encryption at rest). Both are namespace-scoped and referenced in pod specs by name.

# Create a ConfigMap from literal values
kubectl create configmap app-config \
  --from-literal=APP_ENV=production \
  --from-literal=LOG_LEVEL=info

# Create a Secret
kubectl create secret generic db-secret \
  --from-literal=DB_PASSWORD='super-secret'

# Reference in a pod spec
# env:
# - name: APP_ENV
#   valueFrom:
#     configMapKeyRef:
#       name: app-config
#       key: APP_ENV
# - name: DB_PASSWORD
#   valueFrom:
#     secretKeyRef:
#       name: db-secret
#       key: DB_PASSWORD

Persistent Volumes on Azure

Stateful applications need storage that outlives individual pods. Kubernetes uses PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs) to decouple storage from pod lifecycle. On AKS, the built-in Azure Disk and Azure Files storage classes provision managed disks and file shares automatically when a PVC is created. Azure Disk is for single-pod access; Azure Files supports multiple pods reading/writing simultaneously.

# PersistentVolumeClaim using Azure Disk
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-disk-pvc
spec:
  accessModes:
  - ReadWriteOnce   # Single-node read/write (Azure Disk)
  storageClassName: managed-csi
  resources:
    requests:
      storage: 10Gi

# Mount in a pod
# volumes:
# - name: data
#   persistentVolumeClaim:
#     claimName: my-disk-pvc
# volumeMounts:
# - name: data
#   mountPath: /data

Horizontal Pod Autoscaler

The Horizontal Pod Autoscaler (HPA) automatically adjusts the number of pod replicas in a Deployment based on observed CPU/memory utilisation or custom metrics. The HPA controller queries the metrics server every 15 seconds and scales replicas up or down to keep utilisation near the target. You set minimum and maximum replica counts as guardrails to prevent runaway scaling.

# Create an HPA targeting 50% CPU utilisation
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Health Checks: Liveness and Readiness Probes

Kubernetes uses probes to monitor container health. A liveness probe checks if a container is still running — if it fails, Kubernetes restarts the container. A readiness probe checks if a container is ready to serve traffic — if it fails, the pod is removed from Service load balancing without restarting it. A startup probe delays the other probes until the application has initialised, preventing premature restarts during slow startup.

livenessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 20
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

startupProbe:
  httpGet:
    path: /startup
    port: 80
  failureThreshold: 30
  periodSeconds: 10  # Allow 300s for slow startup

Resource Requests and Limits

Every container in Kubernetes should declare resource requests (the minimum guaranteed allocation used by the scheduler) and limits (the maximum allowed, beyond which the container is throttled or killed). Requests in CPU are in millicores (m) — 1000m = 1 CPU core. Setting requests and limits accurately prevents noisy-neighbour problems and enables the scheduler to pack pods efficiently onto nodes without overcommitting resources.

resources:
  requests:
    cpu: '250m'      # 0.25 CPU core guaranteed
    memory: '256Mi'  # 256 MiB guaranteed
  limits:
    cpu: '1'         # Max 1 CPU core
    memory: '512Mi'  # Max 512 MiB (OOMKilled if exceeded)

Quick Check

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

Lesson Recap

In this lesson you learned: pods are the smallest deployable units sharing network and storage, Deployments manage stateless replica sets with rolling update support, and Services provide stable endpoints that load-balance traffic across ephemeral pods. Next up we explore deploying workloads on AKS.

Frequently asked questions

Is the “Kubernetes Concepts for Azure” lesson free?

Yes — the full text of “Kubernetes Concepts for Azure” 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 “Kubernetes Concepts for Azure”?

Review core Kubernetes constructs — pods, deployments, services, and namespaces — and understand how AKS manages the control plane on your behalf. 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 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Kubernetes Concepts for Azure” 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