kubernetes-skill

KubeShark：Kubernetes の障害モードに対処するワークフロー

このワークフローを上から順に実行してください。

1) 実行コンテキストを記録する

マニフェストを作成する前に、以下を記録してください。

• クラスターバージョン（例：1.30、1.31）とディストリビューション（EKS、GKE、AKS、k3s、vanilla）
• 対象の名前空間と環境の重要度（dev/staging/prod）
• ワークロードの種類（Deployment、StatefulSet、Job、CronJob、DaemonSet）
• デプロイ方法（raw YAML、Helm、Kustomize、オペレーター管理）
• ポリシーの適用状況（Pod Security Admission のレベル、Kyverno、OPA/Gatekeeper）
• クラウドプロバイダーと CNI（ネットワーク、ストレージクラス、ロードバランサーに影響します）
• プラットフォームのコントローラー／アドオン（GitOps、オブザーバビリティ、Ingress、サービスメッシュ、自動スケーリング）

不明な場合は、前提を明記してください。

2) 想定される障害モードを診断する

ユーザーの意図とリスクに基づき、1 つ以上選択してください。

• 安全性に欠けるワークロードのデフォルト設定：セキュリティコンテキストの欠落、PSS 違反、ホストへのアクセス
• リソース不足：requests/limits の欠落、PDB がない、スケジューリングの混乱
• ネットワークの露出：フラットネットワーク、ポリシーの欠落、誤った Service タイプ、DNS の問題
• 権限の拡大：過度に許容的な RBAC、漏えいしたシークレット、過剰な ServiceAccount 権限
• 脆弱なロールアウト：プローブの設定ミス、変更可能なタグ、安全でない更新戦略
• API の乖離：誤った apiVersion、非推奨 API、スキーマ違反、ツール固有のエラー

3) 関連する参照ファイルのみを読み込む

主要な障害モードの参照ファイル：

• 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

補足の参照ファイル（必要な場合のみ）：

• 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

条件付き参照ファイルの取得（CRR）：シグナルを検出した場合のみ読み込みます。

• EKS、AWS、IRSA、EKS Pod Identity、AWS Load Balancer Controller、EBS/EFS CSI、Karpenter の場合は references/conditional/eks-patterns.md
• GKE、Autopilot、Workload Identity Federation for GKE、Dataplane V2、GCE Ingress、Config Sync の場合は references/conditional/gke-patterns.md
• AKS、Microsoft Entra Workload ID、Azure CNI、AGIC、Azure Disk/File/Blob CSI の場合は references/conditional/aks-patterns.md
• OpenShift、OKD、ROSA、ARO、Routes、SCCs、OLM、oc の場合は references/conditional/openshift-patterns.md
• Argo CD、ApplicationSet、Flux、GitOps の調整、同期ウェーブの場合は references/conditional/gitops-controllers.md
• Prometheus Operator、ServiceMonitor、PodMonitor、OpenTelemetry、Loki、Grafana の場合は references/conditional/observability-stacks.md

タスクが複数の検出済みプラットフォーム／ツールにまたがらない限り、複数の CRR ファイルを読み込まないでください。

4) 明示的なリスク制御を含む修正方針を提示する

各修正について、以下を含めてください。

• その修正が障害モードに対処する理由
• デプロイ時または実行時に、なお発生しうる問題
• ガードレール（検証コマンド、ポリシーチェック、ロールバック手順）

5) 実装成果物を生成する

該当する場合、以下を出力してください。

• Kubernetes マニフェスト（セキュリティコンテキスト、リソース制限、ラベルを含む YAML）
• Helm の values／テンプレート、または Kustomize オーバーレイ
• NetworkPolicies、RBAC リソース、PodDisruptionBudgets
• ポリシールール（Kyverno/OPA）とアドミッション制御

6) 完了前に検証する

デプロイ方法とリスクレベルに応じた検証手順を必ず提示してください。

• kubectl apply --dry-run=server または kubectl diff
• 対象クラスターのバージョンに対するスキーマ検証には kubeconform
• リソース間の整合性チェック（ラベル／セレクター／ポートの整合）
• ポリシースキャン（PSS プロファイルの確認、Kyverno／OPA による監査） レビュー済みの差分と承認なしに、本番環境へ直接適用することは決して推奨しないでください。

7) 出力の要件

以下を返してください。

• 前提条件とクラスターの最低バージョン
• 選択した障害モード
• 選択した修正方法とトレードオフ
• 検証／テスト計画
• ロールバック／復旧に関する注意事項（ロールアウトの取り消し、リビジョン履歴、データの安全性）