AKS lets you run many containers across many machines without building and maintaining the management system yourself.

The simple definition

Azure Kubernetes Service is an Azure service that gives you a working Kubernetes cluster. A cluster is a group of computers that act together as one system. In AKS, Azure operates the “brain” of the cluster, and you provide the “workers”, which are virtual machines that run your containers. You tell the cluster what you want, for example “keep five copies of my shopping website running”, and the cluster makes it so and keeps it so.

What AKS gives you

Before Kubernetes makes sense, you need to understand what it manages.

The “works on my machine” problem

An application depends on many things: a programming language runtime, libraries, settings, and a particular version of each. If the server has different versions, the application may fail in strange ways. For years, teams lost days to this problem.

What a container is

A container is a lightweight package that holds an application and everything it needs to run: its code, its libraries, and its settings. It runs in isolation from other containers on the same machine, yet shares the machine’s operating system core, which makes it small and quick to start. A container image is the saved, read-only blueprint, and a running container is a live copy made from an image.

Containers versus virtual machines

One container is easy. A thousand containers across fifty machines is a different problem.

Running one container on one machine is simple. But real systems need many containers, spread across many machines, because one machine is a single point of failure and has limited capacity. Then a long list of questions appears. Which machine should run each container? What if a machine dies? How do containers find each other when their addresses keep changing? How do you update the application without turning it off? How do you add capacity during a busy hour?

Kubernetes, often written K8s, is an open-source system that answers these questions. It was created by Google, based on experience running enormous numbers of containers, and was released to the world through the Cloud Native Computing Foundation. Today it is the standard way to run containers at scale, and every major cloud offers a managed version.

Kubernetes is powerful, but running it yourself is hard work. AKS takes over the hardest parts.

The burden of self-managed Kubernetes

If you install Kubernetes yourself, you must build and protect its control plane, back up its database, patch it, upgrade it carefully every few months, replace failed control machines, and keep it highly available. These tasks need specialist skills and constant attention, and a mistake can take down the whole cluster.

Kubernetes has its own vocabulary. This table is the key to everything that follows.

Desired state: the heart of Kubernetes

The most important Kubernetes idea is desired state. You do not tell Kubernetes the steps. You describe what you want, such as “five copies of this web app”. Kubernetes constantly compares what you want with what actually exists, and works to close any gap. If a pod dies, there are only four where you wanted five, so it starts another. This repeating compare-and-fix loop is called reconciliation.

An AKS cluster has a control plane that Azure runs and worker nodes that run in your subscription.

flowchart TB
  subgraph AZ["Managed by Azure"]
    API["API server: the front door"]
    ET["etcd: the cluster's memory"]
    SC["Scheduler: picks a node for each pod"]
    CM["Controllers: keep reality matching desire"]
    API --- ET
    API --- SC
    API --- CM
  end
  subgraph YOU["In your subscription"]
    N1["Node 1: kubelet and pods"]
    N2["Node 2: kubelet and pods"]
    N3["Node 3: kubelet and pods"]
  end
  U["You: kubectl, portal, pipelines"] --> API
  API --> N1
  API --> N2
  API --> N3
    

Control plane components

Node components

• Kubelet: an agent on each node that receives instructions and makes sure the assigned pods run and stay healthy.
• Container runtime: the software that actually starts and stops containers on the node.
• Network proxy and rules: handle the traffic rules that make services reachable.

Azure keeps the brain of your cluster alive, and offers different levels of commitment about how reliable it is.

What Azure does for you

When you create a cluster, Azure sets up the control plane components in a way that you do not have to manage. Azure monitors them, repairs them, patches them, and applies updates when you ask to upgrade the Kubernetes version. The control plane uses redundancy so that the failure of one component does not stop the cluster from accepting requests.

Pricing tiers and reliability promises

AKS has offered more than one tier for the control plane, which differ in cost and in the reliability commitment. In broad terms, a free tier is meant for learning and testing, with no financial commitment on availability. A standard tier adds a financially backed uptime commitment and is meant for production, and a premium tier adds long-term support options for organisations that need to stay on a particular Kubernetes version for longer. The names, prices, and details change over time, so check current documentation before choosing.

The worker machines in AKS are organised into groups called node pools.

What a node pool is

A node pool is a group of identical worker nodes. All nodes in a pool share the same virtual machine size, operating system type, and settings. A cluster has at least one pool, and can have many. Behind the scenes, Azure creates a scale set for each pool, which is the Azure feature that manages a group of identical machines.

Choosing machine sizes

Virtual machine sizes differ in how many processor cores and how much memory they have. Choose by watching real usage, not guessing. Very small nodes waste capacity on system overhead, while very large nodes make a single node failure hurt more. A middle path, a handful of moderate-sized nodes per pool, is common for production.

Follow an application from your instruction to running containers, and through an update.

sequenceDiagram
  participant U as You
  participant A as API server
  participant E as etcd
  participant C as Controllers
  participant S as Scheduler
  participant K as Kubelet on a node
  U->>A: Submit a deployment of 3 copies
  A->>E: Store the desired state
  C->>A: Notice 0 pods exist, need 3
  C->>A: Create 3 pod records
  S->>A: Assign each pod to a node
  K->>A: Watch for pods assigned to me
  K->>K: Pull image and start containers
  K->>A: Report pod running
  A->>E: Store the actual state
    

Pods

A pod is the smallest thing Kubernetes runs. Usually it holds a single container, but it may hold a few that must work closely together, sharing the same network address and storage. Pods are disposable. They are never repaired. A broken pod is replaced with a new one, which will have a different address.

Deployments and rolling updates

You rarely create pods directly. A deployment declares how many identical pods you want and which image they run. When you change the image to a new version, the deployment performs a rolling update: it starts a few new pods, waits until they are healthy, shuts down a few old ones, and repeats until all pods are new. Users see no interruption, and if the new version is faulty, the deployment can roll back to the earlier one.

Health checks

• Readiness check: tells Kubernetes whether a pod is ready to receive traffic. A pod that is still warming up is kept out of rotation.
• Liveness check: tells Kubernetes whether a pod is stuck. A pod that fails is restarted.
• Startup check: gives slow-starting applications extra time before the other checks begin.

Every pod should say how much processing power and memory it needs. This one habit prevents many outages.

Requests and limits

A request is the amount of processor and memory a pod asks Kubernetes to reserve for it. The scheduler uses requests to decide whether a node has room. A limit is the maximum a pod is allowed to use. If a container tries to use more memory than its limit, it is stopped and restarted. If it tries to use more processor than its limit, it is slowed down.

Quality of service classes

Based on how you set requests and limits, Kubernetes ranks pods when a node runs out of memory. Pods with requests equal to limits are the most protected, pods with some requests are in the middle, and pods with none are removed first. This ranking decides who gets evicted when the node is under pressure.

Networking is the part of Kubernetes that surprises beginners most. The ideas are simple once you see the pattern.

The basic rules

Kubernetes sets a few simple rules. Every pod gets its own network address. Any pod can reach any other pod directly, without translation, unless you add rules to forbid it. And nodes can reach pods, and pods can reach nodes. How these rules are made to work depends on the network plugin chosen when the cluster is created.

Network models in AKS

Pods come and go, so Kubernetes provides stable addresses and doors for traffic.

Why services exist

Because pods are replaced often and each new pod has a new address, nobody can depend on a pod’s address. A service solves this with a stable name and address that stays the same, and forwards traffic to whichever healthy pods currently match its label. Other applications inside the cluster simply call the service by name.

flowchart LR
  U["Users on the internet"] --> LB["Azure load balancer or gateway"]
  LB --> IC["Ingress controller pods"]
  IC -->|"Path: /shop"| S1["Shop service"]
  IC -->|"Path: /pay"| S2["Payment service"]
  S1 --> P1["Shop pod"]
  S1 --> P2["Shop pod"]
  S2 --> P3["Payment pod"]
  S2 --> P4["Payment pod"]
    

DNS inside the cluster

Kubernetes runs its own name system, so a pod can reach another application just by using the service name, for example “payments”. The cluster translates the name to the current stable address. This is why applications in a cluster rarely need to know any real network addresses.

By default every pod can talk to every pod. Network policies let you close doors that should be closed.

The open default is convenient but not safe. If an attacker breaks into one pod, they could probe all others. A network policy is a rule that says which pods may talk to which, and over what ports. With policies in place, a front-end pod might be allowed to call the back-end, the back-end allowed to call the database, but the front-end forbidden from ever reaching the database directly.

flowchart LR
  F["Front-end pods"] -->|allowed| B["Back-end pods"]
  B -->|allowed| D["Database pods"]
  F -. blocked .-> D
  X["Unrelated pods"] -. blocked .-> D
    

Practical tips

• Start with a “deny all” rule per namespace, then allow only the paths that are needed.
• Control outgoing traffic too, so a compromised pod cannot freely call out to unknown places.
• Choose a network policy engine when creating the cluster, because support depends on the plugin and engine chosen.
• Test policies in a non-production namespace first, because a mistake can break legitimate traffic.

Pods are disposable, but data often must not be. Kubernetes separates the storage from the pod.

The problem

When a pod is deleted or replaced, anything it wrote inside its own container is lost. That is fine for stateless web servers, but not for a database. Kubernetes solves this with persistent volumes, storage that exists independently of any pod and can be reattached to a replacement pod.

The pieces

Azure storage choices

Keep settings out of your images so one image can run everywhere.

The same container image should run in testing and in production, with only the settings differing. Kubernetes provides two objects for this. A ConfigMap stores ordinary settings, such as a feature switch or a web address. A Secret stores sensitive values, such as passwords. Pods receive them as environment variables or as files.

Good habits

• Never bake passwords or keys into container images.
• Keep configuration in files under version control, separate from secret values.
• Use a Key Vault integration so secrets rotate without rebuilding images.
• Give each namespace only the secrets it needs.

AKS can grow and shrink at two levels: the number of pods, and the number of nodes.

flowchart TD
  L["Load rises"] --> H["Horizontal pod autoscaler adds pods"]
  H --> Q{"Is there room on existing nodes?"}
  Q -->|Yes| R["New pods start"]
  Q -->|No| P["Pods wait as pending"]
  P --> CA["Cluster autoscaler adds nodes"]
  CA --> R
  R --> D["Load falls"]
  D --> S["Pods scale in, idle nodes are removed"]
    

Making scaling work well

• Set requests honestly. Autoscalers use them for decisions, so wrong requests give wrong scaling.
• Set minimums and maximums. A minimum protects availability, and a maximum protects your bill.
• Allow warm-up time. New nodes take a few minutes to arrive, so scale early rather than late for sudden spikes.
• Test with load. Never discover scaling behaviour on launch day.

Sometimes you need to guide the scheduler. Kubernetes gives you several polite and strict controls.

Kubernetes moves quickly. Staying current safely is a core part of running AKS.

Versions

Kubernetes publishes a new minor version a few times a year, and each version is supported for a limited window. AKS supports a rolling set of recent versions, and older ones stop receiving fixes. Running an unsupported version means no security patches and possibly no help. Plan to upgrade regularly rather than waiting until the last moment.

Two kinds of updates

How a node upgrade works

There are two sets of questions: who may manage the cluster, and what may your applications access?

Access for people

AKS integrates with Microsoft Entra ID, Azure’s identity service, so people sign in with their normal work accounts instead of shared cluster passwords. Two layers of permission then apply. Azure role-based access control decides who may create, change, or delete the cluster itself. Kubernetes role-based access control decides what a signed-in person may do inside the cluster, such as reading pods in one namespace but not deleting them. Azure also offers a way to manage Kubernetes permissions using Azure roles, so one system of records covers both.

Access for applications

Applications in pods often need to call Azure services, such as a database or a vault. Putting passwords in the pod is risky. Workload identity lets a pod prove who it is using a short-lived token tied to a service account, and Azure grants access based on that identity. There are no stored passwords to leak, and access can be limited to the exact pod that needs it. Older approaches existed, and the recommended approach has changed over time, so follow the current guidance.

sequenceDiagram
  participant P as Pod
  participant K as Cluster token issuer
  participant E as Microsoft Entra ID
  participant V as Azure service
  P->>K: Ask for a signed identity token
  K-->>P: Short-lived token for this service account
  P->>E: Exchange token for an Azure access token
  E-->>P: Access token limited to allowed services
  P->>V: Call service with access token
  V-->>P: Response
    

Kubernetes security works best as layers, so one failure does not mean total loss.

flowchart TB
  A["Layer 1: Supply chain - trusted, scanned images"] --> B["Layer 2: Cluster access - identity, roles, private endpoint"]
  B --> C["Layer 3: Network - policies, firewalls, private traffic"]
  C --> D["Layer 4: Workload - restricted pods, no unnecessary privileges"]
  D --> E["Layer 5: Data - secrets in a vault, encryption"]
  E --> F["Layer 6: Detection - logs, alerts, threat protection"]
    

Layer by layer

You cannot fix what you cannot see. Observability is the habit of making the cluster tell you how it is doing.

The three signals

Azure tools

What to watch

• Node health: processor, memory, disk, and node readiness.
• Pod health: restarts, pending pods, and containers killed for memory.
• Application signals: request rate, errors, and delay.
• Scaling: whether autoscalers hit their maximums.
• Cost signals: idle capacity and over-sized requests.

A first-aid sequence

Things fail. A reliable AKS design expects failure and keeps serving users anyway.

Levels of failure

Availability zones

An Azure region is divided into availability zones, physically separate datacentres with independent power and cooling. An AKS node pool can spread its nodes across zones. If one zone fails, nodes in the others keep running, and Kubernetes places replacement pods there. Combine this with topology spread rules so copies of your application are spread across zones, and check that your storage and databases are zone-aware too.

flowchart LR
  U["Users"] --> G["Global traffic steering"]
  G --> R1["Region A cluster"]
  G --> R2["Region B cluster"]
  subgraph R1S["Region A"]
    R1 --> Z1["Zone 1 nodes"]
    R1 --> Z2["Zone 2 nodes"]
    R1 --> Z3["Zone 3 nodes"]
  end
  R1 --> DB["Replicated data service"]
  R2 --> DB
    

Multi-region: do you really need it?

Running active clusters in two regions doubles many costs and complicates data consistency, deployments, and testing. Many applications reach their reliability goals with zones alone, and add a second region only when the business impact of a regional outage justifies it. Decide using explicit targets: how much downtime and how much data loss can the business accept?

Kubernetes makes it easy to start things and just as easy to forget them. Cost control is a daily habit.

What you pay for

• Worker nodes: usually the largest cost. You pay for the virtual machines whether pods fill them or not.
• Control plane: free in the basic tier, and a small charge in paid tiers, depending on current pricing.
• Storage: disks and file shares, including unused ones left behind.
• Networking: load balancers, public addresses, and data leaving Azure or crossing zones and regions.
• Monitoring: log and metric volume can become significant if collected without thought.
• Registry and security tools: container registry storage and protection plans.

How code travels from a developer’s laptop to a running pod, safely and repeatably.

Continuous integration and delivery

Continuous integration means that every code change is automatically built and tested. Continuous delivery extends this to automatically preparing, and often deploying, the tested result. For AKS this typically means: build a container image, scan it, push it to the registry, and update the cluster to use the new image.

flowchart LR
  A["Developer pushes code"] --> B["Pipeline builds and tests"]
  B --> C["Image scanned and signed"]
  C --> D["Image pushed to registry"]
  D --> E["Manifest repository updated"]
  E --> F["GitOps agent in cluster notices change"]
  F --> G["Cluster pulls new image and rolls out"]
  G --> H["Monitoring watches the release"]
    

GitOps

GitOps keeps the desired state of the cluster in a Git repository. An agent running inside the cluster continuously compares the cluster with the repository and corrects any difference. Changes happen only by changing the repository, which gives review, history, and easy rollback. AKS supports GitOps through extensions, and popular tools include Flux and Argo CD.

Safer rollout strategies

A cluster created by clicking is hard to repeat. A cluster described in code can be rebuilt in minutes.

Because AKS is an Azure resource, you can describe it with the same tools used for other Azure resources: Bicep, Azure Resource Manager templates, or Terraform. The code states the Kubernetes version, node pools, network model, identity settings, and add-ons. Storing it in version control gives history, review, and repeatability.

Choices to make when creating a cluster

Opinionated, simplified modes

Microsoft has introduced a more automated style of cluster, often called AKS Automatic, where many of these decisions are made for you using recommended settings, including node management, scaling, networking, and security defaults. This reduces effort and mistakes, in exchange for less freedom to tune. Whether it suits you depends on your need for control. Because this area evolves quickly, check the current documentation.

AKS is powerful, but power brings complexity. Choose it for good reasons.

Experience across many teams has produced reliable patterns for running workloads on Kubernetes.

Namespaces and quotas

A resource quota limits the total resources a namespace may use, and a limit range sets defaults for pods that forget to declare them. Together they stop one team from consuming the whole cluster by accident.

These habits feel convenient early on and cause pain later.

Use this as a review list before a cluster goes to production.

Common beginner mistakes

• Treating pods like permanent servers, and storing important data in them.
• Forgetting that deleting a namespace deletes everything inside it.
• Creating a public load balancer for every service, instead of using one ingress.
• Leaving test clusters running all weekend.
• Ignoring pod restarts until users complain.
• Assuming that “managed” means “nothing for me to do”.

Here are typical uses of AKS in different industries. The scenarios are illustrative.

Practice makes ideas stick. Try these on a sandbox subscription, and delete everything when done.

A quick reference to the terms used in this guide.

AKS gives you the power of Kubernetes without the burden of running its brain. Success depends on how you run what sits on top.

You have seen how containers solve the “works on my machine” problem, how Kubernetes orchestrates many containers using desired state and constant reconciliation, and how AKS splits the work between an Azure-managed control plane and worker nodes in your subscription. You learned about node pools, pods, deployments, services, and ingress, then explored networking, policies, storage, configuration, scaling, scheduling, and upgrades. You looked at identity, layered security, monitoring, reliability across zones and regions, cost control, delivery through pipelines and GitOps, and how to judge when AKS is the right tool at all.