/azure-kubernetes

name: azure-kubernetes
license: MIT
metadata:
  author: Microsoft
  version: "1.2.2"
description: "Plan, create, and configure production-ready Azure Kubernetes Service (AKS) clusters. Covers Day-0 checklist, SKU selection (Automatic vs Standard), networking options (private API server, Azure CNI Overlay, egress configuration), security, and operations (autoscaling, upgrade strategy, cost analysis). WHEN: create AKS environment, provision AKS, enable AKS observability, design AKS networking, choose AKS SKU, secure AKS, optimize AKS, AKS spot nodes, AKS cluster-autoscaler, rightsize AKS pod, pod rightsizing, over-provisioned AKS pod, pod resource requests and limits, Vertical Pod Autoscaler, VPA recommendations."

Azure Kubernetes Service

> **AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE** > > This skill produces a **recommended AKS cluster configuration** based on user requirements, distinguishing **Day-0 decisions** (networking, API server — hard to change later) from **Day-1 features** (can enable post-creation). See [CLI reference](./references/cli-reference.md) for commands.

Quick Reference

| Property | Value | |----------|-------| | Best for | AKS cluster planning and Day-0 decisions | | MCP Tools | `mcp_azure_mcp_aks` | | CLI | `az aks create`, `az aks show`, `kubectl get`, `kubectl describe` | | Related skills | azure-kubernetes-app-deploy (deploy an app to an existing cluster), azure-diagnostics (troubleshooting AKS), azure-validate (readiness checks), azure-kubernetes-automatic-readiness (migrate existing cluster to AKS Automatic) |

When to Use This Skill

Activate this skill when user wants to:

• Create a new AKS cluster
• Plan AKS cluster configuration for production workloads
• Design AKS networking (API server access, pod IP model, egress)
• Set up AKS identity and secrets management
• Configure AKS governance (Azure Policy, Deployment Safeguards)
• Enable AKS observability (Container Insights, Managed Prometheus, Grafana)
• Define AKS upgrade and patching strategy
• Understand AKS Automatic vs Standard SKU differences
• Get a Day-0 checklist for AKS cluster setup and configuration

> **Deploying an application to an existing cluster?** This skill provisions and > configures the *cluster*. To containerize an app and deploy it to a cluster > that already exists (Dockerfile + manifests + Deployment Safeguards), use the > `azure-kubernetes-app-deploy` sub-skill instead.

Rules

1. Start with the user's requirements for provisioning compute, networking, security, and other settings. 2. Use the `azure` MCP server and select `mcp_azure_mcp_aks` first to discover the exact AKS-specific MCP tools surfaced by the client. Choose the smallest discovered AKS tool that fits the task, and fall back to Azure CLI (`az aks`) only when the needed functionality is not exposed through the AKS MCP surface. 3. Determine if AKS Automatic or Standard SKU is more appropriate based on the user's need for control vs convenience. Default to AKS Automatic unless specific customizations are required. 4. Document decisions and rationale for cluster configuration choices, especially for Day-0 decisions that are hard to change later (networking, API server access).

Required Inputs (Ask only what’s needed)

If the user is unsure, use safe defaults.

• AKS environment type: dev/test or production
• Region(s), availability zones, preferred node VM sizes
• Expected scale (node/cluster count, workload size)
• Networking requirements (API server access, pod IP model, ingress/egress control)
• Security and identity requirements, including image registry
• Upgrade and observability preferences
• Cost constraints

Workflow

1. Cluster Type

• **AKS Automatic** (default): Best for most production workloads, provides a curated experience with pre-configured best practices for security, reliability, and performance. Use unless you have specific custom requirements for networking, autoscaling, or node pool configurations not supported by Node Auto-Provisioning (NAP).
• **AKS Standard**: Use if you need full control over environment configuration, which requires additional overhead to set up and manage.

2. Networking (Pod IP, Egress, Ingress, Dataplane)

**Pod IP Model** (Key Day-0 decision):

• **Azure CNI Overlay** (recommended): pod IPs from private overlay range, not VNet-routable, scales to large environments and good for most workloads
• **Azure CNI (VNet-routable)**: pod IPs directly from VNet (pod subnet or node subnet), use when pods must be directly addressable from VNet or on-prem
• Docs: https://learn.microsoft.com/azure/aks/azure-cni-overlay

**Dataplane & Network Policy**:

• **Azure CNI powered by Cilium** (recommended): eBPF-based for high-performance packet processing, network policies, and observability

**Egress**:

• **Static Egress Gateway** for stable, predictable outbound IPs
• For restricted egress: UDR + Azure Firewall or NVA

**Ingress**:

• **App Routing addon with Gateway API** — recommended default for HTTP/HTTPS workloads
• **Istio service mesh with Gateway API** - for advanced traffic management, mTLS, canary releases
• **Application Gateway for Containers** — for L7 load balancing with WAF integration

**DNS**:

• Enable **LocalDNS** on all node pools for reliable, performant DNS resolution

3. Security

• Use **Microsoft Entra ID** everywhere (control plane, Workload Identity for pods, node access). Avoid static credentials.
• Azure Key Vault via **Secrets Store CSI Driver** for secrets
• Enable **Azure Policy** + **Deployment Safeguards**
• Enable **Encryption at rest** for etcd/API server; **in-transit** for node-to-node
• Allow only signed, policy-approved images (Azure Policy + Ratify), prefer **Azure Container Registry**
• **Isolation**: Use namespaces, network policies, scoped logging

4. Observability

• Use Managed Prometheus and Container Insights with Grafana for AKS observability (logs + metrics).
• Enable Diagnostic Settings to collect cont