AKS Deep Dive — Node Pools, RBAC, Ingress & GitOps

“Welcome back. In our AKS fundamentals episode we covered pods, deployments, services, and basic scaling. That's enough to get started but not enough for production. Today we go deep — the patterns and features that separate a development AKS cluster from a production-grade one. Node pools for workload isolation, Helm for application packaging, Ingress for HTTP routing, persistent volumes for stateful workloads, RBAC for multi-team security, and GitOps for automated deployments from Git.”

“AKS separates system components from application workloads using node pools. The system node pool runs kube-system pods — the scheduler, DNS, metrics server — and cannot be deleted. User node pools run your applications and can be created, scaled, and deleted independently. This lets you create a GPU node pool for AI inference workloads, a high-memory pool for data processing, and a spot node pool for batch jobs — all in the same cluster. Spot node pools use Azure spot VMs at 60-90% discount. The catch: Azure can evict spot nodes with 30 seconds notice. Design batch jobs to checkpoint progress so they restart from where they left off after eviction.”

“Helm is the package manager for Kubernetes — think of it as apt or npm but for Kubernetes applications. A Helm chart packages all the Kubernetes manifests needed for an application into a single installable artifact with configurable parameters. Instead of writing and maintaining 10 YAML files, you install a Helm chart with your specific values. Artifact Hub hosts thousands of community charts: NGINX ingress controller, Prometheus monitoring stack, cert-manager for TLS certificates, databases, message queues. Helm tracks what's deployed — helm list shows all releases, helm rollback instantly reverts a broken upgrade. For enterprise use, organizations maintain private Helm repositories in Azure Container Registry.”

“An Ingress Controller is a reverse proxy running inside your cluster that handles all inbound HTTP traffic. You install it once — NGINX via Helm — and then every application creates an Ingress resource describing its routing rules. Path-based routing: requests to /api go to the API service, /web go to the web service. Host-based routing: api.myapp.com and www.myapp.com resolve to the same load balancer IP but route to different services based on the hostname. TLS termination at the ingress handles HTTPS so your individual services communicate over plain HTTP internally. Pair with cert-manager to automatically provision and renew Let's Encrypt certificates — your ingress gets free, auto-renewing TLS.”

“Containers are ephemeral — when a pod restarts, all local data is gone. For stateful workloads you need PersistentVolumes. Azure Disk maps to a managed disk — high performance, low latency, but only one pod can mount it at a time (ReadWriteOnce). Azure Files uses SMB or NFS to share storage across multiple pods simultaneously (ReadWriteMany) — useful for shared file assets. StorageClasses enable dynamic provisioning: create a PVC and Kubernetes automatically provisions an Azure Disk or Azure Files share. StatefulSets combine stable network identities with persistent storage — essential for running databases like PostgreSQL or MongoDB in Kubernetes where each replica needs its own persistent disk.”

“Kubernetes RBAC controls who can do what inside the cluster. A Role defines a set of permissions — list pods, create deployments, delete services — within a specific namespace. A RoleBinding grants that Role to a user, group, or service account. For multi-team clusters, each team gets their own namespace and a RoleBinding granting their Entra ID group admin access to that namespace only — they cannot see or modify other teams' workloads. AKS integrates with Microsoft Entra ID so you use the same groups and identities you already have. Service account RBAC controls what applications running inside the cluster can do — follow the same least-privilege principle as for humans.”

“GitOps inverts the traditional deployment model. Instead of running kubectl apply from a CI pipeline, a GitOps operator running inside the cluster continuously watches a Git repository and applies whatever is in that repository to the cluster. Flux is the most popular GitOps operator. The workflow: a developer merges a PR changing a Helm chart version → Flux detects the change in Git → Flux applies the new deployment to the cluster → pods roll out. Critically, if someone makes a manual kubectl change outside of Git, Flux detects the drift and reverts it — Git remains the single source of truth. AKS has a native GitOps extension that installs and manages Flux for you from the Azure portal.”

“Let me walk through a production-style AKS setup. Create a cluster with separate system and user node pools. Install NGINX ingress via Helm. Deploy a frontend and API service with an ingress routing /api to the API and / to the frontend. Create a PVC backed by Azure Disk and show data persisting across pod restarts. Set up namespace-based RBAC for two teams. Finally, enable GitOps with Flux — push a change to the Git repository and watch Flux automatically deploy it without any manual kubectl commands.”

“You now have the foundation for running production workloads on AKS. The production checklist: separate system and user node pools, Helm for all application deployments, NGINX ingress for HTTP routing with auto-renewing TLS, Azure Disk or Files for any stateful workloads, namespace-based RBAC with Entra ID groups for multi-team isolation, and GitOps with Flux for automated, auditable deployments. AKS with these patterns handles anything from small microservices to large-scale enterprise platforms.”