India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Azure Kubernetes Service (AKS) & Container Registry Services
Azure Kubernetes Service (AKS) is Microsoft's managed Kubernetes offering, where Azure runs the control plane and customers run containerized workloads on node pools, with AKS Automatic adding preconfigured node provisioning, security and monitoring. NTSPL designs AKS clusters in Indian regions for insurers, SaaS vendors and telecom operators, wiring in Container Registry, Workload Identity, KEDA and managed Prometheus.
Microsoft Azure services in scope
The Problem Azure Kubernetes Service (AKS Automatic) and Azure Kubernetes Service (AKS Standard) Solve
Teams arrive at Kubernetes for good reasons, dozens of services, independent release cycles, uneven scaling, and then spend most of their effort on the platform instead of the product: node pool sizing, ingress controllers, secrets in YAML, upgrade cadences every few months, and Prometheus servers that run out of disk. The AKS problem is making the cluster a product the application teams consume, with secure defaults, autoscaling that tracks real demand, and identity that does not depend on long-lived secrets, while keeping cost per namespace visible.
NTSPL starts by deciding how much of the platform the customer wants to own. AKS Automatic suits teams that want production defaults without tuning node pools; AKS Standard suits those needing custom networking, GPU pools or Windows nodes. Either way, every workload authenticates with Workload Identity, images come only from a private Azure Container Registry, event-driven services scale with KEDA, and metrics go to Azure Monitor managed Prometheus with Managed Grafana dashboards per team.
When AKS Is the Right Platform for Your Microservices (and When Container Apps Is Enough)
Signals that point to containers & kubernetes on Microsoft Azure
- More than 15-20 containerized services are owned by several teams that release independently.
- Services scale on queue depth or event lag, and CPU-based HPA leaves backlogs of thousands of messages before scaling.
- Connection strings and service principal secrets for Azure services are stored in Kubernetes secrets or Helm values.
- A SaaS product must isolate tenants by namespace, node pool or cluster with per-tenant cost visibility.
- Self-managed Kubernetes on VMs is two or more minor versions behind and upgrades are postponed every quarter.
When a different approach is better
- Fewer than 10 containerized services with simple HTTP and queue scaling: Azure Container Apps gives KEDA scaling and revisions without operating a cluster.
- A single monolithic web application: Azure App Service with deployment slots is simpler and cheaper.
- Short event-triggered functions such as file or webhook processing: Azure Functions on Flex Consumption avoids paying for idle nodes.
AKS Building Blocks: AKS Automatic, Node Pools, Container Registry, Workload Identity and KEDA
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Azure Kubernetes Service (AKS Automatic) | Delivers a production-configured cluster with node autoprovisioning, Azure CNI Overlay powered by Cilium, Workload Identity, deployment safeguards and automatic upgrades enabled by default. | The team wants Kubernetes APIs and ecosystem but does not want to design and maintain node pools and add-ons. |
| Azure Kubernetes Service (AKS Standard) | Provides full control over node pools, VM sizes, networking plug-ins, Windows or GPU nodes and add-on selection. | Workloads need Windows containers, GPU pools, custom CNI configuration or specific node-level tuning. |
| Azure Container Registry (Premium) | Stores and serves container images and Helm charts privately, with geo-replication, private endpoints, ACR Tasks for builds and support for signed artefacts. | Clusters should pull only scanned, signed images from a private registry inside the VNet. |
| Microsoft Entra Workload ID | Federates Kubernetes service account tokens with Entra ID through the cluster's OIDC issuer, so pods get Azure access tokens without stored secrets. | Pods call Key Vault, Storage, SQL, Service Bus or other Azure services. |
| KEDA add-on for AKS | Scales deployments, including to zero, on external event sources such as Service Bus queue length, Event Hubs lag, Kafka topics or Prometheus queries. | Load is driven by queues or events rather than CPU, and HPA on CPU reacts too late or not at all. |
| Azure Monitor managed service for Prometheus and Azure Managed Grafana | Collects Prometheus metrics from clusters into an Azure Monitor workspace with managed retention and recording rules, visualized in Managed Grafana. | Self-hosted Prometheus is running out of storage or needs high availability across several clusters. |
Private AKS platform with Workload Identity, KEDA and managed Prometheus
Private AKS platform with Workload Identity, KEDA and managed Prometheus
External traffic enters through Application Gateway for Containers into a private AKS cluster in Central India, where namespaced services pull signed images from a private Premium Container Registry. Pods authenticate to Azure services with Workload Identity, event workers scale through KEDA on Service Bus or Event Hubs, and metrics flow to managed Prometheus and Grafana.
Select any component
Private AKS platform with Workload Identity, KEDA and managed Prometheus: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 5-step primary path.
AKS Engineering Decisions: Cluster Mode, Networking, Tenancy Model, Autoscaling and Upgrades
AKS Automatic or AKS Standard
Choose AKS Automatic when workloads are Linux, stateless or use managed data services, and the team values defaults over control: node provisioning, upgrades, Cilium networking and safeguards come preconfigured. Choose Standard when you need Windows node pools, GPU pools, specific VM SKUs, custom kubelet settings or third-party CNI. Many organizations run Automatic for product teams and Standard for one specialized cluster. Validate that required add-ons are supported in the chosen mode before committing.
Networking model and IP planning
Azure CNI Overlay gives pods addresses from a private overlay range, so VNet space is consumed only by nodes, which avoids the IP exhaustion of flat Azure CNI in large clusters. Cilium dataplane adds eBPF-based network policy and observability. Size the node subnet for maximum nodes plus surge during upgrades. Use a private cluster with the API server reachable only from the hub and egress routed through Azure Firewall with FQDN rules for required AKS endpoints.
Tenancy model for teams or SaaS customers
Namespace-per-tenant with network policies, resource quotas and separate Workload Identities suits many small tenants on shared nodes. Dedicated node pools with taints suit tenants needing noisy-neighbour isolation or compliance separation. Cluster-per-tenant or deployment stamps per region suit large enterprise tenants with contractual isolation. Most SaaS vendors combine all three by tier, automating tenant onboarding through GitOps so every tenant is defined declaratively.
Autoscaling layers
Set accurate CPU and memory requests first; every autoscaler depends on them. Use HPA for CPU-bound services, KEDA for queue and event-driven workers, and Vertical Pod Autoscaler in recommendation mode to correct requests. Let node autoprovisioning or cluster autoscaler add nodes for pending pods. Set PodDisruptionBudgets so scale-in and upgrades never take all replicas down. Spot node pools suit batch and stateless workers with tolerations.
Upgrade cadence and support window
Kubernetes minor versions arrive roughly every four months and AKS supports a limited window, so plan quarterly upgrades rather than annual ones. Use auto-upgrade channels with planned maintenance windows, upgrade non-production a cycle ahead, and set max surge on node pools to control speed. Where regulated workloads cannot upgrade that often, the Premium tier's Long Term Support extends a version's support to two years.
How NTSPL Builds a Production AKS Platform from Registry to GitOps
Platform landing zone and private registry
Create the spoke VNet, private DNS, egress firewall rules for AKS endpoints and a Premium Container Registry with a private endpoint and geo-replica.
Cluster build and GitOps bootstrap
Deploy AKS Automatic or Standard through Bicep or Terraform, enable the Flux extension and let Git define namespaces, quotas and network policies.
Workload Identity and secrets migration
Create a managed identity per service, federate it with its service account, and replace every connection string with token-based access or Key Vault CSI mounts.
Service onboarding with KEDA and HPA
Move services namespace by namespace, set requests from VPA recommendations and attach KEDA ScaledObjects to event-driven workers.
Observability and SLO alerting
Enable managed Prometheus, import Managed Grafana dashboards and define per-namespace SLO alerts before traffic cutover.
Upgrade drill and handover
Run a full minor-version upgrade in non-production with PodDisruptionBudgets, document timings and hand over the runbook.
What you receive
Hardening AKS: Workload Identity, Deployment Safeguards, Private Clusters and Defender for Containers
AKS threats include stolen secrets in manifests, unsigned or vulnerable images, privileged pods escaping to nodes, an internet-exposed API server and lateral movement between namespaces. NTSPL removes stored secrets with Workload Identity and the Key Vault CSI driver, admits only signed images from a private registry, enforces pod security baselines through Azure Policy and deployment safeguards, runs private clusters and applies default-deny network policies per namespace.
- Microsoft Entra Workload ID replacing Kubernetes secrets for Azure service access
- Azure Policy for Kubernetes enforcing restricted pod security, no privileged containers and approved registries
- Private cluster with Entra ID integration and Kubernetes RBAC mapped to Entra groups; local accounts disabled
- Defender for Containers for image vulnerability assessment and runtime threat detection
- Cilium network policies with default deny between namespaces
AKS Pricing Levers: Node Autoprovisioning, Spot Node Pools, Pricing Tiers and Namespace Cost Allocation
AKS bills the underlying node VMs, disks, load balancers and egress, plus a per-cluster hourly fee for the Standard and Premium tiers; the control plane on the Free tier has no fee but no financially backed SLA. Cost therefore follows node utilization: requests set too high leave nodes half empty, while missing limits cause noisy neighbours. Visibility per namespace is what makes chargeback possible.
- Node autoprovisioning with constrained VM families to bin-pack pods on right-sized nodes
- Spot node pools for batch, CI runners and stateless workers with eviction-tolerant design
- Savings Plan for compute covering the steady baseline of node vCPUs
- KEDA scale-to-zero for event workers idle outside business hours
- AKS cost analysis add-on and VPA recommendations to correct over-requested pods
AKS vs Azure Container Apps: which should run my containers?
Decide on four criteria. Control: AKS exposes the full Kubernetes API, node pools, DaemonSets, CRDs and operators; Container Apps hides Kubernetes and offers a fixed set of features. Scale of estate: AKS pays off when you run dozens of services, need service mesh or operators such as Kafka or Postgres operators; Container Apps fits up to a few dozen services with HTTP and event scaling. Operations: AKS needs upgrade planning, node management and platform engineering capacity, though AKS Automatic reduces this; Container Apps needs almost none. Cost model: AKS bills nodes whether pods use them or not; Container Apps consumption bills per second of use. NTSPL rule: start on Container Apps unless a concrete requirement needs Kubernetes APIs.
Key facts about containers & kubernetes on Microsoft Azure
Containers & Kubernetes on Microsoft Azure in Practice
3 containers & kubernetes scenarios from Health insurance TPA, Software (ERP ISV), Telecommunications: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
Health TPA meets 1-hour cashless pre-auth target with AKS and KEDA-scaled adjudication
ERP vendor turns single-tenant installs into multi-tenant SaaS on AKS Automatic
Telecom operator runs OSS fault and inventory microservices at 4x event volume on AKS
Containers & Kubernetes on Microsoft Azure: Frequently Asked Questions
How is AKS priced?
You pay for the VMs, disks, load balancers and data transfer that your node pools use, at normal Azure rates. The control plane is free on the Free tier, while the Standard tier adds an hourly cluster fee for a financially backed API server SLA, and Premium adds Long Term Support. Savings Plans, Reservations and Spot apply to node VMs. NTSPL estimates node counts from pod requests.
How do we migrate from self-managed Kubernetes or Docker Compose to AKS?
For existing Kubernetes, export manifests or Helm charts, replace cloud-specific storage classes and ingress, swap secrets for Workload Identity and Key Vault, then deploy through GitOps to a new AKS cluster and shift traffic by DNS. For Docker Compose, convert services into Kubernetes deployments with health probes and resource requests first. NTSPL runs both environments in parallel during cutover.
Can AKS clusters and container images stay in India?
Yes. AKS and Azure Container Registry are available in Indian regions including Central India, with registry geo-replication to South India for DR. Application data stays in the regional data services you attach. NTSPL documents data flows for DPDP Act processing records and for IRDAI or RBI reviews, and restricts registry replication to Indian regions.
What is the difference between AKS Automatic and AKS Standard?
AKS Automatic is a cluster mode where Azure preconfigures node provisioning, scaling, networking, security safeguards, monitoring and upgrades according to recommended practice, so teams deploy workloads without designing node pools. AKS Standard gives full control of every setting. Automatic is faster to production; Standard suits Windows nodes, GPUs or unusual requirements.
Why use Workload Identity instead of Kubernetes secrets?
Kubernetes secrets are only base64-encoded and often end up in Git or Helm values; if leaked, they grant access until manually rotated. Workload Identity issues short-lived Entra ID tokens to pods based on their service account, so there is nothing to leak or rotate. It replaces the deprecated pod-managed identity add-on.
How often do we need to upgrade AKS?
Plan for a minor-version upgrade about every quarter, because new Kubernetes versions arrive roughly three times a year and AKS supports a limited window of versions. Auto-upgrade channels and planned maintenance windows automate most of it. If quarterly upgrades are impractical for a regulated workload, the Premium tier offers Long Term Support for selected versions.