AgentAlley
Submit

Azure Kubernetes Service skill

Plan, create, and configure production-ready Azure Kubernetes Service (AKS) clusters.

by microsoft·MIT license·★ 1,532 Stars on the repo·GitHub ↗

Use now

Files of Azure Kubernetes Service

microsoft/main1 file shown
SKILL.md
Show the full text159 lines
azure-kubernetes/SKILL.md159 lines · 10.6 KB
Outline
RawView on GitHub

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 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

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 control plane logs and audit logs in a Log Analytics workspace for security monitoring and troubleshooting.
  • For other monitoring and troubleshooting tools, use features like the Agentic CLI for AKS, Application Insights, Resource Health Center, AppLens detectors, and Azure Advisors.
5. Upgrades & Patching
  • Configure Maintenance Windows for controlled upgrade timing
  • Enable auto-upgrades for control plane and node OS to stay up-to-date with security patches and Kubernetes versions
  • Consider LTS versions for enterprise stability (2-year support) by upgrading your AKS environment to the Premium tier
  • Fleet upgrades: Use AKS Fleet Manager for staged rollout across test to production environments
6. Performance
  • Use Ephemeral OS disks (--node-osdisk-type Ephemeral) for faster node startup
  • Select Azure Linux as node OS (smaller footprint, faster boot)
  • Enable KEDA for event-driven autoscaling beyond HPA
7. Node Pools & Compute
  • Dedicated system node pool: At least 2 nodes, tainted for system workloads only (CriticalAddonsOnly)
  • Enable Node Auto Provisioning (NAP) on all pools for cost savings and responsive scaling
  • Use latest generation SKUs (v5/v6) for host-level optimizations
  • Avoid B-series VMs — burstable SKUs cause performance/reliability issues
  • Use SKUs with at least 4 vCPUs for production workloads
  • Set topology spread constraints to distribute pods across hosts/zones per SLO
8. Reliability
  • Deploy across 3 Availability Zones (--zones 1 2 3)
  • Use Standard tier for zone-redundant control plane + 99.95% SLA for API server availability
  • Enable Microsoft Defender for Containers for runtime protection
  • Configure PodDisruptionBudgets for all production workloads
  • Use topology spread constraints to ensure pod distribution across failure domains
9. Cost Controls
  • Use Spot node pools for batch/interruptible workloads (up to 90% savings)
  • Stop/Start dev/test clusters: az aks stop/start
  • Consider Reserved Instances or Savings Plans for steady-state workloads

Deep-dive scenarios — load only the relevant reference file:

Scenario Trigger Keywords Reference
Pod Rightsizing over-provisioned pods, CPU requests, memory requests, rightsize workloads azure-aks-rightsizing.md
VPA Setup vertical pod autoscaler, VPA recommendations, VPA enable azure-aks-vpa.md
Cluster Autoscaler idle nodes, CAS off, enable autoscaler, scale-down profile, node utilization azure-aks-autoscaler.md
Spot Node Pools Spot VMs, Spot nodes, batch workloads, cheaper nodes azure-aks-spot.md

Disambiguation: If a prompt matches multiple rows (e.g., "cheaper nodes" could suggest both Spot and autoscaler), prefer the most specific match. If ambiguous, ask the user to clarify their intent before loading a reference file.

Guardrails / Safety

  • Do not request or output secrets (tokens, keys).
  • Do not ask the user to paste subscription IDs. Discover subscription and resource scope via MCP tools (e.g., list subscriptions, list resource groups) or az account show / az account list so the agent can resolve context without exposing identifiers.
  • If requirements are ambiguous for day-0 critical decisions, ask the user clarifying questions. For day-1 enabled features, propose 2–3 safe options with tradeoffs and choose a conservative default.
  • Do not promise zero downtime; advise workload safeguards (PDBs, probes, replicas) and staged upgrades along with best practices for reliability and performance.

MCP Tools

Tool Purpose Key Parameters
mcp_azure_mcp_aks AKS MCP entry point used to discover the exact AKS-specific tools exposed by the client Discover the callable AKS tool first, then use that tool's parameters

Error Handling

Error / Symptom Likely Cause Remediation
MCP tool call fails or times out Invalid credentials, subscription, or AKS context Verify az login, confirm the active subscription context with az account show, and check the target resource group without echoing subscription identifiers back to the user
Quota exceeded Regional vCPU or resource limits Request quota increase or select different region/VM SKU
Networking conflict (IP exhaustion) Pod subnet too small for overlay/CNI Re-plan IP ranges; may require cluster recreation (Day-0)
Workload Identity not working Missing OIDC issuer or federated credential Enable --enable-oidc-issuer --enable-workload-identity, configure federated identity
1---
2name: azure-kubernetes
3license: MIT
4metadata:
5 author: Microsoft
6 version: "1.2.2"
7description: "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."
8---
9 
10# Azure Kubernetes Service
11 
12> **AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE**
13>
14> 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.
15 
16## Quick Reference
17| Property | Value |
18|----------|-------|
19| Best for | AKS cluster planning and Day-0 decisions |
20| MCP Tools | `mcp_azure_mcp_aks` |
21| CLI | `az aks create`, `az aks show`, `kubectl get`, `kubectl describe` |
22| 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) |
23 
24## When to Use This Skill
25Activate this skill when user wants to:
26- Create a new AKS cluster
27- Plan AKS cluster configuration for production workloads
28- Design AKS networking (API server access, pod IP model, egress)
29- Set up AKS identity and secrets management
30- Configure AKS governance (Azure Policy, Deployment Safeguards)
31- Enable AKS observability (Container Insights, Managed Prometheus, Grafana)
32- Define AKS upgrade and patching strategy
33- Understand AKS Automatic vs Standard SKU differences
34- Get a Day-0 checklist for AKS cluster setup and configuration
35 
36> **Deploying an application to an existing cluster?** This skill provisions and
37> configures the *cluster*. To containerize an app and deploy it to a cluster
38> that already exists (Dockerfile + manifests + Deployment Safeguards), use the
39> `azure-kubernetes-app-deploy` sub-skill instead.
40 
41## Rules
421. Start with the user's requirements for provisioning compute, networking, security, and other settings.
432. 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.
443. 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.
454. Document decisions and rationale for cluster configuration choices, especially for Day-0 decisions that are hard to change later (networking, API server access).
46 
47 
48## Required Inputs (Ask only what’s needed)
49If the user is unsure, use safe defaults.
50- AKS environment type: dev/test or production
51- Region(s), availability zones, preferred node VM sizes
52- Expected scale (node/cluster count, workload size)
53- Networking requirements (API server access, pod IP model, ingress/egress control)
54- Security and identity requirements, including image registry
55- Upgrade and observability preferences
56- Cost constraints
57 
58## Workflow
59 
60### 1. Cluster Type
61- **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).
62- **AKS Standard**: Use if you need full control over environment configuration, which requires additional overhead to set up and manage.
63 
64### 2. Networking (Pod IP, Egress, Ingress, Dataplane)
65 
66**Pod IP Model** (Key Day-0 decision):
67- **Azure CNI Overlay** (recommended): pod IPs from private overlay range, not VNet-routable, scales to large environments and good for most workloads
68- **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
69 - Docs: https://learn.microsoft.com/azure/aks/azure-cni-overlay
70 
71**Dataplane & Network Policy**:
72- **Azure CNI powered by Cilium** (recommended): eBPF-based for high-performance packet processing, network policies, and observability
73 
74**Egress**:
75- **Static Egress Gateway** for stable, predictable outbound IPs
76- For restricted egress: UDR + Azure Firewall or NVA
77 
78**Ingress**:
79- **App Routing addon with Gateway API** — recommended default for HTTP/HTTPS workloads
80- **Istio service mesh with Gateway API** - for advanced traffic management, mTLS, canary releases
81- **Application Gateway for Containers** — for L7 load balancing with WAF integration
82 
83**DNS**:
84- Enable **LocalDNS** on all node pools for reliable, performant DNS resolution
85 
86### 3. Security
87- Use **Microsoft Entra ID** everywhere (control plane, Workload Identity for pods, node access). Avoid static credentials.
88- Azure Key Vault via **Secrets Store CSI Driver** for secrets
89- Enable **Azure Policy** + **Deployment Safeguards**
90- Enable **Encryption at rest** for etcd/API server; **in-transit** for node-to-node
91- Allow only signed, policy-approved images (Azure Policy + Ratify), prefer **Azure Container Registry**
92- **Isolation**: Use namespaces, network policies, scoped logging
93 
94### 4. Observability
95- Use Managed Prometheus and Container Insights with Grafana for AKS observability (logs + metrics).
96- Enable Diagnostic Settings to collect control plane logs and audit logs in a Log Analytics workspace for security monitoring and troubleshooting.
97- For other monitoring and troubleshooting tools, use features like the Agentic CLI for AKS, Application Insights, Resource Health Center, AppLens detectors, and Azure Advisors.
98 
99### 5. Upgrades & Patching
100- Configure **Maintenance Windows** for controlled upgrade timing
101- Enable **auto-upgrades** for control plane and node OS to stay up-to-date with security patches and Kubernetes versions
102- Consider **LTS versions** for enterprise stability (2-year support) by upgrading your AKS environment to the Premium tier
103- **Fleet upgrades**: Use **AKS Fleet Manager** for staged rollout across test to production environments
104 
105### 6. Performance
106- Use **Ephemeral OS disks** (`--node-osdisk-type Ephemeral`) for faster node startup
107- Select **Azure Linux** as node OS (smaller footprint, faster boot)
108- Enable **KEDA** for event-driven autoscaling beyond HPA
109 
110### 7. Node Pools & Compute
111- **Dedicated system node pool**: At least 2 nodes, tainted for system workloads only (`CriticalAddonsOnly`)
112- Enable **Node Auto Provisioning (NAP)** on all pools for cost savings and responsive scaling
113- Use **latest generation SKUs (v5/v6)** for host-level optimizations
114- **Avoid B-series VMs** — burstable SKUs cause performance/reliability issues
115- Use SKUs with **at least 4 vCPUs** for production workloads
116- Set **topology spread constraints** to distribute pods across hosts/zones per SLO
117 
118### 8. Reliability
119- Deploy across **3 Availability Zones** (`--zones 1 2 3`)
120- Use **Standard tier** for zone-redundant control plane + 99.95% SLA for API server availability
121- Enable **Microsoft Defender for Containers** for runtime protection
122- Configure **PodDisruptionBudgets** for all production workloads
123- Use **topology spread constraints** to ensure pod distribution across failure domains
124 
125### 9. Cost Controls
126- Use **Spot node pools** for batch/interruptible workloads (up to 90% savings)
127- **Stop/Start** dev/test clusters: `az aks stop/start`
128- Consider **Reserved Instances** or **Savings Plans** for steady-state workloads
129 
130**Deep-dive scenarios** — load only the relevant reference file:
131 
132| Scenario | Trigger Keywords | Reference |
133|----------|-----------------|-----------|
134| Pod Rightsizing | over-provisioned pods, CPU requests, memory requests, rightsize workloads | [azure-aks-rightsizing.md](./references/azure-aks-rightsizing.md) |
135| VPA Setup | vertical pod autoscaler, VPA recommendations, VPA enable | [azure-aks-vpa.md](./references/azure-aks-vpa.md) |
136| Cluster Autoscaler | idle nodes, CAS off, enable autoscaler, scale-down profile, node utilization | [azure-aks-autoscaler.md](./references/azure-aks-autoscaler.md) |
137| Spot Node Pools | Spot VMs, Spot nodes, batch workloads, cheaper nodes | [azure-aks-spot.md](./references/azure-aks-spot.md) |
138 
139> **Disambiguation:** If a prompt matches multiple rows (e.g., "cheaper nodes" could suggest both Spot and autoscaler), prefer the most specific match. If ambiguous, ask the user to clarify their intent before loading a reference file.
140 
141## Guardrails / Safety
142- Do not request or output secrets (tokens, keys).
143- Do not ask the user to paste subscription IDs. Discover subscription and resource scope via MCP tools (e.g., list subscriptions, list resource groups) or `az account show` / `az account list` so the agent can resolve context without exposing identifiers.
144- If requirements are ambiguous for day-0 critical decisions, ask the user clarifying questions. For day-1 enabled features, propose 2–3 safe options with tradeoffs and choose a conservative default.
145- Do not promise zero downtime; advise workload safeguards (PDBs, probes, replicas) and staged upgrades along with best practices for reliability and performance.
146 
147## MCP Tools
148| Tool | Purpose | Key Parameters |
149|------|---------|----------------|
150| `mcp_azure_mcp_aks` | AKS MCP entry point used to discover the exact AKS-specific tools exposed by the client | Discover the callable AKS tool first, then use that tool's parameters |
151 
152## Error Handling
153| Error / Symptom | Likely Cause | Remediation |
154|-----------------|--------------|-------------|
155| MCP tool call fails or times out | Invalid credentials, subscription, or AKS context | Verify `az login`, confirm the active subscription context with `az account show`, and check the target resource group without echoing subscription identifiers back to the user |
156| Quota exceeded | Regional vCPU or resource limits | Request quota increase or select different region/VM SKU |
157| Networking conflict (IP exhaustion) | Pod subnet too small for overlay/CNI | Re-plan IP ranges; may require cluster recreation (Day-0) |
158| Workload Identity not working | Missing OIDC issuer or federated credential | Enable `--enable-oidc-issuer --enable-workload-identity`, configure federated identity |
159 

Discussion

Alternatives

Azure app onboardEnd-to-end orchestrator: from a business idea, app idea, or existing app to running Azure deployment with cost estimates and pre-deploy approval. Analyzes your app, auto-detects the right Azure services, scaffolds infrastructure code, and deploys — tailored to your app, not a template. Handles moving existing apps to Azure without rewriting or with minimal changes. WHEN: bring your app to Azure, plan my app, cost to run, is my code ready to deploy, deploy my app to the cloud, deploy all my services, what Azure services do I need, plan my Azure deployment, deploy my new app to Azure, one-click deploy, I have an app and want it on Azure, migrate my app to Azure, help me get started, build an app, no code yet, starter project. DO NOT USE FOR: use azd for deployment(use azure-deploy), optimizing existing costs (use cost-optimization), code readiness checks only (use azure-app-onboard-prereq).Infrastructure & ops · MITAzure App Onboard Prereq — Repository EvaluationAssess whether source code is ready to deploy to Azure — the check BEFORE infrastructure work. Evaluates build health, app completeness, dependencies and local services, stack compatibility, and deployment feasibility. Answers questions about what your app needs before it can be deployed — frameworks, dependencies, and configuration. Checks whether dependencies are compatible and identifies deployment blockers and unsupported frameworks. WHEN: "evaluate my repo", "is my app ready to deploy", "what does my app need to deploy", "what do I need before deploying", "does my app need", "can I ship this to Azure", "scan my repo for issues", "is this app deployable", "check if my app is ready for Azure", "do I need a Dockerfile", "what's blocking my deployment", "are there any blockers", "are my dependencies compatible", "does Azure support my framework", "what needs to change before deploying", "check my app configuration".Infrastructure & ops · MITDocker MCP gatewayDocker's own CLI plugin: run any server from the Docker MCP Catalog in its own container, behind one connection, with secrets kept out of env vars.Coding · MITAzure cloud migrateAssess and migrate cross-cloud workloads to Azure with reports and code conversion. Supports Lambda→Functions, Beanstalk/Heroku/App Engine→App Service, Fargate/Kubernetes/Cloud Run/Spring Boot→Container Apps. WHEN: migrate Lambda to Functions, AWS to Azure, migrate Beanstalk, migrate Heroku, migrate App Engine, Cloud Run migration, Fargate to ACA, ECS/Kubernetes/GKE/EKS to Container Apps, Spring Boot to Container Apps, cross-cloud migration.Infrastructure & ops · MIT

Browse more free Claude skills or everything in Development.