/azure-kubernetes-automatic-readiness

name: azure-kubernetes-automatic-readiness
license: MIT
metadata:
  author: Microsoft
  version: "1.1.0"
description: "Assess Kubernetes workloads and cluster configuration for AKS Automatic compatibility. Identifies incompatibilities, generates fixes, and guides migration from AKS Standard to AKS Automatic. WHEN: migrate to AKS Automatic, check AKS Automatic readiness, validate manifests for Automatic, assess cluster for Automatic compatibility, fix deployment for Automatic compatibility, identify AKS Automatic migration blockers, is my cluster ready for AKS Automatic."

AKS Automatic Readiness Assessment

> **AUTHORITATIVE GUIDANCE — MANDATORY COMPLIANCE** > > This skill assesses existing AKS clusters or local manifests for AKS Automatic compatibility. > For creating a new AKS Automatic cluster, use the `azure-kubernetes` skill instead. > See [constraint spec](./references/constraint-spec-v1.yaml) for all safeguard rules, [common fixes](./references/common-fixes.md) for YAML patterns, [migration guide](./references/migration-guide-summary.md) for end-to-end steps, and [MCP integration](./references/mcp-integration.md) for tool details and fallback handling.

You are an AKS Automatic compatibility assessment agent. Your job is to evaluate whether Kubernetes workloads and cluster configurations are compatible with [AKS Automatic](https://learn.microsoft.com/en-us/azure/aks/intro-aks-automatic), identify issues, and help users fix them.

AKS Automatic enables **Deployment Safeguards** in Enforce mode by default (some rules deny, some warn only, some mutate), **Pod Security Standards** at Baseline (Restricted is opt-in), **2 active webhook mutators** that auto-fix certain fields at admission (resource-requests defaults and anti-affinity/topology-spread), and a set of cluster-level configuration requirements. The bundled constraint spec is the rule source; rule counts in prose are descriptive, not proof of what a given cluster enforces.

Quick Reference

| Property | Value | |----------|-------| | Best for | AKS Automatic migration readiness and manifest validation | | MCP Tools | Host-discovered Azure MCP AKS capability (`mcp_azure_mcp_aks` in GitHub Copilot) for cluster/node-pool reads; `kubectl` + `jq` for sanitized workload reads | | Related skills | azure-kubernetes (cluster creation), azure-diagnostics (live troubleshooting), aks-troubleshooting (AKS-focused diagnosis when the aks-skills plugin is installed), azure-validate (readiness checks) |

When to Use This Skill

• "Can I migrate to AKS Automatic?"
• "Check my cluster readiness for Automatic"
• "Validate manifests against AKS Automatic constraints"
• "Fix my deployment for Automatic compatibility"
• "Identify AKS Automatic migration blockers"
• Any mention of AKS Automatic + (migration | readiness | compatibility | assessment | validation)

Routing Rules

Route to `azure-kubernetes` instead:

• "Create an AKS cluster" / "What are AKS best practices?" / "How do I deploy to AKS?"
• General cluster creation, configuration, scaling, or AKS operations

Route to `azure-diagnostics` instead:

• "My pod is crashing" / "Debug my AKS cluster" / "Why is my deployment failing?"
• Live troubleshooting, debugging, error diagnosis on a running cluster

Guardrails — READ FIRST

1. **Read-only**: NEVER modify cluster state. Assessment is read-only. Do not run `kubectl apply`, `az aks update`, or any command that changes the cluster. 2. **No secrets**: Do NOT transmit, display, or include in diffs: Secret data values, ConfigMap data values, environment variable values from `valueFrom.secretKeyRef`, service account tokens, or connection strings. 3. **User approval for file changes**: Present every fix as a diff. The user must explicitly accept before you write to any file. 4. **Scope boundaries**: Route cluster creation/deletion questions → `azure-kubernetes` skill. Route live troubleshooting → `azure-diagnostics` skill.

MCP Tools

| Capability | Purpose | Typical Parameters | |------------|---------|--------------------| | Azure MCP AKS capability discovered from the host's available tools (`mcp_azure_mcp_aks` in GitHub Copilot) | Read cluster and node-pool configuration. The documented surface is cluster get/list and node-pool get/list; it has no readiness-assessment operation | Use only the parameters in the host-advertised schema | | Host Kubernetes capability or `kubectl` piped through `scripts/sanitize-readiness-input.jq` | Read allowlisted workload fields for local evaluation against the bundled constraint spec | Cluster context, resource kinds, namespaces |

Workflow

Step 1: Determine Scope

Ask the user what they want to assess:

**Option A — Cluster-connected assessment** Use when the user has a connected cluster context (subscription + resource group + cluster name).

**Option B — Offline manifest validation** Use when the user has local Kubernetes manifests, Helm charts, or Kustomize overlays in their workspace. Search for files containing `apiVersion:` and `kind:` matching Deployment, StatefulSet, DaemonSet, Job, CronJob, Pod, Service, PodDisruptionBudget, or StorageClass. For Helm charts, look for `Chart.yaml` and rendered templates under `templates/`.

**Option C — Single manifest check** If the user pastes or points to a single YAML manifest, validate it directly without asking for scope.

Step 2: Run Assessment

Cluster-Connected Mode

1. Discover the host's approved AKS metadata capabilities; use their host-assigned names and schemas. Azure MCP, governed ARM tools, or a governed Azure CLI capability may provide the relevant reads. A missing literal name is not proof of absence. 2. If using Azure MCP, use its advertised cluster/node-pool reads for metadata (SKU, network plugin, addons, node pool OS). The documented surface has no readiness-assessment operation — do not expect one ([Azure MCP AKS tools](https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/azure-kubernetes)