Before the solution makes sense, we must feel the problem.

In the early days, one application ran on one server. If the server failed, the application stopped. If the application became popular, the team bought a bigger server. Over time, companies built dozens of small applications instead of one giant program, an approach called microservices, where each small service does one job, such as handling payments, sending emails or searching products. This makes teams faster and systems easier to change, but it creates a new problem: now there are hundreds of small pieces to start, connect, update, repair and scale.

Kubernetes manages containers, so we must understand them first.

A container is a small, sealed package that holds an application together with everything it needs to run: its code, libraries and settings. Containers run on top of an operating system but are isolated from one another, so one cannot disturb another. Unlike a virtual machine, which carries a whole operating system inside it, a container shares the host’s operating system core, so it is much smaller and starts in seconds.

A container image is the frozen template from which containers are created. You build an image once, and run it anywhere as many times as you like. Images are stored in a container registry, which is like a library of images. On Azure, the registry service is Azure Container Registry, or ACR. The program that actually runs containers on a machine is a container runtime; AKS uses containerd.

Kubernetes is open-source software that runs and looks after containers across many machines.

Kubernetes, often written K8s, was created at Google and is now maintained by a large open community. A group of machines running Kubernetes is called a cluster. You tell Kubernetes what you want, for example “keep five copies of this application running, reachable at this address”, and Kubernetes works constantly to make reality match your wish. This idea is called the desired state. If a copy crashes, Kubernetes notices the difference between desired and actual state and starts a new copy. You describe the destination; Kubernetes drives the car.

AKS is Kubernetes with the hardest operating work handled by Microsoft.

Running Kubernetes yourself is demanding. You must install it, protect its central brain, keep it highly available, back up its data, upgrade it every few months and fix problems. Azure Kubernetes Service is a managed service: Microsoft runs and maintains the cluster’s control plane, the central brain, at no extra charge in the free tier, while you manage the worker machines that run your applications and the applications themselves. This split is called the shared responsibility model.

AKS also connects naturally with other Azure services: Microsoft Entra ID for sign-in, Azure Container Registry for images, Azure Key Vault for secrets, Azure Monitor for observability, Azure Policy for governance, Azure disks and files for storage, and Microsoft Defender for Cloud for security.

Every AKS cluster has a managed brain and a set of worker machines.

flowchart TB
    subgraph CP["Control plane: managed by Microsoft"]
        API["API server: front door for all commands"]
        ETCD["etcd: the cluster's database"]
        SCH["Scheduler: chooses a node for each pod"]
        CM["Controller manager: keeps desired state"]
    end
    subgraph NP["Node pools: your worker machines"]
        N1["Node 1: kubelet + containerd + pods"]
        N2["Node 2: kubelet + containerd + pods"]
        N3["Node 3: kubelet + containerd + pods"]
    end
    USER["You, pipelines, tools"] --> API
    API --> ETCD
    API --> SCH
    API --> CM
    API --> N1
    API --> N2
    API --> N3
        

A handful of Kubernetes objects describe almost everything you run.

Kubernetes objects are normally described in text files called manifests, written in a format such as YAML. These files state the desired state, are stored in version control and are applied to the cluster. This is the practice of describing infrastructure and applications as files rather than clicking in screens.

Nodes are organized into pools so different workloads can have different machines.

A node is a worker machine, in AKS a virtual machine, that runs pods. A node pool is a group of identical nodes, backed by an Azure virtual machine scale set that makes it easy to add or remove machines. A cluster can have several pools.

AKS offers different levels of service and different amounts of hands-on control.

AKS clusters come in pricing tiers. The Free tier has no charge for the control plane and no financially backed uptime guarantee, suitable for learning and tests. The Standard tier adds a financially backed service level agreement for the API server’s availability, higher limits and is recommended for production. A Premium tier adds long-term support for specific Kubernetes versions, for organizations that cannot upgrade as often. In all tiers, you pay for the nodes and other resources you use. Check the current pricing page, since details change.

There are also two management modes. AKS Standard gives you full control over choices such as node pools, networking and add-ons, while you take responsibility for configuring them well. AKS Automatic is a more opinionated mode in which Microsoft applies many production best practices by default, such as managed node provisioning, scaling, networking, security settings and monitoring, reducing the number of decisions you must make. It suits teams that want Kubernetes without becoming Kubernetes experts, though with less freedom to customize.

Let us follow one request through the cluster to see how the pieces cooperate.

sequenceDiagram
    participant U as You or pipeline
    participant A as API server
    participant E as etcd
    participant C as Controllers
    participant S as Scheduler
    participant K as Kubelet on node
    participant R as containerd
    U->>A: Apply deployment: 3 copies of my app
    A->>A: Authenticate, authorize, validate
    A->>E: Store desired state
    C->>A: Notice deployment needs 3 pods
    C->>A: Create pod records
    S->>A: Notice unassigned pods
    S->>A: Assign each pod to a node
    K->>A: Notice pod assigned to my node
    K->>R: Pull image and start container
    K->>A: Report pod running and healthy
        

The most important lesson is that Kubernetes works through control loops. No single component commands the others in a rigid order. Instead, each component watches the shared record of desired state and acts on the differences it sees. This makes the system resilient: if a component restarts, it simply resumes watching.

Telling Kubernetes how much each pod needs is the secret of stable clusters.

Each container can declare a request, the amount of processor and memory it needs to run well, and a limit, the maximum it may use. The scheduler uses requests to decide where a pod fits. At runtime, limits protect neighbors: a container that uses more memory than its limit can be stopped and restarted, and one that wants more processor than its limit is slowed down.

Kubernetes needs to know whether your application is alive and ready.

A running container is not always a healthy application. It might be stuck, or still loading data. Kubernetes uses probes, small regular checks, to find out.

Networking is the most important design decision, and the hardest to change later.

Every pod needs an address, and pods on different nodes must reach each other. AKS offers several network plugins, which decide how addresses are assigned.

Because plugin choice is difficult to change later, decide it at the start, size address ranges for future growth, and check the current recommendations in the documentation.

Users on the internet need a stable door into your changing pods.

flowchart LR
    USER["User on the internet"] --> DNS["DNS name"]
    DNS --> LB["Azure public load balancer or application gateway"]
    LB --> ING["Ingress controller pods"]
    ING -->|"/shop"| S1["Service: shop"]
    ING -->|"/pay"| S2["Service: payments"]
    S1 --> P1["Pod"]
    S1 --> P2["Pod"]
    S2 --> P3["Pod"]
    S2 --> P4["Pod"]
        

Ingress needs an ingress controller, the software that reads the rules and routes the traffic. Common AKS choices include the managed application routing add-on, which provides a managed NGINX-based controller, Azure Application Gateway for Containers, and other popular controllers you install yourself. Each differs in features such as web application firewall, certificate handling and cost, so compare them before deciding. Older approaches such as the Application Gateway Ingress Controller are also still found in many clusters.

Containers forget everything when they stop, so lasting data needs special handling.

A pod’s own filesystem disappears when the pod is replaced. For data that must survive, Kubernetes uses a small set of ideas. A PersistentVolume, or PV, is a piece of storage in the cluster. A PersistentVolumeClaim, or PVC, is a request by a pod for storage of a certain size and type. A StorageClass describes a kind of storage and lets Kubernetes create it on demand, which is called dynamic provisioning. The connection to Azure storage is handled by CSI drivers, standard plug-ins for storage.

Several layers decide who may do what, to the cluster and from the cluster.

Passwords and keys need much stronger protection than ordinary settings.

Kubernetes has a Secret object, but by default its values are only encoded, not strongly protected, and anyone with permission to read them can see them. A safer pattern on Azure is to keep secrets in Azure Key Vault, a hardened service for secrets, keys and certificates, and let pods read them using the Secrets Store CSI driver with the Key Vault provider. The pod gets the value at start-up, using its workload identity, and values can be rotated centrally without rebuilding images.

AKS can adjust capacity at several levels, and each level solves a different problem.

flowchart TB
    L["Load increases"] --> HPA["Horizontal Pod Autoscaler or KEDA: add more pods"]
    HPA --> Q{"Enough room on nodes?"}
    Q -- Yes --> OK["Pods are scheduled"]
    Q -- No --> PEND["Pods stay Pending"]
    PEND --> CA["Cluster autoscaler or Node Auto Provisioning: add nodes"]
    CA --> OK
    L2["Load decreases"] --> HPA2["Fewer pods"]
    HPA2 --> CA2["Idle nodes removed"]
        

A healthy team delivers changes through an automated, repeatable pipeline.

flowchart LR
    DEV["Developer commits code"] --> CI["CI pipeline: build and test"]
    CI --> IMG["Build container image"]
    IMG --> SCAN["Scan image for vulnerabilities"]
    SCAN --> ACR["Push to Azure Container Registry"]
    ACR --> GIT["Update manifests in Git"]
    GIT --> GO["GitOps agent in cluster, such as Flux"]
    GO --> AKS["AKS applies desired state"]
    AKS --> MON["Monitor health and roll back if needed"]
        

Package tools such as Helm bundle many manifests into one reusable package, called a chart, with adjustable settings. Kustomize helps adjust manifests for different environments without copying them. Both are widely used with AKS.

Security in Kubernetes works in layers, from the cloud around the cluster to the code inside.

Azure Policy for Kubernetes enforces rules inside the cluster using an admission controller. Examples: forbid privileged containers, require resource limits, allow only images from your registry, and require certain labels. Policy turns good intentions into enforced guardrails.

You cannot fix what you cannot see, and clusters produce a lot to see.

Kubernetes releases new versions regularly, and clusters must keep up.

Kubernetes publishes a new minor version, such as 1.xx, roughly every few months. AKS supports a limited number of recent versions, normally the latest few, and older versions fall out of support after a defined period. Running an unsupported version means missing security fixes and losing official help. A long-term support option exists for selected versions in the Premium tier for teams who need slower change. Always check the AKS release calendar for the current support windows.

Plan for failures at every level, from a pod to an entire region.

AKS makes it easy to scale, and just as easy to overspend.

You pay for the nodes (virtual machines, disks), networking components such as load balancers, public addresses and outbound data, storage, monitoring data, and the paid cluster tier if you choose Standard or Premium. The control plane in the Free tier has no charge.

Proven ways of organizing applications on Kubernetes, and habits to avoid.

A compact list to review before and after going to production.

A balanced view helps you choose the right platform.

A useful rule: choose the simplest platform that meets your needs. Move to AKS when you need Kubernetes capabilities, such as custom networking, many cooperating services, special scheduling, an ecosystem of Kubernetes tools, or portability across environments.

Seeing how organizations use AKS helps connect the concepts.

Kubernetes is the open-source software. AKS is Azure’s managed service that runs the Kubernetes control plane for you and integrates it with Azure services. You still manage worker nodes, workloads and many settings.

The Free tier does not charge for the control plane but has no financially backed uptime guarantee. The Standard and Premium tiers carry a charge and add guarantees and features. You always pay for nodes and related resources.

Many new clusters use Azure CNI Overlay, or Azure CNI powered by Cilium, for address efficiency and scale. Avoid kubenet for new clusters because of its announced retirement. Always check the current recommendation, and decide before creating the cluster.

If your needs are simple, such as a web app or a few microservices with basic scaling, they require much less operating effort. Use AKS when you need Kubernetes features, deeper control or an ecosystem of Kubernetes tools.

Use workload identity, which lets a pod receive an Entra identity and obtain access tokens without stored passwords. Combine it with Key Vault for secrets and private endpoints for network paths.

Kubernetes versions are supported for a limited time, so plan regular upgrades, usually a few times a year, and use maintenance windows and auto-upgrade channels. Test in a non-production cluster first.

Yes, using StatefulSets, persistent volumes and database operators, but it demands expertise. For important data, managed database services are usually simpler and safer.

Right-size requests, enable autoscaling in both directions, use Spot pools for tolerant work, commit to stable capacity, limit log volume, stop idle non-production clusters and track costs by namespace with budgets and alerts.

Learn containers first, then core objects like pods, deployments and services. Create a small test cluster in a non-production subscription, deploy a simple application, expose it, scale it and observe it. Then add identity, policies, GitOps and monitoring step by step.

Azure Kubernetes Service gives you the power of Kubernetes while Microsoft operates the control plane. You have learned how containers and Kubernetes solve the problem of running many applications reliably, how an AKS cluster is built from a managed control plane and node pools, and how pods, deployments, services and ingress describe what you run and how traffic reaches it. You have seen how networking, storage, identity and secrets are arranged, how scaling works at pod and node levels, how delivery pipelines and GitOps keep changes safe, and how layered security, monitoring, upgrades, resilience and cost control keep a cluster healthy and affordable.

The best way to start is small and careful: choose the network design deliberately, set resource requests and probes on every workload, use Entra ID and workload identity, store configuration in Git, and watch your cluster with proper monitoring and budgets. Kubernetes rewards teams that automate, measure and keep things simple. Remember that the aim is not to run Kubernetes for its own sake, but to deliver reliable applications to your users with confidence.