Azure Kubernetes

MicrosoftOfficialCreated by Microsoft

Skill
Workflow
Cloud and DevOps
MIT
No issues found

From the author

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.

— the description by Microsoft

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a comprehensive framework for designing and managing Azure Kubernetes Service (AKS) clusters. It guides users through critical Day-0 architectural decisions—such as networking models, SKU selection, and security configurations—that are difficult to modify after deployment. The skill also covers ongoing operational tasks including observability, cost optimization, and upgrade strategies, ensuring clusters are built for production reliability and performance.

What it does

Assists in planning and provisioning new AKS clusters based on production requirements.
Provides guidance on choosing between AKS Automatic and Standard SKUs.
Configures networking, including pod IP models, ingress, egress, and network policies.
Implements security best practices like Microsoft Entra ID integration and secret management.
Sets up observability using Managed Prometheus, Container Insights, and Grafana.
Coordinates cost-optimization workflows including autoscaling, spot nodes, and pod rightsizing.

When to use it

When you need to create a new AKS cluster from scratch.
When designing the network architecture for a production-grade Kubernetes environment.
When you need to evaluate and implement security or observability standards for AKS.
When optimizing an existing cluster for cost, performance, or reliability.
When determining the appropriate upgrade and patching strategy for your infrastructure.

Advantages

Ensures critical Day-0 architectural decisions are made correctly to avoid future rework.
Provides a structured, authoritative approach to complex AKS configurations.
Integrates specialized workflows for cost management and resource rightsizing.
Promotes the use of modern, high-performance defaults like Azure CNI Overlay and Cilium.
Reduces operational risk by enforcing security and reliability best practices.

Usage examples

“I need to set up a new production AKS cluster in the East US region.”: The agent will initiate a consultation to gather requirements for networking, node sizing, and security, then provide a configuration plan based on the AKS Automatic SKU.
“How can I reduce the costs of my existing AKS cluster?”: The agent will perform a cost review, evaluating the use of spot node pools, cluster autoscaler tuning, and pod rightsizing recommendations.
“What is the best way to handle egress traffic for my AKS pods?”: The agent will explain options like Static Egress Gateway or UDR with Azure Firewall, helping you choose the best fit for your security and routing needs.
“Should I use Azure CNI Overlay or VNet-routable CNI?”: The agent will compare the two models based on your scale and connectivity requirements, recommending Azure CNI Overlay as the default for most modern workloads.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/microsoft/azure-kubernetes/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip azure-kubernetes.zip -d .agents/skills

Documentation by Microsoft

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 (baseline AKS troubleshooting), azure-validate (readiness checks), azure-kubernetes-automatic-readiness (migrate existing cluster to AKS Automatic), optional `aks-skills` operations add-on (focused incident, advanced cost-efficiency, exact-signature, packet-capture, and GPU Day-2 workflows)

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.

Deeper operational task? Keep Day-0 planning and basic operations in this base skill. Load optional-aks-operations.md only when a focused optional AKS operational skill could improve the current task.

Rules

Start with the user's requirements for provisioning compute, networking, security, and other settings.
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.
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.
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 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)
Node Auto Provisioning (NAP) is enabled per cluster and can reduce cost when dynamic capacity fits workload demand; savings are not guaranteed. Enable NAP for new clusters. For existing clusters, use optional AKS operations to invoke aks-cost-optimization when available for NAP readiness. Otherwise, continue with base NAP readiness.
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

Focused AKS Cost Workflows

For a focused request, 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
Advanced AKS Cost Efficiency	NAP readiness, node-pool bin packing, blocked scale-down, Kubernetes storage cost	optional AKS operations

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.

Comprehensive AKS Cost Review

When the user requests an overall AKS cost assessment rather than one focused workflow, this skill owns triage and coordinates one unified review:

Confirm the target subscription, resource group, and AKS cluster. If cost-analysis is available, collect one billed-cost baseline for that scope and reuse it throughout the review.
Evaluate the applicable rightsizing, VPA, Cluster Autoscaler, and Spot workflows.
Invoke aks-cost-optimization when available for NAP readiness, node-pool bin packing, node-scaling bottlenecks, or Kubernetes-to-Azure storage optimization.
Check for stable non-Spot demand. If present, invoke cost-optimization when available for commitment analysis. If the capability or evidence is unavailable, report commitment analysis as a gap. Do not recommend a purchase from this review alone.

Investigate applicable levers and return one ranked report. Rank by comparable estimated cost impact when available; keep unknown monetary impact unknown rather than zero. Do not present one narrow analysis as the complete review. Mark unavailable capabilities or evidence as gaps.

Rank	Lever	Evidence	Estimated cost impact and basis	Risk	Approval needed	Confidence

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

Files

ATTRIBUTION.mdAdded by AutoGineer980 B
LICENSELicence file added by AutoGineer1.1 KiB
SKILL.md12.8 KiB
references/azure-aks-autoscaler.md4.0 KiB
references/azure-aks-nap-readiness.md2.5 KiB
references/azure-aks-rightsizing.md4.3 KiB
references/azure-aks-spot.md4.6 KiB
references/azure-aks-vpa.md1.4 KiB
references/cli-reference.md1.2 KiB
references/optional-aks-operations.md3.0 KiB

references/azure-aks-spot.md

AKS Spot Node Pools

Recommend and create Spot VM node pools for batch, dev/test, or fault-tolerant workloads (60-90% cost reduction vs regular nodes).

Check Existing Node Pools

az aks nodepool list \
  --cluster-name "<CLUSTER_NAME>" --resource-group "<RESOURCE_GROUP>" \
  --query "[].{name:name, vmSize:vmSize, priority:scaleSetPriority, count:count, mode:mode}" \
  -o table

Identify Spot-Suitable Workloads

Before creating a Spot pool, identify which workloads can tolerate interruptions:

# List deployments without PodDisruptionBudgets (single-replica or no PDB = higher eviction risk)
kubectl get deployments --all-namespaces -o json | \
  jq -r '.items[] | select(.spec.replicas == 1) | "\(.metadata.namespace)/\(.metadata.name)"'

# Check which pods already have spot tolerations
kubectl get pods --all-namespaces -o json | \
  jq -r '.items[] | select(.spec.tolerations[]?.key == "kubernetes.azure.com/scalesetpriority") | "\(.metadata.namespace)/\(.metadata.name)"'

Use the suitability table below to decide which workloads to migrate.

Mixed Node Pool Pattern (Spot + Regular)

For workloads that need resilience but want cost savings, use a mixed approach:

# Keep existing regular node pool as fallback (min 1-2 nodes)
az aks nodepool update \
  --cluster-name "<CLUSTER_NAME>" --resource-group "<RESOURCE_GROUP>" \
  --name "<REGULAR_POOL>" \
  --enable-cluster-autoscaler --min-count 1 --max-count 3

# Add Spot pool for the majority of workload capacity
# -1 means pay up to on-demand price (no cap); set e.g. 0.05 to cap hourly spend
az aks nodepool add \
  --cluster-name "<CLUSTER_NAME>" --resource-group "<RESOURCE_GROUP>" \
  --name "<SPOT_POOL_NAME>" \
  --priority Spot --eviction-policy Delete --spot-max-price -1 \
  --node-vm-size "<VM_SIZE>" \
  --node-count 3 --min-count 0 --max-count 10 \
  --enable-cluster-autoscaler \
  --node-taints "kubernetes.azure.com/scalesetpriority=spot:NoSchedule" \
  --labels "kubernetes.azure.com/scalesetpriority=spot"

The toleration below makes Spot nodes eligible, while preferred affinity biases scheduling toward Spot when it is available. Because the affinity is preferred rather than required, compatible regular nodes remain eligible when Spot capacity is unavailable. This does not promise failover or capacity: the regular pool must have compatible labels, resources, taints, and available capacity. Pods pinned to Spot with a nodeSelector or required affinity remain pending when Spot capacity is unavailable.

Workload Toleration and Preference (add to Deployment YAML)

tolerations:
- key: "kubernetes.azure.com/scalesetpriority"
  operator: "Equal"
  value: "spot"
  effect: "NoSchedule"
affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      preference:
        matchExpressions:
        - key: "kubernetes.azure.com/scalesetpriority"
          operator: In
          values:
          - "spot"

Suitability

Workload	Spot-Suitable?
Batch / data processing	Yes
Dev / test environments	Yes
Stateless web/API (replicas >= 2)	Yes (with care)
Jobs with checkpointing	Yes
Stateful workloads (databases)	No
Single-replica critical services	No

Risk: Low for batch/dev. High for production stateful workloads. Spot VMs evict with 30-second notice. Eviction policy Delete is recommended for AKS.

Handling Eviction Gracefully

Configure workloads to handle the 30-second eviction notice:

# Add to Deployment spec — terminationGracePeriodSeconds should be < 30s for Spot
spec:
  template:
    spec:
      terminationGracePeriodSeconds: 25
      containers:
      - name: <CONTAINER_NAME>
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 5"]  # Drain in-flight requests

A PodDisruptionBudget does not prevent Azure Spot node reclamation. PDBs constrain voluntary disruptions performed through the Kubernetes Eviction API, such as drains, upgrades, and cluster-autoscaler scale-down. Azure can reclaim or delete the underlying Spot VM involuntarily, reducing availability below the budget. See AKS PDB guidance and Spot node pool limitations.
Use multiple replicas distributed across nodes or other failure domains, and retain enough compatible regular-pool capacity for the workload's availability requirements. Preferred Spot affinity permits that fallback but cannot guarantee scheduling capacity.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server, Needs Node.js

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

Microsoft

Publisher

Microsoft (Official)

Source

microsoft/skills · .github/plugins/azure-skills/skills/azure-kubernetes · commit 0696600

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from .github/plugins/azure-skills/LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-08

Also distributed in

microsoft/azure-skills

AutoGineer is not affiliated with or endorsed by Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download azure-kubernetes.zip