AKS in 2026: What Changed and How Beginners Can Start

Kubernetes is an open-source platform for running containerized workloads across many machines in a predictable way. It began with Google’s internal approach to operating containers at scale and is now used far beyond those early web-scale origins, helping cloud teams with scheduling, health checks, rollouts, and recovery.

Azure Kubernetes Service, usually shortened to AKS, is Microsoft’s managed Kubernetes service for running containerized applications on Azure. Microsoft manages much of the Kubernetes control plane, while the user manages application workloads, node pools, networking choices, identity, security policy, and the operating model around deployments.

That division of responsibility is important for beginners. AKS removes some of the infrastructure burden, but it does not remove the need to understand Kubernetes objects, container images, networking, permissions, upgrades, and cost controls. A small AKS cluster can be created quickly; a reliable AKS environment depends on choices made before the first production workload is deployed.

The official Azure Kubernetes Service product page is useful for understanding the managed-service scope, while Microsoft Learn and CNCF materials are useful for the Kubernetes model underneath it. Readers who need a broader refresher can also browse Kubernetes learning resources before working through the deployment example later in this article.

Where AKS fits, and where it may be too much

AKS is a good fit when an application needs Kubernetes-level orchestration control: multiple services deployed independently, CI/CD-driven releases, GPU-enabled workloads, hybrid management through Azure Arc, or edge and IoT patterns where container scheduling and scaling matter. These are the scenarios where Kubernetes gives teams useful control over placement, rollout strategy, service discovery, and resilience.

For a single web application with simple scaling needs, a managed platform service may be easier to operate. AKS becomes more attractive when the team needs control over containers, sidecars, namespaces, ingress rules, custom controllers, or workload-specific node pools. The trade-off is operational responsibility: even with a managed control plane, someone still owns Kubernetes version upgrades, RBAC boundaries, network planning, observability, image supply chain decisions, and cost hygiene.

A practical way to think about AKS is to ask whether the organization needs Kubernetes as an application platform, rather than simply needing somewhere to run a container. When the answer is yes, AKS provides an Azure-native way to run that platform without building the Kubernetes control plane from scratch.

The core Kubernetes ideas beginners need first

An AKS cluster is made of a managed control plane and one or more node pools. The control plane exposes the Kubernetes API and decides where workloads should run. The nodes are Azure virtual machines that run the containers. Node pools group nodes with similar configuration, such as VM size, operating system, availability zone, or workload purpose.

The smallest deployable unit is the Pod. In many beginner examples, one Pod runs one application container, although Kubernetes also supports multiple containers in a Pod when they must share networking and storage closely. A Deployment manages replicas of Pods and enables rolling updates. A Service gives Pods a stable network identity, because individual Pods are replaceable and receive new IP addresses when recreated.

These objects are normally described in YAML and applied to the cluster with kubectl. That declarative model can feel unfamiliar at first, but it is one of Kubernetes’ strengths: the user describes the desired state, and Kubernetes works continuously to bring the actual cluster state into line.

Basic AKS application flow: a container image is stored in a registry, deployed to AKS, and exposed through a Service or ingress layer:

1. Developer workflow
2. Container image -
3. Registry -
4. AKS Deployment -
5. Pods on nodes
6. Service / Ingress
7. Application users

A quick hands-on AKS deployment

The following example creates a small AKS cluster, connects kubectl, deploys a sample application, verifies that it is running, and then removes the resources. It is suitable for learning, but it still creates billable Azure resources, so the cleanup step is part of the exercise rather than an optional afterthought.

Before running the commands, the Azure CLI should be installed and authenticated with az login. The example uses Azure CNI Overlay, managed identity, OIDC issuer support, and Workload Identity support so that the cluster starts closer to a modern baseline instead of relying on older identity patterns.

Example — create a small AKS cluster

az group create \
  --name rg-aks-beginner-demo \
  --location westeurope

az aks create \
  --resource-group rg-aks-beginner-demo \
  --name aks-beginner-demo \
  --node-count 2 \
  --enable-managed-identity \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --network-policy azure \
  --enable-oidc-issuer \
  --enable-workload-identity \
  --generate-ssh-keys

az aks get-credentials \
  --resource-group rg-aks-beginner-demo \
  --name aks-beginner-demo

This creates a resource group and a small AKS cluster, then configures local kubectl access. The networking flags choose Azure CNI Overlay with Azure network policy support, which is a sensible learning default because it introduces Azure-integrated networking while reducing the risk of consuming large numbers of VNet IP addresses.

The sample application below uses a Microsoft-hosted public image so that the first deployment does not depend on building and pushing a custom image. In production, images should come from a controlled registry such as Azure Container Registry, with clear ownership, scanning, and promotion rules. That registry decision is part of the application supply chain, not a detail to postpone until the first incident.

Example — deploy a sample application

cat <<'YAML' > aks-helloworld.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: aks-helloworld
spec:
  replicas: 2
  selector:
    matchLabels:
      app: aks-helloworld
  template:
    metadata:
      labels:
        app: aks-helloworld
    spec:
      containers:
      - name: aks-helloworld
        image: mcr.microsoft.com/azuredocs/aks-helloworld:v1
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "250m"
            memory: "256Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: aks-helloworld
spec:
  type: LoadBalancer
  selector:
    app: aks-helloworld
  ports:
  - port: 80
    targetPort: 80
YAML

kubectl apply -f aks-helloworld.yaml
kubectl get pods
kubectl get service aks-helloworld --watch

The Deployment creates two replicas and defines CPU and memory requests and limits. Those values are deliberately small, but their presence matters: the scheduler uses requests to place Pods, and limits help stop one container from consuming more than its intended share. When the Service receives an external IP address, the sample application can be opened in a browser.

Using a public LoadBalancer is acceptable for this short test because the application is disposable and intentionally exposed. Private business applications should usually start with an internal load balancer or internal ingress design, then add public exposure only where there is a clear requirement and suitable controls such as TLS, authentication, WAF policy, and restricted backend access.

Example — inspect and clean up the environment

kubectl rollout status deployment/aks-helloworld
kubectl get events --sort-by=.lastTimestamp
kubectl describe deployment aks-helloworld
kubectl logs deployment/aks-helloworld --tail=50

az group delete \
  --name rg-aks-beginner-demo \
  --yes \
  --no-wait

These commands show the rollout state, recent cluster events, deployment details, and application logs before deleting the entire resource group. Deleting the resource group removes the AKS cluster and the related Azure resources created in the exercise, which prevents a learning environment from becoming an idle monthly cost.

Networking choices that matter early

AKS networking is one of the first areas where beginner decisions can create later constraints. At a high level, Pods need addresses, nodes need addresses, Services need stable virtual endpoints, and applications need an ingress path. The difficult part is deciding how those addresses are allocated and how much of the Azure virtual network should be reserved for the cluster.

Kubenet is the simpler legacy-style option in which nodes receive Azure VNet IP addresses and Pods use a separate address space with routing handled by Kubernetes and Azure route tables. Azure CNI gives Pods addresses that are more directly integrated with Azure virtual networking. Traditional Azure CNI can consume many VNet IP addresses because Pods draw from subnet capacity, which makes subnet sizing an early design issue rather than an administrative detail.

Azure CNI Overlay addresses a common IP planning problem. It allows Pods to use an overlay address space while nodes remain attached to the VNet, reducing VNet IP consumption compared with traditional Azure CNI in larger clusters. For beginners, this matters because IP exhaustion can appear only after the environment grows: new nodes fail to join, Pods cannot schedule as expected, or subnet redesign becomes necessary during a migration window.

Ingress design is another early decision. NGINX Ingress is common when teams want Kubernetes-native ingress behavior and broad portability. Application Gateway Ingress Controller is often considered when the team wants Azure Application Gateway features, such as Azure-native layer seven routing and Web Application Firewall integration. Internal-only ingress or an internal load balancer is often the right starting point for APIs, back-office applications, and services that should be reachable only from private networks.

Public app pattern:      Internet --> Public ingress --> Service --> Pods
Private app pattern:     VNet/VPN --> Internal ingress --> Service --> Pods
Registry path:           AKS nodes --> Azure Container Registry --> Images

Security defaults beginners should set early

Security in AKS begins with identity and permission boundaries. Human users should not all receive cluster-admin access, and application workloads should not share broad credentials. Azure RBAC and Kubernetes RBAC can be used together to control who can access the cluster and what they can do inside it. Beginners should learn namespace-level permissions early because they become the basis for separating teams, environments, and application responsibilities.

Azure AD Workload Identity is now the preferred direction for allowing Pods to access Azure resources without storing secrets in Kubernetes. It succeeds the older AAD Pod Identity approach and uses federation between Kubernetes service accounts and Azure identities. For a beginner, the key idea is simple: a Pod should be able to prove what workload it is, then receive narrowly scoped access to resources such as Key Vault, Storage, or Azure Container Registry without embedding long-lived credentials.

Network policies add another important layer. By default, Kubernetes networking can be permissive inside the cluster, so teams should define which Pods can talk to which other Pods and external endpoints. This is especially important in shared clusters where a development namespace, an internal API, and a data-processing workload may have very different communication requirements.

Image provenance deserves equal attention. Pulling arbitrary images from public registries may be convenient during experimentation, but production clusters should use trusted registries, controlled base images, vulnerability scanning, and clear promotion from development to test to production. Azure Container Registry commonly fills that role in Azure environments, and Microsoft’s Kubernetes training material at Azure Kubernetes training and certification resources can help readers connect these platform concepts with structured learning objectives.

Node pools, storage, and workload placement

A minimal starter AKS design should separate system and user workloads. The system node pool hosts critical cluster components, while user node pools host application workloads. Mixing everything onto one pool can work in a test cluster, but it makes upgrades, scaling, and troubleshooting harder as the environment grows.

For non-production environments, Spot node pools can reduce compute cost for workloads that tolerate interruption. They are unsuitable for critical system components or stateful services that expect stable capacity. GPU node pools should be created only when needed and removed or scaled down when idle, because specialized compute can become one of the easiest ways to waste budget in a forgotten development cluster.

Scheduling also differs between Linux and Windows node pools. Linux containers run on Linux nodes, and Windows containers require Windows node pools with compatible container images. This sounds obvious, but it is a frequent source of failed scheduling when teams copy YAML between workloads without node selectors, tolerations, or image compatibility checks.

Storage choices should follow the application’s access pattern. Azure Disks are typically used when a workload needs block storage attached to a single node, such as many database-style workloads. Azure Files is often more suitable when multiple Pods need shared file access. The access mode matters because Kubernetes will enforce what the underlying storage can support; choosing the wrong storage class can lead to attach failures or disappointing performance.

Scaling and cost hygiene from the first cluster

AKS scaling happens at more than one layer. Horizontal Pod Autoscaler changes the number of Pod replicas based on metrics such as CPU or memory. Cluster Autoscaler changes the number of nodes when Pods cannot be scheduled due to insufficient capacity. KEDA can scale workloads based on event sources, which is useful for queue-driven or message-driven applications.

Beginners often reach too quickly for node autoscaling when the first step should be right-sizing the workload. If Pod requests are too high, the scheduler may demand more nodes than the application really needs. If limits are too low, the application may suffer CPU throttling or memory restarts. Observing real usage before increasing infrastructure size leads to a more stable and less expensive cluster.

Development clusters also need deliberate shutdown habits. Scheduled scale-down, small node counts outside working hours, removal of unused public IPs, and cleanup of test namespaces all reduce waste. The cleanup command in the earlier example is intentionally simple because the safest learning environment is one that can be recreated rather than preserved indefinitely.

Day-two operations: upgrades, monitoring, and recovery

The first deployment proves that AKS works; day-two operations prove whether the platform can be trusted. Kubernetes and AKS versions move over time, and clusters need an upgrade plan. That plan should cover maintenance windows, node image updates, workload disruption budgets, and a test environment where upgrades are tried before production.

Monitoring should combine Kubernetes signals with Azure platform signals. Kubernetes events help explain scheduling failures, image pull errors, readiness probe failures, and rollout problems. kubectl describe provides object-level detail, while kubectl logs shows application output. Azure Monitor Container Insights can add visibility into restarts, node pressure, CPU throttling, memory usage, and cluster-level trends.

Safe recovery often begins with Deployments. A rolling update can be paused, inspected, and rolled back if the new version fails readiness checks. That makes health probes and deployment strategy more than YAML decoration; they determine how safely the cluster can replace one version of an application with another.

Several beginner mistakes recur across AKS environments: leaving system and user workloads on the same node pool, omitting Pod requests and limits, underestimating IP address needs, skipping Kubernetes version upgrades, and choosing storage without checking access modes. Each mistake is easy to overlook during a successful first deployment, but each can become expensive during scale, outage recovery, or production change windows.

How beginners should build from here

A sensible AKS learning path starts with Kubernetes fundamentals, then moves into Azure-specific networking, identity, registry, monitoring, and cost controls. Running a small cluster is useful, but the more valuable skill is understanding why each default was chosen and what should change when the workload becomes private, stateful, regulated, or business-critical.

Readynez can fit into that learning journey when a team wants structured Microsoft training around Azure administration, cloud operations, and Kubernetes-related skills; the broader Microsoft catalogue is available through Readynez Microsoft training. The important point is to connect training with hands-on practice: create a cluster, deploy a workload, inspect failures, secure access, and remove resources cleanly.

The key takeaway is that AKS is approachable for beginners, but it rewards careful early decisions. Networking, identity, node pools, scaling, and observability should be treated as part of the first learning cycle rather than postponed until production. Readynez provides one route for formalizing those skills, while the practical foundation comes from building, breaking, inspecting, and improving a real AKS environment.