kubernetes-skill

name kubernetes-skill description Prevent Kubernetes hallucinations by diagnosing and fixing failure modes: insecure workload defaults, resource starvation, network exposure, privilege sprawl, fragile rollouts, and API drift. Use when generating, reviewing, refactoring, or migrating manifests, Helm charts, Kustomize overlays, cluster policies, and platform-specific Kubernetes work for EKS, GKE, AKS, OpenShift, GitOps controllers, or observability stacks. KubeShark: Failure-Mode Workflow for Kubernetes Run this workflow top to bottom. 1) Capture execution context Record before writing manifests: cluster version (e.g. 1.30, 1.31) and distribution (EKS, GKE, AKS, k3s, vanilla) target namespace and environment criticality (dev/staging/prod) workload type (Deployment, StatefulSet, Job, CronJob, DaemonSet) deployment method (raw YAML, Helm, Kustomize, operator-managed) policy enforcement (Pod Security Admission level, Kyverno, OPA/Gatekeeper) cloud provider and CNI (affects networking, storage classes, load balancers) platform controllers/add-ons (GitOps, observability, ingress, service mesh, autoscaling) If unknown, state assumptions explicitly. 2) Diagnose likely failure mode(s) Select one or more based on user intent and risk: insecure workload defaults: missing security contexts, PSS violations, host access resource starvation: missing requests/limits, no PDB, scheduling chaos network exposure: flat networking, missing policies, wrong Service types, DNS issues privilege sprawl: overly permissive RBAC, leaked secrets, excess ServiceAccount rights fragile rollouts: misconfigured probes, mutable tags, unsafe update strategies API drift: wrong apiVersion, deprecated APIs, schema violations, tool-specific errors 3) Load only the relevant reference file(s) Primary failure-mode references: references/insecure-workload-defaults.md references/resource-starvation.md references/network-exposure.md references/privilege-sprawl.md references/fragile-rollouts.md references/api-drift.md Supplemental references (only when needed): references/deployment-patterns.md references/stateful-patterns.md references/job-patterns.md references/daemonset-operator-patterns.md references/security-hardening.md references/observability.md references/multi-tenancy.md references/storage-and-state.md references/helm-patterns.md references/kustomize-patterns.md references/validation-and-policy.md references/examples-good.md references/examples-bad.md references/do-dont-patterns.md Conditional Reference Retrieval (CRR) references (load only when the signal is detected): references/conditional/eks-patterns.md for EKS, AWS, IRSA, EKS Pod Identity, AWS Load Balancer Controller, EBS/EFS CSI, Karpenter references/conditional/gke-patterns.md for GKE, Autopilot, Workload Identity Federation for GKE, Dataplane V2, GCE Ingress, Config Sync references/conditional/aks-patterns.md for AKS, Microsoft Entra Workload ID, Azure CNI, AGIC, Azure Disk/File/Blob CSI references/conditional/openshift-patterns.md for OpenShift, OKD, ROSA, ARO, Routes, SCCs, OLM, oc references/conditional/gitops-controllers.md for Argo CD, ApplicationSet, Flux, GitOps reconciliation, sync waves references/conditional/observability-stacks.md for Prometheus Operator, ServiceMonitor, PodMonitor, OpenTelemetry, Loki, Grafana Do not load multiple CRR files unless the task spans multiple detected platforms/tools. 4) Propose fix path with explicit risk controls For each fix, include: why this addresses the failure mode what could still go wrong at deploy time or runtime guardrails (validation commands, policy checks, rollback path) 5) Generate implementation artifacts When applicable, output: Kubernetes manifests (YAML with security contexts, resource limits, labels) Helm values/templates or Kustomize overlays NetworkPolicies, RBAC resources, PodDisruptionBudgets Policy rules (Kyverno/OPA) and admission controls 6) Validate before finalize Always provide validation steps tailored to deployment method and risk tier: kubectl apply --dry-run=server or kubectl diff kubeconform for schema validation against target cluster version cross-resource consistency check (label/selector/port alignment) policy scan (PSS profile check, Kyverno/OPA audit) Never recommend direct production apply without reviewed diff and approval. 7) Output contract Return: assumptions and cluster version floor selected failure mode(s) chosen remediation and tradeoffs validation/test plan rollback/recovery notes (rollout undo, revision history, data safety)