Azure Kubernetes Service (AKS)

What it is

Azure Kubernetes Service (AKS) is Azure’s managed Kubernetes service for deploying and managing containerized applications. Kubernetes coordinates many containers across compute resources: it schedules pods, replaces failed pods, scales workloads, and exposes services according to the configuration a team supplies.

Why it exists

When a workload needs coordinated services, deployments, scaling, service discovery, and repeated operational patterns, Kubernetes can help. AKS shifts substantial Kubernetes platform work to Azure, but it does not remove the need to design, secure, monitor, and operate the applications running on the cluster.

Key ideas

  • AKS creates and manages a control plane. Workloads run in pods on nodes. A node pool groups the compute nodes for a cluster.
  • AKS Automatic uses Azure-managed production defaults for nodes, scaling, security, monitoring, and upgrades. AKS Standard gives teams more direct control of cluster configuration and node pools. Choose the mode from actual platform-control needs.
  • Kubernetes objects such as Deployments, Services, Ingress, and namespaces describe desired workload state and boundaries. They are configuration the team must understand and maintain.
  • AKS integrates with Azure networking, storage, and identity. For example, pods can use persistent volumes backed by Azure Disks or Azure Files, and workloads can pull images from ACR.
  • Scaling can involve pod autoscalers and node provisioning or autoscaling. A configured scaler responds to its configured signals; it does not guarantee that every workload can scale safely.
  • Pricing, uptime guarantees, and included features vary by AKS mode and pricing tier. Verify the current offering rather than relying on an old blanket “control plane is free” statement.

How it fits (diagram)

aks - Microsoft diagram

Diagrams courtesy of Microsoft Learn / Azure docs: aks/intro-kubernetes

Northwind example

Northwind’s ordering platform has several containerized services: checkout, catalogue, recommendations, and background workers. It uses AKS Automatic to start from Azure’s managed defaults, then defines deployments, health checks, resource limits, identities, and monitoring for each service. When checkout traffic rises, configured Kubernetes scaling can add capacity. Luis still owns application behavior, safe rollout settings, secrets, and the decision of whether a failed dependency should make a pod ready to serve traffic.

AKS versus ACI

NeedStart by considering
Coordinated, multi-service container platform with Kubernetes capabilitiesAKS
One simple container or small related container group[[aci
Small event-driven code unit without managing containers[[azure-functions

Common confusion

  • AKS is managed Kubernetes, not “no operations.” Someone still owns workload manifests, release safety, identity, networking, observability, and incident response.
  • A healthy Kubernetes node does not prove an application is healthy. Define meaningful readiness, liveness, and monitoring signals.
  • Kubernetes authorization and Azure resource authorization are related but distinct. Use the appropriate identity and RBAC model for each boundary.

Path MOC · aci · acr · azure-functions

Sources and re-audit