Skip to article
Containers Azure Kubernetes Service

AKS cluster

Microsoft Learn describes Azure Kubernetes Service as a managed Kubernetes service for deploying and managing containerized applications. An AKS cluster provides the managed Kubernetes control plane, node pools, networking, identity, scaling, and Azure integration points for running containers in Azure production environments.

Source: Microsoft Learn - What is Azure Kubernetes Service? Reviewed 2026-05-30

Exam trap
Treating AKS as only an application target and ignoring platform responsibilities.
Production check
Run az aks show and confirm identity, network profile, version, and node resource group.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
Azure Kubernetes cluster, AKS managed cluster, Kubernetes cluster in Azure
Difficulty
fundamentals
CLI mappings
5
Last verified
2026-05-30
Article depth
field-manual-complete
Learning paths Learn AKS operator path AKS cluster
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

An AKS cluster is the Azure-managed Kubernetes environment where containerized applications run. Azure operates much of the Kubernetes control plane, while your team manages workload design, node pools, networking, identity, upgrades, ingress, monitoring, and deployments. Developers interact with pods, services, deployments, and ingress rules. Platform engineers focus on private API access, network plugin, autoscaling, Azure Monitor, workload identity, and registry integration. Treat the cluster as a shared platform boundary, not just a container host. Support teams need evidence from the Azure resource and Kubernetes API.

Why it matters

AKS clusters matter because many container platform risks are cluster-level risks, not individual application risks. A weak cluster identity can break image pulls or expose permissions. A poor network decision can exhaust IP space or block private dependencies. A missing upgrade plan can leave workloads on unsupported Kubernetes versions. A public API server can expand the attack surface. Understanding the cluster boundary lets teams design pools, policies, namespaces, ingress, and monitoring intentionally. Cluster decisions shape every namespace, node pool, and ingress path. Production onboarding should review the cluster boundary before traffic arrives. Support needs evidence from both Azure and Kubernetes when incidents cross layers.

Technical context

Technically, an AKS cluster is an Azure resource that exposes a Kubernetes API server and connects to node pools, a node resource group, managed identities, network resources, and optional add-ons. Important settings include region, Kubernetes version, node pool mode, node size, zones, outbound type, network plugin, private or public API endpoint, Azure Policy, monitoring, and workload identity. Operators inspect Azure properties with CLI and Kubernetes state with kubectl. Validate Azure properties and Kubernetes state before changing production workloads.

Exam context

What to know

operator-ready

Compare with

Container Apps Container Instances Node pool AKS private cluster

Where it is used

Where you see it

  1. In the Azure portal, the AKS cluster overview shows Kubernetes version, node pools, API server access, monitoring, networking, upgrade status, and add-on configuration. for operators
  2. In CLI output, az aks show returns identity profiles, network settings, node resource group, provisioning state, power state, and Kubernetes upgrade fields. during support reviews
  3. In kubectl output, nodes, pods, services, ingress objects, events, and namespaces reveal whether the cluster is scheduling workloads and serving traffic. under real production demand

Common situations

  • Run production microservices that need Kubernetes scheduling, rolling updates, and service discovery.
  • Standardize container platform operations while Azure manages much of the Kubernetes control plane.
  • Host workloads that require custom networking, node pools, storage classes, ingress, and policy.
  • Create private container platforms integrated with Azure Container Registry and managed identities.
  • Support high-scale batch, API, or event-driven containers where autoscaling and isolation matter.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Stabilizing container releases Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A sports streaming provider ran containerized APIs on hand-managed virtual machines. Release nights caused inconsistent scaling, image drift, and manual routing changes during live events.

Goals
  • Move 42 services into a managed Kubernetes operating model.
  • Reduce release rollback time below 10 minutes.
  • Separate latency-sensitive APIs from encoding jobs.
  • Create unified monitoring before championship season.
Approach using AKS cluster

The platform group built an AKS cluster with separate system, API, and batch node pools. API nodes used zones and autoscaling with strict resource requests, while batch nodes handled short encoding jobs. Images were pulled from Azure Container Registry through managed identity. Container Insights collected node, pod, and controller telemetry. Deployment pipelines applied manifests, verified rollout status, and captured cluster version and node pool evidence before every release. Ingress routing was standardized so application teams no longer edited load balancer settings directly. The team documented owners, rollback steps, monitoring signals, and approval notes so support staff could explain the change during incidents. Load-test evidence was added to release notes before the launch window opened.

Potential outcomes
  • Rollback time fell from 45 minutes to seven minutes.
  • Average node utilization improved from 28 percent to 61 percent.
  • Live-event incident count dropped 64 percent across the season.
  • Manual release checklist steps fell from 31 to 9.
What to learn

An AKS cluster creates a platform boundary for scaling, release safety, and operations evidence.

Scenario 02 Protecting ticketing APIs Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A transit agency modernized ticket validation APIs while keeping payment and rider data away from public management endpoints. The old environment mixed web, batch, and database access.

Goals
  • Deploy ticketing services on a private cluster.
  • Use managed identities instead of stored database credentials.
  • Keep API latency below 180 milliseconds during commute peaks.
  • Provide recovery procedures for node failures and upgrades.
Approach using AKS cluster

Architects deployed a private AKS cluster into a hub-spoke network with Azure CNI, private DNS, and approved egress through Azure Firewall. Workload identity connected pods to Key Vault and database services without secrets. Separate user pools isolated ticket validation from reporting jobs, and pod disruption budgets protected minimum replicas during maintenance. Azure Policy enforced Kubernetes controls, while Container Insights and Application Insights correlated pod health with API latency. Operators rehearsed upgrades using CLI and kubectl evidence. Before-and-after command output was attached to the ticket, giving auditors a clear view of scope, permissions, and expected behavior. Operations attached private endpoint tests, authorized IP review notes, and kubectl health checks to the change record.

Potential outcomes
  • Peak validation latency averaged 132 milliseconds.
  • Stored database secrets were removed from container configuration.
  • Node image upgrades completed with no customer-visible outage during rehearsals.
  • Security review time fell from 12 business days to 4.
What to learn

AKS cluster design around networking and identity shapes safe modernization.

Scenario 03 Scaling risk simulations Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A fintech analytics firm ran intraday risk simulations on a fixed virtual machine grid. Traders waited for capacity during volatile markets, while idle compute sat unused on normal days.

Goals
  • Scale simulation workers automatically from queued jobs.
  • Keep pricing APIs isolated from compute-heavy simulations.
  • Reduce idle compute spend by at least 30 percent.
  • Create audit trails for cluster changes and job health.
Approach using AKS cluster

Engineers created an AKS cluster with a small system pool, a dedicated pricing API pool, and an autoscaling worker pool for simulations. Queue depth and resource requests drove job scheduling. Labels and taints kept simulation pods away from interactive APIs. Images came from Azure Container Registry, and pipeline gates recorded version, node counts, and rollout status. Container Insights, Prometheus metrics, and job logs were linked to trading dashboards so operators could separate capacity shortages from application errors. The runbook included validation commands, rollback timing, and owner contacts so the handoff remained clear after the project team left. Capacity checkpoints were scheduled before each market simulation cycle.

Potential outcomes
  • Idle compute cost dropped 41 percent.
  • Ninety-eight percent of simulations completed before deadline, up from 86 percent.
  • Pricing API latency stayed within target because workers used separate nodes.
  • Regulatory evidence came from pipeline and cluster telemetry outputs.
What to learn

A well-designed AKS cluster combines elastic compute with intentional workload isolation.

Azure CLI

I use Azure CLI for AKS clusters because the portal cannot replace precise cluster evidence. CLI shows API endpoint mode, Kubernetes version, identity profile, node resource group, network profile, add-on state, tags, and upgrade choices in repeatable JSON. It also supports creation, scaling, upgrade planning, credential retrieval, and add-on changes through automation. During incidents, CLI quickly confirms whether a cluster is private, which identity owns it, and whether capacity changed. CLI output captures cluster settings in a form automation can compare. That record helps platform teams coordinate kubectl checks with Azure changes. Scripts expose drift that portal reviews often miss.

Useful for

  • Show cluster properties before approving production deployment, including version, identity, network profile, and add-ons.
  • Create a cluster from automation with approved networking, monitoring, workload identity, and node settings.
  • List available upgrades and plan Kubernetes version changes without guessing from portal views.
  • Retrieve credentials for controlled troubleshooting while avoiding stale kubeconfig files.
  • Scale or update node pools after confirming demand, maintenance windows, and disruption risk.

Before you run a command

  • Confirm tenant, subscription, resource group, cluster name, and whether the cluster is production or shared.
  • Check Azure RBAC and Kubernetes RBAC because commands may expose credentials or change capacity.
  • Review region, node resource group, Kubernetes version, network plugin, and private API access.
  • Estimate cost before adding nodes, enabling logs, creating load balancers, or changing egress.
  • Use safe output queries so identities and endpoints are not overshared in tickets.

What the output tells you

  • Provisioning and power states show whether Azure sees the cluster as healthy, updating, failed, or stopped.
  • Kubernetes version and upgrade profile reveal support posture and the next available upgrade paths.
  • Identity profile fields show which managed identities connect to Azure networking and registries.
  • Network profile fields explain pod addressing, outbound routing, load balancer behavior, and IP risks.

Mapped commands

AKS cluster operational commands

direct 
az aks show --resource-group <resource-group> --name <cluster-name>
az aksdiscoverContainers
read-only Microsoft Learn 
az aks create --resource-group <resource-group> --name <cluster-name> --enable-managed-identity
az aksprovisionContainers
mutating Microsoft Learn 
az aks get-credentials --resource-group <resource-group> --name <cluster-name>
az akssecureContainers
sensitive-read Microsoft Learn 
az aks get-upgrades --resource-group <resource-group> --name <cluster-name>
az aksdiscoverContainers
read-only Microsoft Learn 
az aks nodepool list --resource-group <resource-group> --cluster-name <cluster-name>
az aks nodepooldiscoverContainers
read-only Microsoft Learn

Architecture context

In Azure architecture, an AKS cluster is where compute, network, identity, security, observability, and release practices meet. I decide early whether a workload belongs in a shared cluster, a dedicated cluster, or a managed alternative such as Container Apps. That choice affects isolation, node pool sizing, IP planning, ingress design, secret handling, and staffing. Mature designs include separate system and user pools, upgrade windows, Azure Monitor integration, approved registry pulls, private networking where needed, and workload identity instead of long-lived secrets. The cluster should match network, identity, and upgrade patterns before app teams depend on it. Shared add-ons need owners, version review, and rollback notes.

Security
Security impact is direct because the cluster controls access to the Kubernetes API, node identities, workload identities, image pulls, network policy, secrets, and add-ons. A public API endpoint, broad cluster-admin permissions, unmanaged kubeconfig files, or permissive namespaces can turn one mistake into broad compromise. Strong designs use Microsoft Entra integration, least-privilege RBAC, private clusters or authorized IP ranges where appropriate, managed identities, approved images, and audit logs. Private API access, workload identity, and image-pull paths deserve explicit review. Security evidence should include both Azure and Kubernetes authorization points. Namespace controls cannot compensate for a poorly governed cluster identity. Rotate credentials before emergency access becomes routine.
Cost
AKS cost is driven mostly by surrounding resources: VM nodes, disks, load balancers, public IPs, NAT gateways, logs, registries, and data transfer. The managed control plane does not make idle node pools free. Shared clusters improve utilization, but they need guardrails so one workload does not force expensive scaling for everyone. Cost-aware designs use right-sized node pools, autoscaling, specialized pools, log retention controls, budgets, and tags for workload and platform owners. Node pool sizing and idle capacity are the main cost levers. Shared platform costs should be allocated before teams argue about chargeback. Cluster add-ons and logging retention also need FinOps ownership.
Reliability
Reliability depends on cluster design. Availability zones, node pool capacity, pod disruption budgets, autoscaler settings, upgrade strategy, and ingress configuration affect whether workloads survive node failures, maintenance, or demand spikes. Azure manages the control plane, but application availability still depends on replicas, scheduling, probes, resource requests, and safe rollouts. Resilient clusters have documented failure domains, spare capacity, rollback paths, and monitoring that separates platform issues from application issues. Upgrade windows, node pool capacity, and API reachability belong in the service runbook. A cluster outage usually affects many services, not one pod. Zone and autoscaler choices should be validated before peak traffic.
Performance
Cluster performance is shaped by node size, pod density, network plugin, storage choices, resource requests, autoscaler latency, ingress path, and noisy-neighbor behavior. A CPU-starved node pool or missing request limits can make healthy application code look slow. Network decisions affect pod-to-service latency and IP availability. Operators should monitor pod throttling, node pressure, API server latency, ingress metrics, DNS failures, and pending pods before tuning. Node size, pod density, ingress, and network plugin choices shape application latency. Capacity tests should run before production rollout, not during an incident. Metrics should distinguish node pressure from application behavior. AKS cluster performance evidence should be captured before approval 1.
Operations
Operators manage AKS clusters by inspecting cluster properties, node pool health, Kubernetes version support, upgrade readiness, add-on status, identities, networking, and telemetry. Daily work includes retrieving credentials safely, checking node and pod status, reviewing Container Insights, draining nodes, rotating certificates when required, and validating image pull paths. Runbooks should cover image pull errors, pending pods, DNS issues, ingress outages, autoscaler limits, and API access problems. Inventory should capture add-ons, node pools, versions, identities, and network profile together. Change records should identify workload owners before cluster-level maintenance. Runbooks should pair az aks output with kubectl health checks. AKS cluster operations evidence should be captured before approval 1.

Common mistakes

  • Treating AKS as only an application target and ignoring platform responsibilities.
  • Using one shared node pool for workloads with different security, cost, and performance needs.
  • Forgetting that the node resource group contains billable and operational resources.
  • Retrieving admin credentials casually and leaving privileged kubeconfig files on laptops.
  • Creating a public API endpoint without reviewing access and monitoring requirements.