August 17, 2026
9 min read
Table of Contents
By Kokil Thapa | Last reviewed: August 2026
Provisioning a managed Kubernetes cluster is straightforward until you hit production requirements like networking isolation, identity management, and unpredictable billing. This guide for Azure Kubernetes Service (AKS): Deploy Your First Cluster moves beyond the portal wizard to establish a repeatable, infrastructure-as-code foundation suitable for real workloads. Whether you are migrating a legacy monolith or architecting a new microservices platform, getting these primitives right prevents costly re-architecture later. For teams evaluating their broader hosting strategy before committing to containers, comparing this against traditional cloud hosting services in Nepal helps clarify whether Kubernetes complexity is actually justified for your current scale.
Quick answer: To successfully complete Azure Kubernetes Service (AKS): Deploy Your First Cluster, use the Azure CLI with explicit parameters for VNet integration, managed identity, and monitoring. Avoid default "quick create" options in production; instead, define node pools, CNI networking, and RBAC upfront via Infrastructure as Code to ensure security and cost predictability.
How do you plan Azure Kubernetes Service (AKS): Deploy Your First Cluster architecture?
Before running a single az aks create command, you must define the architectural boundaries. A common mistake I see on client projects is treating AKS as a simple VM replacement rather than a distributed system platform. The planning phase determines whether your cluster will be a stable foundation or a source of constant operational friction.
Define workload characteristics and node sizing
Kubernetes scheduling is bin-packing. If your application containers request 500Mi RAM but your nodes only have 4Gi total, you waste significant capacity on system overhead. In 2026, the Standard_Ds_v2 series remains a balanced starting point for general web workloads, while E-series instances suit memory-heavy Java or .NET applications. Always calculate based on actual resource requests, not limits.
- System Node Pool: Dedicate at least 2 nodes (Standard_D2s_v3 or better) exclusively for CoreDNS, kube-proxy, and monitoring agents. Never run user workloads here.
- User Node Pool: Size based on peak aggregate requests plus 20% headroom for rolling updates.
- OS Disk: Use ephemeral OS disks where supported to reduce latency and storage costs; otherwise, premium SSDs for etcd performance.
Select the networking model deliberately
The choice between Kubenet and Azure CNI is irreversible after creation. Kubenet is simpler and uses fewer IPs, making it suitable for small clusters or development. Azure CNI assigns real VNet IPs to pods, enabling direct communication with other Azure resources without NAT, which is mandatory for most production scenarios involving databases or internal APIs.
Identity and access strategy
Disable local accounts immediately. Use Microsoft Entra ID (formerly Azure AD) integration with Kubernetes RBAC. This maps your existing corporate identities to cluster roles, eliminating shared kubeconfig files. For service-to-service communication within Azure, configure Workload Identity to avoid managing long-lived secrets entirely.
What are the exact CLI commands to provision a production-ready AKS cluster?
The Azure Portal hides critical configuration options. Using the Azure CLI ensures every parameter is explicit, version-controlled, and reproducible. Below is a battle-tested sequence for 2026 that includes networking, identity, and monitoring from day one.
Step 1: Create resource group and VNet
# Create dedicated resource group
az group create --name rg-aks-prod-np --location southeastasia
# Create VNet with sufficient address space for Azure CNI
az network vnet create \
--resource-group rg-aks-prod-np \
--name vnet-aks-prod \
--address-prefixes 10.10.0.0/16 \
--subnet-name snet-aks-nodes \
--subnet-prefix 10.10.1.0/24
# Get subnet ID for later use
SUBNET_ID=$(az network vnet subnet show \
--resource-group rg-aks-prod-np \
--vnet-name vnet-aks-prod \
--name snet-aks-nodes \
--query id -o tsv)Step 2: Provision the AKS cluster
az aks create \
--resource-group rg-aks-prod-np \
--name aks-prod-cluster \
--kubernetes-version 1.31 \
--node-count 2 \
--node-vm-size Standard_D2s_v3 \
--network-plugin azure \
--vnet-subnet-id $SUBNET_ID \
--enable-managed-identity \
--enable-aad \
--enable-azure-monitor-metrics \
--generate-ssh-keys \
--zones 1 2 3 \
--os-sku Ubuntu \
--tier standardNote the --tier standard flag. The free tier lacks SLA guarantees and has lower API server availability. For any business-critical workload, especially those serving Nepali customers expecting 24/7 uptime, the Standard tier is non-negotiable. The additional ~USD 73/month buys genuine reliability.
Step 3: Add a dedicated user node pool
az aks nodepool add \
--resource-group rg-aks-prod-np \
--cluster-name aks-prod-cluster \
--name userpool \
--node-count 3 \
--node-vm-size Standard_D4s_v3 \
--enable-cluster-autoscaler \
--min-count 2 \
--max-count 10 \
--labels workload=app \
--zones 1 2 3This separation ensures system components never compete with your application for resources. The autoscaler responds to pending pods, not CPU usage, so configure your pod resource requests accurately.
How do you manage costs when operating AKS from Nepal?
Billing surprises are the number one reason teams abandon Kubernetes. When operating from Nepal, you face dual challenges: USD-denominated pricing and limited local payment infrastructure. Understanding the cost levers before deployment prevents budget overruns.
| Cost Component | Monthly Estimate (USD) | Monthly Estimate (NPR) | Optimization Strategy |
|---|---|---|---|
| AKS Standard Tier | $73 | ~Rs 9,700 | Mandatory for production SLA; free tier only for dev/test |
| System Nodes (2x D2s_v3) | $140 | ~Rs 18,600 | Use reserved instances (1yr = ~35% savings) |
| User Nodes (3x D4s_v3 base) | $420 | ~Rs 55,800 | Spot instances for fault-tolerant batch; autoscale to zero off-hours |
| Managed Disks + Networking | $50–$150 | ~Rs 6,600–19,900 | Ephemeral OS disks eliminate disk charges; monitor egress |
| Total Baseline | $683–$783 | ~Rs 90,700–104,000 | Reservations can reduce compute by 30–40% |
For Nepali businesses, consider whether this baseline justifies the operational overhead. Many legal-tech portals and SME sites I've built perform excellently on managed PaaS or even optimized VPS setups costing Rs 2,000–5,000/month. Reserve AKS for workloads requiring true auto-scaling, multi-region failover, or complex microservice orchestration. If you're evaluating alternatives, understanding website development costs in Nepal across different architectures provides essential context for this decision.
Implement cost controls immediately
- Set Azure Budget Alerts: Configure alerts at 50%, 75%, and 100% of expected spend. Notifications go to email and webhook.
- Tag Everything: Enforce tags (environment, team, project) via Azure Policy. Untagged resources become untrackable costs.
- Right-size Continuously: Use Azure Advisor recommendations weekly. Over-provisioned nodes are the most common waste.
- Schedule Non-Production Clusters: Dev/test clusters should auto-shutdown nights and weekends. A cluster running 40 hours/week costs 24% of 24/7.
What security and networking configurations prevent common AKS failures?
Security in AKS is layered. Misconfigurations at any layer expose your entire environment. These are the non-negotiable settings for production clusters in 2026.
Network policies are mandatory, not optional
By default, all pods can communicate with all other pods. This violates least privilege. Deploy Azure Network Policy Manager or Calico and define explicit ingress/egress rules. Start with deny-all, then whitelist required paths.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {}
policyTypes:
- IngressPrivate cluster considerations
Private AKS removes public API server exposure. Traffic flows entirely over private endpoints. This adds complexity (requires Azure Bastion or jumpbox for kubectl access) but eliminates a major attack surface. For legal-tech platforms handling sensitive client data, this trade-off is usually worthwhile.
Pod security standards enforcement
Enable Azure Policy for Kubernetes to enforce Pod Security Standards (restricted profile) cluster-wide. This prevents privileged containers, host namespace sharing, and unsafe volume mounts. Treat violations as deployment failures, not warnings.
How do you validate and maintain your AKS cluster post-deployment?
Deployment is day zero. Day two operations determine long-term success. Establish these validation and maintenance routines immediately.
Immediate post-deploy validation checklist
kubectl get nodes— All nodes Ready, correct zones, correct VM sizeskubectl get pods -A— No CrashLoopBackOff or Pending system podsaz aks show --name aks-prod-cluster -g rg-aks-prod-np --query addonProfiles— Monitoring, DNS, and network policy enabled- Verify Entra ID authentication works:
kubectl auth can-i --list - Test autoscaler: Scale deployment beyond current capacity, confirm new nodes provision within 5 minutes
- Confirm network policies block unexpected traffic between namespaces
Ongoing maintenance cadence
Kubernetes moves fast. Falling behind on versions creates security debt and blocks feature adoption. Set a quarterly review cycle:
- Version Upgrades: AKS supports N-2 minor versions. Upgrade at least twice yearly. Always upgrade system pool first, then user pools.
- Node Image Updates: Run
az aks nodepool upgrade --node-image-onlymonthly for OS patches without Kubernetes version change. - Dependency Audit: Scan container images weekly with Trivy or Microsoft Defender. Patch critical CVEs within 48 hours.
- Cost Review: Analyze Azure Cost Management reports monthly. Right-size underutilized nodes. Delete orphaned disks and snapshots.
- Disaster Recovery Test: Quarterly restore test from Velero backups. Verify RTO/RPO targets are achievable.
For teams managing multiple client environments, integrating AKS operations into a broader CI/CD pipeline strategy ensures consistency. GitOps tools like Flux or ArgoCD make cluster state declarative and auditable, reducing drift between environments.
Monitoring and alerting essentials
Azure Monitor Container Insights provides baseline metrics. Supplement with Prometheus/Grafana for custom dashboards. Alert on these signals above all others:
- Node NotReady: Indicates underlying infrastructure failure
- Pod Restarts > 5/hour: Application instability or OOM kills
- Pending Pods > 5 min: Resource exhaustion or scheduler issues
- API Server Latency p99 > 1s: Control plane overload
- Certificate Expiry < 30 days: Prevents silent authentication failures
Moving Forward With Azure Kubernetes Service (AKS): Deploy Your First Cluster
Successfully completing Azure Kubernetes Service (AKS): Deploy Your First Cluster requires deliberate architectural choices, explicit CLI configuration, and disciplined ongoing operations. Skip the portal wizards, separate your node pools, enforce network policies from day one, and treat cost management as a first-class concern. The initial investment in proper setup pays dividends in stability, security, and predictable billing. If your team needs hands-on guidance implementing AKS for production workloads, or wants to evaluate whether Kubernetes is the right fit versus simpler alternatives, reach out to discuss your specific requirements.
Frequently Asked Questions
A minimal AKS cluster with one B2s node costs approximately Rs 4,500 per month or USD 34. The control plane is free in standard tier; you pay only for agent nodes, storage, and load balancers.
Running az aks create with default parameters typically provisions a working cluster in four to eight minutes. Add extra time for custom networking, managed identities, or node pool configurations during initial deployment.
Central India (Pune) generally provides the best connectivity from Nepal, averaging 80-120ms latency. Use az network watcher test-connectivity to verify actual performance before committing production workloads to any specific region.
You need an active Azure subscription, Azure CLI version 2.60 or higher installed locally, sufficient quota in your target region for at least two vCPUs, and a registered Microsoft.ContainerService resource provider. Configure kubectl after creation.
Kubenet suits simple deployments where pods do not require direct VNet integration. Azure CNI assigns real VNet IPs to pods, enabling network policies and direct service communication but consuming more IP addresses. Choose based on whether pod-to-VNet resources matter.
Define a StorageClass referencing azure-disk or azure-file CSI drivers. Azure Disk suits single-node read-write workloads like databases. Azure Files supports multi-node read-write access for shared content. Always set reclaimPolicy to Retain for production data safety.
This error means nodes cannot retrieve container images. Verify image name and tag spelling, confirm Azure Container Registry permissions via az aks update --attach-acr, check node outbound internet access through NSGs, and validate imagePullSecrets if using private registries outside ACR.
AKS eliminates control plane management overhead and reduces operational risk. Self-managed clusters save roughly Rs 2,000 monthly on small deployments but demand significant admin time for upgrades, security patches, and etcd backups. For most teams, AKS total cost of ownership wins despite higher compute bills.
Enable Azure Policy for Kubernetes enforcement, disable local accounts and use Entra ID authentication, apply network policies restricting pod egress, rotate credentials regularly, enable Defender for Containers, restrict API server access via authorized IP ranges, and never run containers as root in production namespaces.
Yes, AKS supports rolling upgrades that surge new nodes before draining old ones. Maintain at least two nodes per pool, configure PodDisruptionBudgets for critical workloads, test upgrades in staging first, and schedule during low-traffic windows. Major version jumps require sequential minor upgrades.
Inspect logs with kubectl logs and events with kubectl describe pod. Common causes include missing environment variables, failed health checks, insufficient memory limits triggering OOMKill, or application startup errors. Fix configuration issues in ConfigMaps or Secrets rather than rebuilding images repeatedly.
Enable Container Insights during cluster creation for immediate metrics and log collection into Azure Monitor. It captures CPU, memory, network stats, and kube-system events without extra infrastructure. Graduate to Prometheus and Grafana only when custom alerting or cross-cluster federation becomes necessary.
Use Azure Application Gateway Ingress Controller for managed L7 routing with WAF protection. Alternatively, deploy NGINX Ingress Controller via Helm for full customization. Both integrate with cert-manager for automatic TLS. Avoid raw LoadBalancer services for HTTP traffic due to cost and limited routing capabilities.
Azure CNI exhausts subnet IPs when pod density exceeds available addresses. Plan subnets with at least 256 IPs per node pool. Monitor usage via az network vnet subnet show. Expand by adding secondary address spaces or migrating to larger subnets during maintenance windows, as in-place expansion has limitations.
Pick AKS when you need microservices orchestration, custom runtime environments, GPU workloads, or complex service mesh patterns. App Service handles traditional web apps faster with less operational burden. If your team lacks Kubernetes experience and the app fits PaaS constraints, start with App Service and migrate later.
