Azure Kubernetes Service: Managed Control Plane, Node Pools, Identity, and Networking

Azure Kubernetes Service manages the Kubernetes control plane while customer node pools run workloads in Azure virtual machines. The API server, scheduler, controllers, and cluster state are service responsibilities; pod specifications, identities, network exposure, persistent data, and node-pool strategy remain customer concerns.

System and user node pools

Every production design should isolate critical system pods from application pressure. System node pools host components such as CoreDNS and metrics services; user pools separate application workloads by VM family, operating system, zone, scaling policy, labels, or taints. Autoscaling responds to scheduling demand but does not repair incorrect requests or unavailable quota.

Identity and access

Microsoft recommends Entra ID authentication for the API server. Authorization may combine Kubernetes RBAC with supported Azure integration. Workloads should use managed workload identity rather than embedded service-principal secrets. Keep cluster administration, node identity, image-pull permission, and application resource access as distinct roles.

Network and ingress

Public or private control-plane access, Azure CNI options, subnet sizing, network policy, DNS, load balancers, application gateways, and ingress controllers all affect reachability. A private cluster still needs outbound paths for required Azure and artifact endpoints. Record which component owns TLS, source IP preservation, and health checks.

Upgrades and operations

Plan control-plane and node-image upgrades through supported version paths and maintenance windows. Respect disruption budgets, but also verify that workloads have multiple replicas and topology spread. Azure Monitor, managed Prometheus options, Kubernetes events, audit data, and application telemetry form the diagnostic picture. Costs include nodes, disks, load balancers, egress, logs, and paid service tiers or add-ons; the managed control plane does not make the surrounding system free.

Cluster and workload identity are separate

Operators authenticate through Microsoft Entra integration and are authorized through Kubernetes RBAC or the supported Azure RBAC integration. Use groups rather than individual bindings, reserve emergency administration for a controlled break-glass path, and audit both Azure role assignments and Kubernetes role bindings. A principal able to change an AKS resource is not automatically entitled to every Kubernetes API action, and the reverse is also true.

Nodes use managed identities for platform operations such as infrastructure and image access. Applications should use Microsoft Entra Workload ID with dedicated Kubernetes service accounts instead of inheriting node permissions or carrying service-principal secrets. Scope federated identity credentials and Azure roles to one workload trust boundary, then test token acquisition and denial from the actual pod.

Node pools are failure and change domains

System pools need enough capacity and taints to keep critical add-ons schedulable when user workloads surge. User pools can separate operating systems, VM families, zones, accelerators, or trust levels. Labels and taints express scheduling intent; they do not reserve Azure quota or subnet addresses. Cluster autoscaler can add nodes for pending pods only when requests, pool constraints, quota, and regional capacity permit a valid placement.

Treat a node image update as replacement. Create headroom, cordon and drain through supported upgrade mechanisms, and verify disruption budgets, topology spread, local storage, daemon sets, and persistent-volume topology. A PDB permits or blocks voluntary eviction; it does not guarantee application availability when replicas share one zone or depend on one database.

Networking must be capacity-tested

AKS offers multiple Azure CNI operating modes and network-policy options. Select them from current Microsoft documentation because pod address consumption, route behavior, performance, and supported features differ. Reserve subnet space for planned scale and upgrades, when old and new nodes may overlap. Track available addresses and failed allocation before deployments become stuck.

For private clusters and restricted egress, enumerate required Azure endpoints, registry access, DNS, time, certificate, and management paths. An ingress controller, Azure Load Balancer, Application Gateway integration, and Gateway API implementation have different ownership and health models. Record where TLS terminates, how source IP is handled, and which component supplies readiness to the load balancer.

Upgrade and recovery discipline

Use supported Kubernetes versions and review the AKS release calendar, version skew, deprecated APIs, add-on compatibility, and node-image notes before scheduling change. Maintenance windows influence timing but do not replace a preproduction test. Back up application data and declarative configuration, then perform restore drills; a managed control plane is not a backup of databases or volumes.

Enable and retain the audit and diagnostic categories required for investigation. Correlate Azure Activity Log, Kubernetes audit, events, node conditions, Container Insights or managed Prometheus, workload logs, and traces. Game days should cover a failed node pool, subnet pressure, broken DNS, registry denial, expired workload authorization, and zonal dependency. The acceptance criterion is user-visible service behavior, not merely a green AKS resource status.

Store cluster, pool, identity, networking, diagnostic, maintenance, and policy configuration in a reviewed declarative system. Kubernetes add-ons installed outside the AKS resource need version and ownership records too. After any emergency console or kubectl change, compare live state against both infrastructure and workload repositories, then either codify the exception or remove it.

Capacity review should combine Azure subscription quotas, regional VM availability, subnet addresses, maximum pods, disk attachment, load-balancer resources, and API throttles. A cluster can show healthy control-plane status while no valid node or pod placement remains. Alert on leading indicators and maintain enough surge headroom for the largest supported node-pool upgrade.

Review the AKS support policy and feature status before adopting previews or deprecated integrations. Record every enabled extension and its upgrade owner. A managed add-on can still introduce API, cost, identity, or network dependencies that must be represented in threat models and recovery tests.

Related:

Sources: