Episode 1 — The AKS Mental Model: What Azure Manages, What You Manage

Welcome to the module. Before touching a single command, we build the mental model that every later episode hangs off of — the split between the part of the cluster Azure runs for you and the part you're responsible for.

Learning objectives

By the end of this episode you can:

Explain what AKS adds on top of open-source Kubernetes.
Draw an AKS cluster as two halves — a managed control plane and your nodes — and name every component in each.
State the shared-responsibility line and use it to predict who fixes what.
Choose between AKS Automatic and AKS Standard, and between the Free / Standard / Premium tiers.

Why it matters

Almost every AKS support ticket, design argument, and 2 a.m. page comes down to one confusion: who owns this piece? If you know that Azure runs the API server but you own what schedules onto your nodes, you stop debugging the wrong layer. This episode installs that instinct.

1. Kubernetes, and what "managed" buys you

Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. It's powerful but operationally heavy: you'd normally run and patch the brain of the cluster yourself.

Azure Kubernetes Service (AKS) is a managed Kubernetes service: Azure operates the cluster's brain — the control plane — for you, so you focus on your applications. That single fact is the root of the whole mental model.

🧠 Mnemonic: AKS = Kubernetes with the control plane rented, not owned.

2. The two halves of a cluster

An AKS cluster is divided into two main components:

Control plane — the Azure-managed brain that provides core Kubernetes services and orchestrates workloads. You never SSH into it and you don't pay per-VM for it.
Nodes — the Azure VMs that run your applications. This is your data plane; you influence their size, count, OS, and what runs on them.

Control-plane components (Azure runs these)

Component	What it does
`kube-apiserver`	Exposes the Kubernetes API — the single front door for every request, from `kubectl` or from inside the cluster.
`etcd`	Highly available key-value store holding the entire cluster state and configuration.
`kube-scheduler`	Watches for new pods with no node and selects a node for each.
`kube-controller-manager`	Runs controllers — control loops that notice drift (e.g. a node goes down) and drive the cluster back to desired state.
`cloud-controller-manager`	Embeds Azure-specific control logic (e.g. wiring up load balancers, disks).

Node components (run on every one of your nodes)

Component	What it does
`kubelet`	The node agent that ensures the containers in each pod are running.
`kube-proxy`	Maintains network rules on the node so Services work.
container runtime	`containerd` on modern AKS — executes containers and manages images.

💡 Tip: These components are identical to upstream Kubernetes. AKS doesn't fork Kubernetes — it operates it. Everything you learn about vanilla Kubernetes transfers directly.

3. Nodes, node pools, and where your VMs actually live

Nodes of the same configuration are grouped into node pools (backed by Azure Virtual Machine Scale Sets). Two kinds:

System node pool — hosts critical system pods like CoreDNS and konnectivity. Every cluster has at least one.
User node pool — hosts your application pods. You add these to match workload needs.

Node configuration you control includes the VM size (CPU/memory/disk type), the OS image (Ubuntu, Azure Linux, or Windows Server), and OS disk type. Note AKS also enforces resource reservations (CPU + memory it keeps for itself), so a node's allocatable resources are less than its total.

⚠️ Pitfall — the second resource group: when you create a cluster in your resource group, AKS auto-creates a second resource group, the node resource group (default name MC_<rg>_<cluster>_<region>), holding the VMs, scale sets, disks, and load balancers. Don't hand-edit resources there — AKS owns them.

Namespaces: logical partitions inside one cluster

Namespaces logically divide a cluster to organize resources and control access. Defaults you'll meet immediately:

Namespace	Role
`default`	Where your resources land if you don't specify one.
`kube-system`	AKS/Kubernetes system components (CoreDNS, metrics-server…). Don't deploy your apps here.
`kube-public`	Rarely used; world-readable.
`kube-node-lease`	Node heartbeat/health leases.

4. The two operating models: AKS Automatic vs Standard

Both modes use the same Kubernetes concepts above. What differs is how much day-2 operation Azure does by default.

AKS Automatic — a more fully managed experience. Azure preconfigures node management, scaling, security guardrails, and upgrades with production-ready defaults. Best when you want less platform management.
AKS Standard — a more configurable experience giving you direct control over node pools, scaling, networking, and operations. Best when you need custom operating patterns and deep tuning.

A useful way to read the comparison: features are Preconfigured (always on, can't change), Default (set for you, changeable), or Optional (off until you enable them).

Dimension	AKS Automatic	AKS Standard
System node pool	Preconfigured — Azure creates/scales/upgrades it	Default — you create and manage it
Scaling	Preconfigured — node autoprovisioning + HPA/KEDA/VPA on	Optional — you enable autoscaler/NAP/KEDA
Upgrades	Preconfigured — auto-upgraded (stable channel)	Default manual; optional auto-upgrade
Networking	Default — Azure CNI Overlay powered by Cilium	Choice of kubenet / Azure CNI / Overlay / Cilium
Auth	Preconfigured — Azure RBAC for Kubernetes	Default local accounts; RBAC optional
SLA	Uptime SLA + pod-readiness SLA included	Uptime SLA tied to pricing tier

🧠 Mnemonic: Automatic = Azure holds the wheel; Standard = you hold the wheel.

5. Pricing tiers and the SLA that comes with them

AKS has three pricing tiers for cluster management, and they buy you API-server availability guarantees, not compute:

Tier	API-server SLA	Use for
Free	No financially-backed SLA (best-effort)	Dev/test, learning
Standard	99.9% (single zone) / 99.95% (across zones)	Production
Premium	99.99% (across zones) + long-term support	Mission-critical, extended version support

💡 Tip: for anything production, Standard tier minimum — the Free tier's control plane has no uptime guarantee.

6. Zooming out: the baseline architecture

Microsoft's baseline reference architecture shows the shape a real production cluster takes. You don't need the details yet — just absorb the pattern and where the shared-responsibility line falls.

Key ideas to carry forward: a production baseline uses a hub-and-spoke network, separates system and user node pools, favors managed identities over secrets, spreads across availability zones, and prefers Azure CNI Overlay to conserve IP space. Every one of these gets its own episode.

Key takeaways

AKS = managed Kubernetes: Azure operates the control plane; you operate the nodes and everything on them.
The control plane = kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager. Nodes = kubelet, kube-proxy, containerd.
Node pools come in system (cluster services) and user (your apps) flavors; a hidden node resource group holds the actual VMs.
AKS Automatic = maximum defaults/minimum ops; AKS Standard = maximum control.
Pricing tier buys API-server SLA: Free (none), Standard (99.9/99.95%), Premium (99.99% + long-term support).
Everything reduces to one question: "Who manages this — Azure or me?"

Quick recall

Q: Which cluster half does Azure fully manage, and can you SSH into it? A: The control plane; no, you cannot access its VMs.
Q: Name the store that holds cluster state. A: etcd.
Q: Which node component actually starts your containers? A: The kubelet (via the container runtime, containerd).
Q: What's the difference between a system and a user node pool? A: System hosts critical cluster pods (CoreDNS, etc.); user hosts your apps.
Q: You need a production uptime guarantee for the API server across zones — which tier? A: Standard (99.95%) or Premium (99.99%).
Q: In AKS Automatic, who manages upgrades and the system pool? A: Azure (preconfigured).

Exercises

Exercise 1.1 — Sort the components. For each item, say whether it runs in the control plane or on a node: etcd, kubelet, kube-scheduler, kube-proxy, containerd, kube-apiserver.

Worked solution

Control plane: etcd, kube-scheduler, kube-apiserver.
Node: kubelet, kube-proxy, containerd. Rule of thumb: if it makes cluster-wide decisions or stores state, it's control plane; if it runs or wires up containers on one machine, it's a node component.

Exercise 1.2 — Who fixes it? A teammate says: "The API server was unreachable for 30 seconds, and separately, one of our app pods is stuck Pending because no node has enough memory." Which problem is Azure's responsibility under the SLA, and which is yours?

Worked solution

API-server unreachability relates to the control plane → covered by the uptime SLA (if you're on Standard/Premium), so it's Azure's availability responsibility.
Pod stuck Pending for lack of memory is a data-plane/capacity problem → yours: you must add nodes, enable autoscaling, or lower the pod's resource requests (Episodes 4–5).

Exercise 1.3 — Pick a mode and tier. A team of two wants to ship a production API with minimal platform babysitting and a real availability guarantee. Recommend a cluster mode and pricing tier, with one sentence of justification each.

Worked solution

Mode: AKS Automatic — production-ready defaults for scaling, upgrades, and security mean the two-person team spends time on the app, not the platform.
Tier: Standard (minimum) — gives the financially-backed API-server uptime SLA (99.9%/99.95%); Automatic already includes uptime + pod-readiness SLA coverage. Choose Premium only if they need long-term version support.

Coming up

You now have the map. In Episode 2 we make it concrete: provision a real cluster with the Azure CLI, connect kubectl, and design system vs user node pools with taints and labels — turning the mental model into infrastructure.