$npx -y skills add microsoft/azure-skills --skill azure-kubernetesPlan, 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 st
| 1 | # Azure Kubernetes Service |
| 2 | |
| 3 | > **AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE** |
| 4 | > |
| 5 | > 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. |
| 6 | |
| 7 | ## Quick Reference |
| 8 | | Property | Value | |
| 9 | |----------|-------| |
| 10 | | Best for | AKS cluster planning and Day-0 decisions | |
| 11 | | MCP Tools | `mcp_azure_mcp_aks` | |
| 12 | | CLI | `az aks create`, `az aks show`, `kubectl get`, `kubectl describe` | |
| 13 | | Related skills | azure-diagnostics (troubleshooting AKS), azure-validate (readiness checks), azure-kubernetes-automatic-readiness (migrate existing cluster to AKS Automatic) | |
| 14 | |
| 15 | ## When to Use This Skill |
| 16 | Activate this skill when user wants to: |
| 17 | - Create a new AKS cluster |
| 18 | - Plan AKS cluster configuration for production workloads |
| 19 | - Design AKS networking (API server access, pod IP model, egress) |
| 20 | - Set up AKS identity and secrets management |
| 21 | - Configure AKS governance (Azure Policy, Deployment Safeguards) |
| 22 | - Enable AKS observability (Container Insights, Managed Prometheus, Grafana) |
| 23 | - Define AKS upgrade and patching strategy |
| 24 | - Understand AKS Automatic vs Standard SKU differences |
| 25 | - Get a Day-0 checklist for AKS cluster setup and configuration |
| 26 | |
| 27 | ## Rules |
| 28 | 1. Start with the user's requirements for provisioning compute, networking, security, and other settings. |
| 29 | 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. |
| 30 | 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. |
| 31 | 4. Document decisions and rationale for cluster configuration choices, especially for Day-0 decisions that are hard to change later (networking, API server access). |
| 32 | |
| 33 | |
| 34 | ## Required Inputs (Ask only what’s needed) |
| 35 | If the user is unsure, use safe defaults. |
| 36 | - AKS environment type: dev/test or production |
| 37 | - Region(s), availability zones, preferred node VM sizes |
| 38 | - Expected scale (node/cluster count, workload size) |
| 39 | - Networking requirements (API server access, pod IP model, ingress/egress control) |
| 40 | - Security and identity requirements, including image registry |
| 41 | - Upgrade and observability preferences |
| 42 | - Cost constraints |
| 43 | |
| 44 | ## Workflow |
| 45 | |
| 46 | ### 1. Cluster Type |
| 47 | - **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). |
| 48 | - **AKS Standard**: Use if you need full control over environment configuration, which requires additional overhead to set up and manage. |
| 49 | |
| 50 | ### 2. Networking (Pod IP, Egress, Ingress, Dataplane) |
| 51 | |
| 52 | **Pod IP Model** (Key Day-0 decision): |
| 53 | - **Azure CNI Overlay** (recommended): pod IPs from private overlay range, not VNet-routable, scales to large environments and good for most workloads |
| 54 | - **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 |
| 55 | - Docs: https://learn.microsoft.com/azure/aks/azure-cni-overlay |
| 56 | |
| 57 | **Dataplane & Network Policy**: |
| 58 | - **Azure CNI powered by Cilium** (recommended): eBPF-based for high-performance packet processing, network policies, and observability |
| 59 | |
| 60 | **Egress**: |
| 61 | - **Static Egress Gateway** for stable, predictable outbound IPs |
| 62 | - For restricted egress: UDR + Azure Firewall or NVA |
| 63 | |
| 64 | **Ingress**: |
| 65 | - **App Routing addon with Gateway API** — recommended default for HTTP/HTTPS workloads |
| 66 | - **Istio service mesh with Gateway API** - for advanced traffic management, mTLS, canary releases |
| 67 | - **Application Gateway for Containers** — for L7 load balancing with WAF integration |
| 68 | |
| 69 | **DNS**: |
| 70 | - Enable **LocalDNS** on all node pools for reliable, performant DNS resolution |
| 71 | |
| 72 | ### 3. Security |
| 73 | - Use **Microsoft Entra |