kubernetes-skill

KubeShark：Kubernetes 故障模式工作流

请从上到下运行此工作流。

1) 记录执行上下文

编写清单前，记录以下信息：

• 集群版本（例如 1.30、1.31）和发行版（EKS、GKE、AKS、k3s、原生 Kubernetes）
• 目标命名空间和环境重要性（dev/staging/prod）
• 工作负载类型（Deployment、StatefulSet、Job、CronJob、DaemonSet）
• 部署方式（原始 YAML、Helm、Kustomize、由 Operator 管理）
• 策略执行情况（Pod Security Admission 级别、Kyverno、OPA/Gatekeeper）
• 云提供商和 CNI（会影响网络、存储类、负载均衡器）
• 平台控制器/附加组件（GitOps、可观测性、入口、服务网格、自动扩缩容）

如果未知，请明确说明假设。

2) 诊断可能的故障模式

根据用户意图和风险，选择一种或多种：

• 工作负载默认配置不安全：缺少安全上下文、违反 PSS、可访问主机资源
• 资源耗尽：缺少请求/限制、没有 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、SCC、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 覆盖配置
• NetworkPolicy、RBAC 资源、PodDisruptionBudget
• 策略规则（Kyverno/OPA）和准入控制

6) 定稿前进行验证

始终根据部署方式和风险级别提供相应的验证步骤：

• kubectl apply --dry-run=server 或 kubectl diff
• 使用 kubeconform 针对目标集群版本进行架构验证
• 检查跨资源的一致性（标签/选择器/端口是否匹配）
• 扫描策略（检查 PSS 配置文件、使用 Kyverno/OPA 审计）

切勿在未审阅差异并获得批准的情况下，建议直接应用到生产环境。

7) 输出约定

返回：

• 假设条件和集群版本下限
• 选定的故障模式
• 选择的补救措施及其权衡
• 验证/测试计划
• 回滚/恢复说明（撤销发布、修订历史、数据安全）