What problem does it solve? Operating Karpenter across two clouds means juggling a shared core API (NodePool/NodeClaim) with provider-specific NodeClasses, identity models, and disruption behaviors — and misconfigurations silently stall pod scheduling or delete nodes. This Skill provides the operating doctrine, CRD reference, and troubleshooting trees for Karpenter on both Amazon EKS and Azure AKS so you can provision nodes from pod intent without trial-and-error. ## Core Features & Use Cases - Dual-cloud coverage: Shared core API guidance plus AWS specifics (EC2NodeClass, Pod Identity/IRSA, SQS interruption queue, IMDSv2) and Azure specifics (AKSNodeClass, Node Auto Provisioning, Workload Identity, NAP enable/disable procedures). - Disruption engine mastery: Consolidation policies, drift, expiration, interruption handling, and disruption budgets, with the critical caveats (budgets don't gate Expiration/Interruption; never delete karpenter.azure.com CRDs during migration). - Read-only triage scripts: Three kubectl-based scripts (karpenter-health.sh, disruption-blockers.sh, nodepool-capacity.sh) that diagnose provisioning failures, disruption blockers, and capacity saturation without mutating the cluster. - Use Case: Your pods are stuck Pending with "no instance type met the scheduling requirements" on an AKS cluster with NAP enabled — use the triage map and Phase F trees to identify whether the cause is SKU sizing, zone mismatch, NodePool limits, or a missing CNI Overlay + Cilium configuration. ## Quick Start Ask the AI to diagnose why Karpenter is not provisioning nodes for your pending pods on your EKS or AKS cluster.