lukasniessen/kubernetes-skill

kubernetes-skill

Prevent Kubernetes hallucinations by diagnosing and fixing failure modes: insecure workload defaults, resource starvation, network exposure, privilege sprawl, fragile rollouts, and API drift.

소스 보기

사용 방법

  1. 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
  2. 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
  3. 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/lukasniessen/kubernetes-skill --skill kubernetes-skill

시작 전 확인

  • 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
  • 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서

원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.

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)

관련 작업