Azure Kubernetes Service (AKS) lets teams run Kubernetes workloads without operating every part of the cluster control plane themselves. Microsoft manages the supported AKS control-plane components, while application teams still own container images, deployment configuration, data access, service reliability and the permissions granted to workloads. This distinction matters: a managed Kubernetes cluster reduces infrastructure administration, but an application that cannot reach its database or safely deploy an update remains the organization’s problem.
Consider a retailer running an online storefront, an inventory API and a background order worker. The website must remain responsive during promotions, inventory changes cannot be lost when a Pod is replaced, and the operations team needs a controlled way to deploy software without exposing secrets. AKS provides the scheduling and managed-cluster foundation, but the design still requires choices about node pools, networking, workload identity, persistent storage, monitoring and recovery. Following this example makes the service easier to understand than a long list of unrelated AKS features.
Choose AKS Automatic or AKS Standard based on operational ownership
AKS has different operating models. AKS Automatic is intended to reduce routine platform work through managed node provisioning, scaling, upgrade behavior and security and monitoring defaults. AKS Standard gives platform teams more direct control of cluster and node-pool configuration. They are not simply two names for the same pricing option. An organization requiring unusual network design, precise VM SKU control or established custom cluster automation may prefer Standard; a new application team seeking managed production defaults may prefer Automatic after confirming that its requirements are supported.
AKS also has separate cluster-management pricing tiers called Free, Standard and Premium. Free management is appropriate for evaluation and development but still incurs charges for consumed resources such as virtual machines, storage and networking; it does not provide a financially backed Kubernetes API uptime SLA. Standard management includes an uptime SLA, and Premium adds extended Kubernetes version support for eligible scenarios. Automatic uses Standard management by default. These management tiers must not be confused with Automatic and Standard cluster operating models or with the cost of running the applications.
For the retailer, start with explicit requirements: expected order volume, availability target, regions, data-classification requirements, deployment cadence and which team will troubleshoot the cluster. Estimate node and data costs before selecting a tier. A cluster that supports thousands of nodes may still be inappropriate for a team running three lightweight services if the platform complexity exceeds the value of its orchestration features.
Kubernetes workload management remains familiar across the operating models. A Deployment specifies desired Pod replicas, a Service offers a stable endpoint for them, and the platform works to reconcile that desired state. AKS does not change the need for image security, API authentication or application compatibility. The higher-value question is which AKS operations Microsoft handles by default and which controls your team will deliberately manage.
Understand control-plane, node-pool and Pod responsibilities
An AKS cluster has a managed Kubernetes control plane and nodes that run application Pods. A node pool groups workers with compatible characteristics such as operating system, VM size and selected deployment settings. Workloads may be separated across system and user pools where appropriate, and scheduling uses Kubernetes resource requests, constraints and policies. A node can be healthy while its application is not, so service readiness needs to be designed at the Pod and application layers.
For the order API, define CPU and memory requests that reflect representative traffic and sensible limits where needed. Kubernetes chooses where to place the Pods based on available resources and scheduling rules. A Pod that cannot be placed may remain Pending despite there being no application exception in its logs. Read scheduler events and node capacity before increasing replica counts. A dedicated workload pool can be appropriate for jobs with specialized CPU, GPU or isolation requirements, but a small application may be simpler to run on ordinary shared nodes with well-defined policies.
Resilience also depends on topology. Multiple Pods on the same node do not protect against that node failing; multiple nodes in one Availability Zone do not by themselves survive a zone outage. Where supported, distribute appropriate node pools and replicas across zones, and use Pod disruption budgets and topology rules to help manage voluntary maintenance. The managed AKS control plane has its own availability model, but the application and its dependent data store still require end-to-end fault-tolerance design.
It is useful to test a routine change before calling the cluster production ready: drain a noncritical node, observe where replacement Pods are scheduled and verify that user traffic continues to reach healthy backends. A correct rollout process needs app-level readiness checks, enough spare capacity and graceful handling of in-flight work. The difference between readiness and liveness matters because restarting a temporarily overloaded Pod may make a recoverable problem worse.
Plan Azure networking before exposing the application
AKS networking connects Pods to one another, services inside the cluster, Azure resources and external clients. Azure CNI offers supported modes with different Pod addressing and routing implications, including overlay and Pod-subnet approaches. Pod CIDR planning affects the number of usable addresses, overlap with connected networks and whether traffic can traverse the expected path. A configuration that works inside one cluster may fail when the retailer adds a private backend or hybrid network with overlapping address ranges.
Choose the exposure model deliberately. The public storefront may use a supported ingress or application routing solution in front of an AKS Service, while the inventory API remains private. An Azure Load Balancer or other supported ingress integration moves packets, but it does not authenticate customers or authorize access to order records. TLS termination, request filtering, rate limits and application identity controls must be implemented for the chosen entry point. A detailed NGINX deployment on AKS can illustrate the difference between deploying a Pod and making it reachable from the right clients.
Network policies can restrict permitted Pod-to-Pod traffic where a supported network-policy implementation is configured. Azure network security groups and routes address other parts of the network path. The retailer should explicitly allow the storefront to reach the inventory API and the order worker to reach its queue or data service, while denying unnecessary lateral connections. A route existing in the virtual network does not prove the application is authorized to use a sensitive backend. A more detailed discussion of Azure network security groups helps distinguish subnet and interface controls from Kubernetes workload identity and Pod policy.
Private clusters, outbound connectivity and DNS design have operational consequences. A private API endpoint can reduce public management exposure, but the administrator’s deployment runner, monitoring systems and support workflows must still resolve and connect to it. Network egress controls should permit legitimate image retrieval, secret access and telemetry while restricting unnecessary destinations. Diagnose connection failures by separating name resolution, route selection, network policy and application behavior rather than widening every rule at once.
Use Microsoft Entra Workload ID and scoped access controls
AKS has two important identity boundaries: identities permitted to manage Kubernetes resources, and identities used by workloads calling Azure services. Microsoft Entra integration and Kubernetes RBAC or Azure RBAC control appropriate management actions, while Microsoft Entra Workload ID can let a supported workload obtain scoped Azure access without embedding a long-lived secret in its image. A user who can deploy a Pod should not automatically be able to read every Key Vault secret, and a Pod’s permission to retrieve a secret should not grant it cluster-administrator rights.
The older Microsoft Entra pod-managed identity add-on is a legacy path whose managed support ended in September 2025; use Workload ID for supported modern designs rather than recommend installing the retired add-on. Workload identity requires correct OIDC and service-account configuration and matching Azure identity permissions. A misconfigured federation can result in access failures even when the Pod is healthy. Test the service account that the application actually runs under, not only a human administrator’s sign-in.
Keep secrets out of container image layers and ordinary environment-logging paths. Azure Key Vault and supported Kubernetes integrations can supply secrets at runtime, subject to the chosen identity and access model. Rotate credentials with an application behavior plan: changing a secret value without accounting for connection pooling or cache lifetime may cause intermittent errors. Microsoft Defender for Containers and suitable image and runtime controls can help identify risks, but enabling a security product does not replace patching application dependencies or limiting effective permissions.
In the retailer scenario, allow the order worker to retrieve only the connection information and data permissions necessary for its task. A compromised storefront Pod should not be able to list production credentials or change unrelated deployments. Review network and identity permission paths together; least privilege needs to be testable both at the Kubernetes API and at the Azure service the workload calls.
Match persistent storage and scaling to workload behavior
Containers can be replaced, so data that must outlive a Pod should not exist only in its writable image layer. Kubernetes PersistentVolumes and PersistentVolumeClaims provide a storage abstraction; AKS supports Azure Disk and Azure Files through supported CSI drivers. Azure Disk is often suitable for certain single-writer, low-latency storage patterns, while Azure Files can support shared-file access models. Access modes, zone placement, performance and failure recovery depend on the chosen storage class and workload. A database’s resilience cannot be inferred solely from the existence of a PVC.
The retailer might store its authoritative orders in an appropriately managed database rather than within a Pod that moves between nodes. Background workers can be stateless and restart safely if each task uses a durable identifier and idempotent write. If several worker replicas receive the same message, the business logic must avoid duplicate fulfillment. Kubernetes can restart failed Pods; it cannot decide whether charging a customer twice is acceptable.
Autoscaling works at several levels. Horizontal Pod Autoscaling can adjust replicas based on supported metrics, KEDA can scale for event-driven triggers, and node autoscaling or automatic node provisioning can supply additional compute when Pods cannot be placed. These mechanisms have separate lag and capacity constraints. Scaling a worker pool during an order burst may simply overload the shared database if connection limits are not considered. Define what should scale and what resource could become the next bottleneck.
Right-size requests and use representative load tests to understand the application’s behavior before enabling aggressive scaling. A low request can cause resource contention, while a vastly inflated request can leave Pods pending even when actual utilization is modest. Cluster cost follows node capacity, storage, logging, network transfer and other Azure services, not only the management tier. Autoscaling is useful when it improves availability per unit of cost, not when it hides a leak in the application’s resource usage.
Deliver changes using repeatable pipelines and observability
AKS applications can be deployed through Kubernetes manifests, Helm, GitOps controllers or conventional CI/CD tools. The retailer should build and test an approved container image, store it in a trusted registry, and deploy an immutable image version with environment-specific configuration. GitOps approaches such as Flux can help reconcile reviewed desired state from version control. A deployment succeeds only when the application passes health and behavior checks, not merely when Kubernetes accepts a resource definition.
A Helm chart can package related Kubernetes resources, but chart templates can also express unsafe permissions or incompatible storage changes. Review the rendered manifests and keep Kubernetes version and API compatibility in mind. The older Open Service Mesh project has retired, and Microsoft documents September 30, 2027 as the end of support for the managed AKS OSM add-on; existing users should plan migration to the supported Istio add-on where appropriate. Do not recommend OSM as the default new service-mesh choice.
Observability should connect user symptoms to cluster signals. Azure Monitor, Container Insights and managed Prometheus/Grafana options can help monitor Pod health, resource saturation, request latency and service failures. An Azure monitoring review is useful when the team must distinguish an overloaded node, a failed rollout or a database dependency from an application error. Keep logs structured and avoid writing user credentials or personal data to ordinary diagnostics.
A useful deployment rehearsal introduces a bad application configuration in a test environment. Inspect whether the new Pods become ready, whether the rollout pauses or fails, and which Azure and Kubernetes signals reveal the problem. Roll back the application version using a documented process. Remember that a Kubernetes Deployment rollback restores a workload template, not external database migrations or already published messages; persistent-state changes may need separate recovery actions.
Plan upgrades, recovery and the correct management tier
Kubernetes releases require a version-support strategy. AKS offers supported Kubernetes versions with defined upgrade policies, and its Premium management tier supplies extended LTS coverage for eligible versions. The right upgrade plan considers supported extensions, networking, storage drivers, workload APIs and application compatibility, not just the cluster’s control-plane version. A third-party ingress controller or deprecated Kubernetes API may break before the application team notices a change in the managed service itself.
Disaster recovery needs a clear definition of what must be restored. Container images and manifests can recreate compute resources, but customer data, identity configuration, secrets, persistent volume contents and external services require their own backup and recovery design. A replica in another Availability Zone does not protect against an incorrect shared database update. Decide whether the application needs another cluster, another Region or only tested backups based on its actual downtime and data-loss objectives.
Governance and ownership should match the cluster’s size. Apply resource and policy controls through reviewed deployment workflows, restrict who can modify node pools or cloud networking, and define a process for emergency changes. Production teams need visibility into cluster upgrades, cost and exposure, while application teams need enough control to ship tested software. AKS Automatic can remove a portion of routine platform work; Standard can be appropriate when the organization needs special control. Neither operating model excuses untested recovery and excessive permissions.
The most reliable AKS decision follows one user request from public entry point to Pod, application identity, backend storage and response. If the team can explain where the request is authorized, how Pods scale or move, what happens during a failed rollout, how data survives a node loss and who receives an alert, the cluster is serving a clear engineering purpose. That understanding matters more than enabling every AKS add-on or claiming that a managed control plane makes Kubernetes operations effortless.