Phase 1: Preparing Azure CLI for Production AKS (Region: East US 2)

Before deploying a production-grade AKS cluster, you must properly configure Azure CLI, subscription settings, networking, and identity.

This guide walks through the exact foundational steps used by platform engineers when building AKS in eastus2.

---

🎯 Goal of Phase 1

By the end of this phase, you will have:

• Azure CLI installed and configured
• Subscription properly selected
• Default region set to eastus2
• Resource Group created
• Virtual Network + Subnet created
• Managed Identity created
• Required Azure resource providers registered

This sets the stage for production AKS deployment.

---

🛠 Step 1 — Install Azure CLI

On Ubuntu / WSL:

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

Verify installation:

az version

You are now ready to manage resources in:

• Microsoft Azure

---

🔐 Step 2 — Authenticate

az login

This authenticates via:

• Microsoft Entra ID

List available subscriptions:

az account list --output table

Set your working subscription:

az account set --subscription "<SUBSCRIPTION_ID>"

Confirm:

az account show --output table

---

🌍 Step 3 — Set Default Region to East US 2

Instead of specifying --location every time:

az configure --defaults location=eastus2

Verify available regions:

az account list-locations --output table

Now all new resources default to:

eastus2

---

📦 Step 4 — Create Resource Group

Resource Groups logically organize infrastructure.

az group create \
  --name aks-east2-rg

Verify:

az group show --name aks-east2-rg --output table

---

🌐 Step 5 — Create Production Networking (VNet + Subnet)

We prepare networking before creating AKS.

az network vnet create \
  --resource-group aks-east2-rg \
  --name aks-vnet \
  --address-prefix 10.0.0.0/8 \
  --subnet-name aks-subnet \
  --subnet-prefix 10.240.0.0/16

This creates:

• Virtual Network
• Subnet dedicated for AKS

This integrates later with:

• Azure Virtual Network

---

🔐 Step 6 — Create Managed Identity

Modern AKS uses Managed Identity instead of Service Principals.

az identity create \
  --resource-group aks-east2-rg \
  --name aks-mi

Capture:

• principalId
• clientId
• id

This identity will later allow AKS to manage networking and cloud resources securely.

---

🚨 Step 7 — Register Required Resource Providers

When enabling monitoring later, many users hit this error:

MissingSubscriptionRegistration:
Microsoft.OperationalInsights

This happens because new subscriptions do not automatically register all providers.

Register them once:

az provider register --namespace Microsoft.OperationalInsights
az provider register --namespace Microsoft.ContainerService
az provider register --namespace Microsoft.Network
az provider register --namespace Microsoft.Compute

Verify registration:

az provider show \
  --namespace Microsoft.OperationalInsights \
  --query registrationState

Wait until:

Registered

Why this matters:

Monitoring uses:

• Azure Monitor
• Log Analytics

Which depend on the Microsoft.OperationalInsights namespace.

This step prevents AKS deployment failures later.

---

🧠 What You Learned in Phase 1

You now understand:

• Azure subscription context management
• Default region configuration
• Azure networking basics for AKS
• Managed identity creation
• Azure provider registration mechanics
• Why monitoring requires Operational Insights

Most AKS failures in real environments happen because Phase 1 was skipped or done incorrectly.

You’ve now built a clean, production-ready foundation.

---

🏗 Current Architecture State

Subscription
│
└── Resource Group: aks-east2-rg
    ├── Virtual Network: aks-vnet
    │   └── Subnet: aks-subnet
    └── Managed Identity: aks-mi

No Kubernetes cluster yet — just solid groundwork.

---

⏭ What’s Next?

In Phase 2, we will:

• Attach AKS to existing VNet
• Use Azure CNI
• Assign network roles to Managed Identity
• Enable OIDC & Workload Identity
• Enable Monitoring
• Deploy a production-ready cluster