Step-By-Step Azure Kubernetes Service Cluster Deployment

If you’re interested in learning how to build a complete enterprise Kubernetes Clustering Service, this is covered in detail here: Mastering Azure Kubernetes Advanced Infrastructure Deployment and Security - Special Edition

1. Purpose of the AKS Cluster

An Azure Kubernetes Service Cluster is used to run Containerized Applications. AKS is not a Traditional Server Platform where Administrators RDP into Servers and install Software manually. AKS provides a Managed Kubernetes Platform where Applications run as Containers inside Pods on Worker Nodes.

In AKS, Microsoft manages the Kubernetes Control Plane, including the API Server, Scheduler, Controllers, and etcd. Microsoft Maintains and Operates the Managed Control Plane Components.

2. High-Level Architecture

Azure Subscription
│
Resource Group
│
Virtual Network
│
AKS Cluster
│
├── Microsoft-Managed Control Plane
│   ├── API Server
│   ├── Scheduler
│   ├── Controllers
│   └── etcd
│
└── Customer-Managed Infrastructure Layer
    ├── System Node Pool
    │   ├── Node 1
    │   ├── Node 2
    │   └── Node 3
    │
    ├── Linux Application Node Pool
    │   ├── Node 1
    │   ├── Node 2
    │   └── Node 3
    │
    └── Windows Application Node Pool
        ├── Node 1
        ├── Node 2
        └── Node 3

3. Main AKS Components

AKS Cluster
Cluster-Scoped Resources

Nodes
Node Pools
Persistent Volumes
StorageClasses
Namespaces themselves
ClusterRoles
ClusterRoleBindings
CustomResourceDefinitions

The AKS Cluster is the complete Kubernetes Environment. It contains the Managed Control Plane and the Worker Node Pools where Workloads run.

Control Plane

The Control Plane is the Brain of Kubernetes. In AKS, Microsoft Manages it. You do not select the Control Plane Nodes, Size them, Patch them, or back Up etcd (et cetera distributed) directly.

Etcd (Et Cetera Distributed)

etcd is the Kubernetes State Database. It stores Cluster State, Desired Configuration, Services, Deployments, Secrets, ConfigMaps, and RBAC Objects. In AKS, Microsoft manages etcd because Microsoft Manages the Control Plane.

Node Pool

A Node Pool is a Logical Group of Worker Nodes with the Same General Configuration. AKS Groups Nodes of the same configuration into Node Pools, and those Pools Contain the underlying VM Scale sets and VMs that run Applications.

Node

A Node is an individual Azure VM/Server inside a Node Pool. Nodes provide CPU, RAM, Networking, and the OS Kernel required to run Pods and containers.

The entire Kubernetes Cluster may have maximum of 5000 Nodes and the 5000 Nodes can be allocated into max of 100 Node Pools and each Node Pool cannot have more than 1000 Nodes in the Node Pool

Max of 1000 Nodes per Node Pool
Max of 100 Node Pools per Cluster
Max of 5000 Total Nodes per Cluster

Namespace
Namespace Commonly Contains:
Pods
Deployments
Services
Secrets
ConfigMaps
Ingress rules
Persistent Volume Claims
Jobs
CronJobs
Service Accounts
RBAC Objects

A Kubernetes Namespace is a Logical Organizational and Administrative Boundary inside a Kubernetes Cluster used to separate, organize, and manage Kubernetes Resources such as Pods, Services, Deployments, Secrets, and Configurations. Namespaces provide Workload Isolation, Resource Organization, RBAC Security Boundaries, and Operational Separation for Teams, Applications, and Environments within the same Cluster.

Pod
A Pod is the smallest deployable and schedulable unit in Kubernetes. A Pod typically contains one or more Containers that run Application Instances.

Container
The Container contains the Application, runtime, Dependencies, Libraries, and Startup configuration. The Container does not contain a full OS Kernel; it uses the node OS Kernel.

Service
A Kubernetes Service Provides a stable Virtual IP and DNS Name for accessing Pods. Pods are temporary, but Services provide stable Access.

Ingress Controller
An Ingress Controller is a Layer 7 Routing Component, similar to a Reverse Proxy or Smart Load Balancer. It allows One Public IP to Route Traffic to Multiple Applications based on Hostname or Path.

4. Responsibility Model

Microsoft Responsibility
Control plane
API server
Scheduler
Core controllers
etcd
Control plane HA
Control plane patching
Control plane resiliency

Customer Responsibility
VNet and subnet planning
Node pools
Worker node sizing
Pod and app deployment
Ingress design
Application data backup
Persistent volume backup
Container images
YAML manifests
Helm charts
Security policies
Monitoring
RBAC

5. Network Planning Requirements

Before creating the AKS cluster, design the network carefully.

You should plan:

VNet Address Space
AKS Subnet
Node IPs
Pod IPs
Service CIDR
DNS Service IP
Ingress Public/Private IPs
Outbound Connectivity
Firewall Routing
Private Endpoint Integration
Hybrid Connectivity
Network Policies
Future Growth

Kubernetes networking is more IP-intensive than traditional VM networking because Kubernetes nodes, pods, services, load balancers, and ingress endpoints all require network planning. Microsoft’s AKS networking guidance explains that Kubernetes uses a virtual networking layer for access within and between applications and components.

6. Recommended Example Network Design

VNet
10.0.0.0/16
AKS Node Subnet
10.0.1.0/24
Kubernetes Service CIDR
10.100.0.0/16
DNS Service IP
10.100.0.10
Docker Bridge CIDR
172.17.0.1/16
Ingress Public IP
Example: 52.x.x.x

A /24 Subnet is a reasonable starting point for many small to medium AKS Environments because it gives roughly 251 usable Azure IP Addresses. A /27 is usually too small for production AKS because Scaling, Upgrades, Node Growth, and Pod Growth can Exhaust the Subnet Quickly.

7. IP Address Planning Rules

Node IPs
Each AKS node requires an IP Address from the AKS Subnet.

Example:

Node Pool: prod-linux-web
Node 1: 10.0.1.10
Node 2: 10.0.1.11
Node 3: 10.0.1.12

Pod IPs
Pods may require IPs depending on the AKS Networking Model.
With Azure CNI, Pod IP behavior is especially Important. Microsoft Documents that maximum Pods per Node vary by Networking Model, with Azure CNI Overlay supporting up to 250 Pods per Node and Azure CNI Pod Subnet Defaulting to 110, configurable up to 250.

Service IPs
Kubernetes Services use Virtual IPs from the Service CIDR.
Example:

Payroll Service: 10.100.0.20
HR Service: 10.100.0.21
Inventory Service: 10.100.0.22

Ingress IPs

Ingress IPs are usually much fewer than Private IPs. One Ingress Public IP can expose many Applications.

Example:

52.x.x.x
payroll.company.com
hr.company.com
inventory.company.com
api.company.com

All can Route through one Ingress Controller.

8. Example AKS IP Layout

AKS Cluster
│
├── Ingress Public IP
│   52.160.10.50
│
├── Service CIDR
│   10.100.0.0/16
│
└── AKS Subnet
    10.0.1.0/24

 Example with Three Node Pools:

Node Pool 1: Prod-System
├── Node 1: 10.0.1.10
├── Node 2: 10.0.1.11
└── Node 3: 10.0.1.12

Node Pool 2: Prod-Linux-Apps
├── Node 1: 10.0.1.20
├── Node 2: 10.0.1.21
└── Node 3: 10.0.1.22

Node Pool 3: Prod-Windows-Apps
├── Node 1: 10.0.1.30
├── Node 2: 10.0.1.31
└── Node 3: 10.0.1.32

If each Node runs three Application Pod instances:

9 Total Nodes
3 Pods Per Node
27 Total Pods

9. Node Pool Planning Rules

You always have at least One Node Pool in AKS. Even if you create One Node, that Node belongs to a Node Pool.

Use Multiple Node Pools when you Need different:

Operating Systems
VM Sizes
Scaling Behavior
Workload Isolation
Security Boundaries
Hardware Types
Cost Models

Example:

Prod-System
For Kubernetes System Pods
Prod-Linux-Web
For Linux Web Applications
Prod-Linux-API
For Linux API workloads
prod-windows-apps
For Windows containers, IIS, and .NET Framework applications

Windows Server Node Pools can run native Windows Container Applications such as .NET Framework Workloads. Microsoft recommends creating AKS Clusters with Linux and Windows Node Pools for Windows Container Scenarios.

10. Recommended Production Node Pool Design

AKS Cluster: AKS-Prod-EastUS

System Node Pool
Name: syspool
OS: Linux
Nodes: 3
Purpose: Core Kubernetes system services

Linux App Node Pool
Name: prodlinux
OS: Linux
Nodes: 3 or more
Purpose: Web apps, APIs, ingress, monitoring

Windows App Node Pool
Name: prodwin
OS: Windows Server
Nodes: 2 or more
Purpose: IIS, ASP.NET Framework, Windows containers

11. High Availability Planning
A Node Pool alone is not High Availability. HA comes from:

Multiple Nodes
Multiple Pod Replicas
Availability Zones
Load Balancing
Self-Healing
Pod Anti-Affinity
Rolling Updates

Example:
Deployment Replicas: 3
Pod 1 runs on Node 1
Pod 2 runs on Node 2
Pod 3 runs on Node 3

If one Node fails, the remaining Pods continue Serving Traffic.

12. Application Deployment Model
Applications are Not Installed Manually onto AKS Nodes.
Correct Model:

Application Code
│
Dockerfile
│
Container Image
│
Azure Container Registry
│
Kubernetes Deployment
│
Pods
│
Nodes

Developers usually create or maintain the Application and Container Image. Kubernetes Administrators or DevOps/Platform Teams control Deployment Governance, RBAC, Namespace Access, Ingress, Scaling, Monitoring, and Security.

13. Container Registry Requirement

Use Azure Container Registry (ACR) to Store Approved Container Images.

Example:

myregistry.azurecr.io/payroll:v1
myregistry.azurecr.io/hr:v1
myregistry.azurecr.io/inventory:v1

The AKS Cluster pulls Images from Azure Container Registry (ACR) and runs them as Containers inside Pods.

14. Ingress Planning
Ingress is usually deployed after AKS Cluster Creation.
Common ingress options:

NGINX Ingress Controller
Azure Application Gateway Ingress Controller
Traefik
Istio Gateway

Common Enterprise Design:

Internet
│
Public IP
│
WAF or Application Gateway
│
Ingress Controller
│
Kubernetes Service
│
Pods

One Public IP can serve many Applications through Hostname Routing:

payroll.company.com → Payroll Service
hr.company.com → HR Service
api.company.com → API Service

15. Private Cluster Decision

For production, consider a private AKS cluster. A private cluster makes the Kubernetes API server reachable privately instead of publicly. Microsoft provides AKS private cluster deployment guidance for this model.

Use Private Cluster when you require:

No public Kubernetes API exposure
Enterprise security boundary
Hub-spoke network integration
Azure Firewall inspection
ExpressRoute/VPN administrative access

16. Security Requirements

Before Deploying Workloads, Configure:

Microsoft Entra ID integration
Kubernetes RBAC
Azure RBAC for AKS
Namespace separation
Network Policies
Private ACR access
Managed identities
Key Vault integration
Image scanning
Pod security controls
Secrets management
Ingress TLS
WAF if public-facing

17. Monitoring Requirements

Deploy or Enable:

Azure Monitor Container Insights
Log Analytics workspace
Prometheus
Grafana
Alert rules
Node health monitoring
Pod health monitoring
Ingress logs
Application logs
Resource utilization dashboards

Monitor:

Node CPU
Node Memory
Pod CPU
Pod Memory
Pod Restarts
Pending Pods
Failed Deployments
IP Exhaustion Risk
Ingress Errors
DNS Errors
Storage Mount Failures

18. Backup and Recovery Requirements

In AKS, you do not directly back up etcd. Microsoft manages the control plane and etcd infrastructure.

You still must protect:

Application Data
Persistent Volumes
Azure Disks
Azure Files
Databases
Container Images
YAML Manifests
Helm Charts
Git Repositories
Secrets
Ingress Configuration
Terraform/Bicep Templates

Best Practice:

Use Git as the Source of Truth
Store Manifests and Helm Charts in Git
Use Infrastructure as Code
Back up Persistent Storage
Back up Databases Separately
Document Restore Procedures
Test Recovery Regularly

19. Step-by-Step AKS Deployment Process

Step 1: Define Requirements

Document:

Environment: Prod/Dev/Test
Region
Expected Applications
Linux or Windows Workloads
Expected Nodes
Expected Pods
Public or Private Access
Hybrid Connectivity
Security Requirements
Backup Requirements
Monitoring Requirements

Step 2: Design Network
Define:

vNet CIDR
AKS subnet CIDR
Service CIDR
DNS IP
Pod networking model
Ingress IP model
Firewall Routes
Private Endpoint Strategy

Recommended Starting Point:

VNet: 10.0.0.0/16
AKS Subnet: 10.0.1.0/24
Service CIDR: 10.100.0.0/16
DNS IP: 10.100.0.10

Step 3: Create Resource Group

az group create \
  --name rg-aks-prod \
  --location eastus

Step 4: Create VNet and Subnet

az network vnet create \
  --resource-group rg-aks-prod \
  --name vnet-aks-prod \
  --address-prefix 10.0.0.0/16 \
  --subnet-name snet-aks-nodes \
  --subnet-prefix 10.0.1.0/24

Step 5: Create Azure Container Registry

az acr create \
  --resource-group rg-aks-prod \
  --name acrprod001 \
  --sku Premium

Step 6: Create AKS Cluster

Example:

az aks create \
  --resource-group rg-aks-prod \
  --name aks-prod-eastus \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5 \
  --network-plugin azure \
  --service-cidr 10.100.0.0/16 \
  --dns-service-ip 10.100.0.10 \
  --enable-managed-identity \
  --attach-acr acrprod001 \
  --generate-ssh-keys

Step 7: Add Linux Application Node Pool

az aks nodepool add \
  --resource-group rg-aks-prod \
  --cluster-name aks-prod-eastus \
  --name prodlinux \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5 \
  --os-type Linux

 Step 8: Add Windows Application Node Pool

az aks nodepool add \
  --resource-group rg-aks-prod \
  --cluster-name aks-prod-eastus \
  --name prodwin \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5 \
  --os-type Windows

Step 9: Connect to Cluster

az aks get-credentials \
  --resource-group rg-aks-prod \
  --name aks-prod-eastus

 Validate:

kubectl get nodes
kubectl get pods -A
kubectl get namespaces

Step 10: Deploy Ingress Controller

Example NGINX ingress using Helm:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-basic \
  --create-namespace

Step 11: Deploy Application

Example deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payroll-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payroll-app
  template:
    metadata:
      labels:
        app: payroll-app
    spec:
      containers:
      - name: payroll-app
        image: acrprod001.azurecr.io/payroll:v1
        ports:
        - containerPort: 80

Step 12: Create Kubernetes Service

apiVersion: v1
kind: Service
metadata:
  name: payroll-service
spec:
  selector:
    app: payroll-app
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

Step 13: Create Ingress Rule

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: payroll-ingress
spec:
  rules:
  - host: payroll.company.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: payroll-service
            port:
              number: 80

20. Final Recommended Design Summary

Use AKS for containerized apps, especially web apps, APIs, services, and scalable workloads.
Use at least one system node pool.
Use separate user node pools for different workload types.
Use Linux node pools for most Kubernetes ecosystem services.
Use Windows node pools only for Windows container workloads.
Use a /24 or larger subnet for serious AKS deployments.
Avoid /27 except for very small labs.
Use ingress for public access.
Use one public IP for many apps when possible.
Do not manually manage etcd in AKS.
Protect workloads, manifests, images, persistent data, and Git repositories.
Use private clusters for stronger enterprise security.
Plan network and IP space before creating the cluster.

21. Simple Mental Model

Microsoft manages the Kubernetes brain.
You manage the worker body.
Node pools group the worker servers.
Nodes provide compute.
Pods run app instances.
Containers contain the apps.
Services provide stable internal access.
Ingress provides external application access.

Step-by-Step AKS Storage Configuration 

1. Purpose

AKS storage is used to provide persistent and temporary storage for containerized applications. In AKS, containers should generally be treated as stateless, while important business data should be stored outside the container and outside the node local disk.

2. Main AKS Storage Types and Storage Responsibility Model

3. AKS Storage Architecture

4. Key Kubernetes Storage Objects

StorageClass

A StorageClass defines the type of storage Kubernetes can dynamically provision.

Examples:

managed-csi
managed-csi-premium
azurefile-csi
azurefile-csi-premium

AKS uses CSI drivers to connect Kubernetes to Azure Disks, Azure Files, and Azure Blob storage. Microsoft states that CSI support in AKS allows Azure Disks, Azure Files, or Azure Blob storage to be used as persistent storage for AKS applications.

Persistent Volume

A Persistent Volume represents the actual storage resource.

Example:

100 GB Azure Managed Disk
Azure Files share
Azure NetApp Files volume

Persistent Volume Claim

A Persistent Volume Claim is the application’s request for storage.

Example:

Application requests 100 GB persistent storage

5. When Storage Is Configured

Storage is usually configured after the AKS cluster is created and before or during application deployment.

1. Create AKS cluster
2. Confirm CSI drivers and StorageClasses
3. Create or select storage backend
4. Create PVC
5. Deploy application pod
6. Mount storage into container

Storage is not usually attached to the cluster like traditional shared cluster storage. Instead, workloads request storage through PVCs.

6. Step 1: Validate Available StorageClasses

Run:

kubectl get storageclass

Typical Result:

managed-csi
managed-csi-premium
azurefile-csi
azurefile-csi-premium

AKS includes built-in storage classes and reconciles the default storage classes, so Microsoft warns that changes to default storage classes may be overwritten.

7. Step 2: Choose the Correct Storage Type

Use Azure Managed Disk when the workload needs block storage and is usually attached to one pod.

Good For:

SQL Server
PostgreSQL
MongoDB
Single-instance stateful applications
High-performance block storage

Microsoft’s Azure Disk AKS guidance describes Azure Disk persistent volumes as storage for use by a single pod.

Use Azure Files when multiple pods need shared access to the same storage.

Good For:

Shared uploads
Shared configuration files
SMB file shares
Windows container workloads
Multiple pod access

Microsoft’s Azure Files AKS guidance states that Azure Files can be used when multiple pods need concurrent access to the same storage volume, using SMB or NFS.

Use Azure Blob Storage when the application needs object storage.

Good For:

Backups
Archives
Documents
Logs
Images
Videos
Large object storage

Use Azure NetApp Files when enterprise-grade high performance shared storage is required.

Good For:

Large databases
SAP workloads
Oracle workloads
High-throughput file workloads
Low-latency enterprise storage

8. Step 3: Create PVC for Azure Disk

Example PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: payroll-disk-pvc
  namespace: payroll-prod
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: managed-csi-premium
  resources:
    requests:
      storage: 100Gi

Apply:

kubectl apply -f payroll-disk-pvc.yaml

9. Step 4: Mount Azure Disk Into a Pod

Example Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payroll-app
  namespace: payroll-prod
spec:
  replicas: 1
  selector:
    matchLabels:
      app: payroll-app
  template:
    metadata:
      labels:
        app: payroll-app
    spec:
      containers:
      - name: payroll-app
        image: acrprod001.azurecr.io/payroll:v1
        volumeMounts:
        - mountPath: /data
          name: payroll-storage
      volumes:
      - name: payroll-storage
        persistentVolumeClaim:
          claimName: payroll-disk-pvc

10. Step 5: Create PVC for Azure Files

Example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-files-pvc
  namespace: payroll-prod
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: azurefile-csi-premium
  resources:
    requests:
      storage: 100Gi

Apply:
kubectl apply -f shared-files-pvc.yaml

11. Step 6: Mount Azure Files Into a Pod

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payroll-web
  namespace: payroll-prod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payroll-web
  template:
    metadata:
      labels:
        app: payroll-web
    spec:
      containers:
      - name: payroll-web
        image: acrprod001.azurecr.io/payroll-web:v1
        volumeMounts:
        - mountPath: /shared
          name: shared-files
      volumes:
      - name: shared-files
        persistentVolumeClaim:
          claimName: shared-files-pvc

This allows multiple pods to use the same shared storage.

12. Step 7: Validate Storage

Run:

kubectl get pvc -n payroll-prod
kubectl get pv
kubectl describe pvc shared-files-pvc -n payroll-prod
kubectl describe pod payroll-web -n payroll-prod

Check:

PVC status is Bound
PV exists
Pod is Running
Volume is mounted
Application can write to mounted path

13. Step 8: Configure Backup

Back up persistent application data.

Recommended Backup Targets:

Azure Disks
Azure Files
Databases
Blob Storage
Application files
Persistent volumes

Do not rely on node local storage for business data.

Microsoft’s AKS storage best practices emphasize understanding application performance and access needs, selecting the right storage type, and planning backup and restore testing for attached storage.

14. Best Practices

Use external persistent storage for business data.
Do not store critical data inside containers.
Do not rely on node local disks for persistent application data.
Use Azure Container Registry for container images.
Use Azure Disk for single-pod block storage workloads.
Use Azure Files for shared multi-pod storage.
Use Azure NetApp Files for high-performance enterprise shared storage.
Use Blob Storage for object storage, backups, archives, and logs.
Use PVCs instead of hard-coding storage directly into pods.
Use StorageClasses for repeatable storage provisioning.
Use separate storage classes for performance tiers.
Use encryption at rest.
Use private endpoints where required.
Use managed identities and least privilege permissions.
Back up application data separately from AKS control plane.
Test restore procedures regularly.
Keep Kubernetes manifests, Helm charts, and storage definitions in Git.
Do not modify AKS default storage classes directly if avoidable, because AKS may reconcile default classes.

15. Summary
Container Images → Azure Container Registry
Temporary Runtime Data → Node Local Storage
Persistent Single-Pod Data → Azure Managed Disk
Persistent Shared Data → Azure Files or Azure NetApp Files
Object Data and Backups → Azure Blob Storage
Kubernetes Cluster State → etcd, managed by Microsoft in AKS

If you’re interested in learning how to build a complete enterprise Kubernetes Clustering Service, this is covered in detail here: Mastering Azure Kubernetes Advanced Infrastructure Deployment and Security - Special Edition