kubernetes

Kubernetes & Helm：生产基础设施

创建、审核和设计 Kubernetes 基础设施——从原始清单到 Helm chart，再到多集群策略。目标是打造可用于生产、强化安全性、兼顾成本且团队能够维护的基础设施。

目标版本（2026 年 10 月）：支持的 Kubernetes 次要版本为 1.35-1.37（1.37.1 / 1.36.5 / 1.35.9）。根据版本历史，Kubernetes 维护最近的三个次要版本（1.37、1.36、1.35）；1.34 于 2026 年 8 月 27 日进入维护模式，并将于 2026 年 10 月 27 日终止支持。上游 Kubernetes 没有 LTS。托管平台的厂商延长支持（AKS/EKS）会延长旧次要版本的支持时间——应将其归因于平台，而非上游。Helm 4.3.0 和 Helm 3.22.0 是当前并行发布的版本线。将 Helm 3 用于新部署前，请确认其支持状态。配对发布版本前，请查看 Helm 兼容性矩阵：Helm 4.3.x 和 Helm 3.22.x 均说明支持 Kubernetes 1.34-1.37，涵盖上述受支持的次要版本。 本技能根据上下文涵盖四个领域：

• 清单 - 用于 Deployment、Service、Gateway API 路由、ConfigMaps、Secrets、PVC 的原始 YAML
• Helm - Helm 4 chart 脚手架、OCI 注册表、模板、多环境 values
• 架构 - 集群拓扑、GitOps、安全层、可观测性、成本、灾难恢复
• 合规 - PCI-DSS 4.0 控制、CDE 隔离、审计日志、供应链

适用场景

• 创建或审核 Kubernetes 清单（Deployment、Service、StatefulSet、Job、HTTPRoute 等）
• 搭建新的 Helm chart 脚手架或改进现有 chart
• 设计集群拓扑、GitOps 策略或多租户架构
• 实施安全上下文、网络策略、RBAC、准入控制
• 设置多环境部署（dev/staging/prod）
• 审核基础设施是否满足生产或合规要求
• 规划可观测性、成本优化或灾难恢复
• 针对金融科技/支付 K8s 工作负载实现 PCI-DSS 4.0 合规

不适用场景

• 配置 CI/CD 流水线（使用 ci-cd）
• Docker/容器镜像优化（使用 docker）
• 审核应用代码安全性（使用 security-audit）
• 通过 IaC 配置集群本身（使用 terraform）
• 配置运行在 K8s 上的数据库引擎（使用 databases）
• 广泛的只读集群健康检查、状态报告和维护后诊断（使用 kubernetes-health）
• 仪表化、采集流水线、告警和 SLO 设计（使用 observability）——本技能负责 Kubernetes 对象配置

AI 自检

此技能在 AI Agent 中运行。AI 工具总是会犯同样的 K8s 安全错误。返回任何生成的清单前，请对照此列表进行检查：

• 每个 Pod 和每个容器上都设置了安全上下文（而非只设置在其中一个层级）
• 设置了 runAsNonRoot: true、readOnlyRootFilesystem: true、allowPrivilegeEscalation: false、drop: ["ALL"]
• 设置了资源 requests 和 limits（如果没有明确提示，AI 几乎从不主动包含这些设置）
• 镜像标签已固定（不是 :latest，也没有省略）。生产环境优先使用 SHA256 摘要。
• 环境变量、ConfigMaps 或 Helm 值中没有硬编码的密钥
• 显式指定了命名空间（不依赖上下文默认值）
• 包含或提及了 NetworkPolicy（AI 几乎从不在生成部署配置时一并生成这些策略）
• 没有 privileged: true 或 hostNetwork: true，除非有明确要求且给出了理由
• 设置了 seccompProfile: { type: RuntimeDefault }（经常被遗漏）
• 新的外部访问使用 Gateway API HTTPRoute，而不是旧版 Ingress
• 就绪探针应为 Pod 流量所需的容器设置门控；仅当辅助 sidecar 的就绪状态必须影响流量门控时，才需要为其设置就绪探针。为工作负载添加有意义的启动探针和存活探针。
• 在执行任何 kubectl/helm/argocd 命令前，已验证 Kube 上下文
• 未经审批关卡批准，不会自动同步到生产环境
• 已检查 API 版本：清单、Helm 模板和 Gateway 资源均与目标集群版本匹配
• 已显示集群上下文：在执行变更命令前打印命名空间、上下文和 kubeconfig 身份
• 已检查 1.35+ 集群上的 kube-proxy 模式：IPVS 模式在 1.35 中已弃用，从 1.40 起默认禁用（可通过 KubeProxyIPVS 功能门控重新启用），并将在 1.43 中移除；建议新集群使用 nftables 模式，并在审查中标记 IPVS
• 已应用跨领域 Agent 卫生规范——参见 references/agent-hygiene.md

如果条件允许，请使用 kube-score score <manifest> 和 checkov（步骤 4）检查生成的清单； 如果仓库已统一使用 kube-linter，请改用它，而不是 kube-score。

性能与运维实践

• 根据测量到的工作负载行为设置 requests 和 limits；缺少 requests 会影响调度和自动扩缩容。
• 应用前使用服务器端 dry-run 和 diff；在紧密循环中避免反复渲染整个集群。
• 在大型集群中，按命名空间/标签限定 watch、日志和 kubectl get 调用范围。
• 生产环境优先使用声明式 GitOps 或经过审查的清单，而不是实时命令式变更。
• 升级或更改 operator 前，备份 CRD 和自定义资源。
• 对特权 Pod、hostPath、宽泛 RBAC 和可变镜像标签设置策略门控。

密钥交付与恢复

通过工作负载身份、命名空间/RBAC 访问权限、刷新和应用重新加载，追踪外部密钥的归属。除了检查轮换成功，也要检查租约是否过期、凭据是否已撤销；不要假设更新 Secret 就会重新加载进程。将颁发方和流水线设置纳入 terraform 和 ci-cd。进行恢复演练时，使用隔离集群或命名空间，验证应用的读写操作及其依赖项，根据 RTO/RPO 衡量恢复时间和数据丢失情况，并记录清理工作。备份作业完成本身并不能证明数据可以恢复。

工作流

复制此清单并跟踪进度：

• 步骤 1：已识别领域
• 步骤 2：已收集需求
• 步骤 3：已构建清单、chart 或设计
• 步骤 4：验证无误（如果 dry-run、lint 或评分失败，请修复并返回步骤 3）
• 步骤 5：在进行任何实时变更前，已确认 GitOps 负责人
• 已通过生产环境检查清单和 AI 自检

步骤 1：确定领域

根据请求：

• “创建部署/服务/清单” -> 清单
• “创建 Helm chart” / “用于部署的软件包” -> Helm
• “设计集群” / “我们应该如何组织” -> 架构
• “让它符合 PCI 标准” / “金融科技” -> 合规
• “审核此清单/chart” -> 应用生产检查清单 + 关键规则 + AI 自检

大多数实际任务会涉及多个领域。自下而上推进：先确保清单正确，再将其模板化，然后规划部署。

步骤 2：收集需求

编写 YAML 之前，确定：

• 工作负载类型：无状态（Deployment）还是有状态（StatefulSet），或批处理（Job/CronJob）
• 容器镜像以及固定的标签或 SHA256 摘要
• 暴露的端口（容器端口、服务端口、协议）
• 配置：环境变量、配置文件、密钥
• 存储：临时存储（emptyDir）还是持久存储（PVC），包括访问模式和容量
• 资源：CPU/内存请求和限制
• 健康状态：启动、存活和就绪探针的端点
• 访问方式：仅限内部（ClusterIP）还是外部（Gateway API HTTPRoute / LoadBalancer）
• 扩缩容：副本数、HPA 阈值、Pod 中断预算
• 合规性：是否属于 PCI-DSS 范围？是否为 CDE 工作负载？是否处于受监管环境？
• Sidecar：是否需要日志、安全或代理 Sidecar？使用原生 Sidecar（在 1.33 中已正式发布）

步骤 3：构建

按照下方相应领域的章节操作。完成前务必执行步骤 4、references/production-checklist.md 中的生产检查清单，以及 AI 自检。

步骤 4：验证

# Always verify kube context first
KUBE_CONTEXT="$(kubectl config current-context)"
printf 'Using kube context: %s\n' "$KUBE_CONTEXT"

# Manifests
kubectl --context "$KUBE_CONTEXT" apply -f <manifest> --dry-run=server  # Server-side validation
if command -v kube-score >/dev/null; then
  kube-score score <manifest>                   # Best practice scoring
else
  echo "kube-score not installed: scoring NOT run; report it as unverified"
fi
if command -v checkov >/dev/null; then
  checkov -d . --framework kubernetes
else
  echo "checkov not installed: policy scan NOT run; report it as unverified"
fi
# Fix and return to Step 3 until dry-run errors and findings this change introduced are clean; report pre-existing ones

# Helm 4
helm lint <chart>/                              # Lint chart
helm template <release> <chart>/               # Render templates locally
helm template <release> <chart>/ -f values-prod.yaml  # With env overlay
helm --kube-context "$KUBE_CONTEXT" install <release> <chart>/ --dry-run=server --debug  # Server-side dry run

步骤 5：GitOps 管理的紧急变更或扩缩容变更

更改由 ArgoCD、Flux 或其他协调器管理的线上工作负载时，请阅读 references/gitops-emergency-changes.md；除非同时更改期望状态，否则线上执行 kubectl scale、kubectl patch 或手动 apply 的更改可能会被还原。

清单

阅读 references/manifest-templates.md，了解完整且可直接复制粘贴的 YAML 模板（Deployment、Service、Gateway API HTTPRoute、ConfigMap、PVC、StatefulSet、原生 Sidecar）。

关键模式

标签：在每个资源上使用 app.kubernetes.io/* 标准标签：

• app.kubernetes.io/name - 应用名称
• app.kubernetes.io/version - 版本字符串
• app.kubernetes.io/component - 角色（前端、后端、数据库）
• app.kubernetes.io/part-of - 所属父系统

外部访问（新集群必须使用 Gateway API，而不是旧版 Ingress）：

• Gateway API HTTPRoute（GA v1.5）：面向角色、路由表达能力强，避免陷入注解的泥潭。Ingress-NGINX 已于 2026 年 3 月退役；请迁移到受维护的控制器。之后的 CVE-2026-4342 可导致配置注入和控制器代码执行；受影响分支的版本分别早于 1.13.9 / 1.14.5 / 1.15.1。这些修复并不能恢复持续支持。
• ClusterIP（默认）：仅限内部访问
• LoadBalancer：云负载均衡器，不支持 HTTP 路由
• Headless（clusterIP: None）：用于 StatefulSet Pod 发现

安全上下文（每个 Pod 都必须满足，不容妥协——包括 Pod 级别和容器级别）。完整 YAML 请参阅 manifest-templates.md 中的 Deployment 模板。关键字段：runAsNonRoot、readOnlyRootFilesystem、allowPrivilegeEscalation: false、drop: ["ALL"]、seccompProfile: RuntimeDefault。

探针类型（根据工作负载选择有意义的检查；只有在必须控制 Pod 流量时，辅助 sidecar 才需要就绪探针）：

• startupProbe：在应用就绪前阻止其他探针运行（较高的 failureThreshold，适中的 periodSeconds）
• livenessProbe：重启不健康的 Pod（设置应保守——不要因响应缓慢而重启）
• readinessProbe：从服务端点中移除 Pod（设置应积极——失败时迅速停止转发流量）

Pod 分布：区域级分布优先使用 topologySpreadConstraints，而不是 Pod 反亲和性（大规模场景下，反亲和性的复杂度为 O(n^2)）。两者结合使用：用 topologySpreadConstraints 实现跨区域分布，再用软反亲和性实现区域内跨节点分散。

原生 sidecar（在 K8s 1.33 中 GA）：将 restartPolicy: Always 用于 init 容器。它们会在主容器之前启动，与主容器一同运行，并在主容器退出后终止。可取代所有 sidecar 生命周期变通方案（preStop 钩子、shareProcessNamespace 杀进程脚本）。

Pod 原地扩缩容（在 K8s 1.35 中 GA）：无需重启即可更新运行中 Pod 的 CPU 和内存。VPA 现在可以使用 InPlaceOrRecreate 模式，在不造成中断的情况下调整资源。

配置/机密信息：非敏感数据使用 ConfigMap。机密信息使用从保险库/云 KMS 同步的 External Secrets Operator，或在加密 Git 工作流中使用 Sealed Secrets（参阅 references/sealed-secrets.md）。绝不要在任何地方提交明文机密信息。

Helm Chart

Helm 4（于 2025 年 11 月 12 日发布 4.0.0；当前版本为 4.3.0）是当前版本。选择 3.22.0 前，请确认 Helm 3 当前的支持政策。

Helm 4 的变化

• 新版本默认使用 服务器端应用（SSA）。当多个控制器修改同一资源时，冲突检测能力更强。
• 通过 OCI 摘要安装：helm install myapp oci://registry/chart@sha256:abc... ——不可变且防篡改。
• WASM 插件系统——后渲染器必须引用插件名称，而不能使用原始可执行文件（重大变更）。
• CLI 标志重命名：--atomic -> --rollback-on-failure、--force -> --force-replace。旧标志仍可用于 install 和 upgrade，但已弃用，作为别名保留（Helm 4.0 曾出现导致 helm install --atomic 失效的短暂回归问题，已在 v4.1.3 中修复）；新脚本优先使用 --rollback-on-failure。
• helm registry login 仅接受域名（例如 ghcr.io，而不是完整 URL）。
• **OCI 仓库是推荐的分发方式。**传统的 index.yaml 仓库仍可使用，但不再是默认方式。

Chart 结构

helm create <app-name>

<app-name>/
+-- Chart.yaml           # Metadata (apiVersion: v2, name, version, appVersion)
+-- values.yaml          # Default config values
+-- values.schema.json   # JSON schema for values validation
+-- charts/              # Bundled dependencies
+-- crds/                # CRDs (not templated, installed first)
+-- templates/
|   +-- NOTES.txt        # Post-install usage instructions
|   +-- _helpers.tpl     # Template helper functions
|   +-- deployment.yaml
|   +-- service.yaml
|   +-- httproute.yaml   # Gateway API (prefer over ingress.yaml)
|   +-- configmap.yaml
|   +-- hpa.yaml
|   +-- tests/
|       +-- test-connection.yaml
+-- .helmignore

Chart.yaml

必填项：apiVersion: v2、name、version（SemVer）、description、type（application|library）。

使用 ~ 锁定依赖的补丁版本范围：

dependencies:
  - name: postgresql
    version: "~12.0.0"          # matches 12.0.x
    repository: "oci://registry-1.docker.io/bitnamicharts"  # OCI preferred
    condition: postgresql.enabled

添加依赖后运行 helm dependency update。

values.yaml 设计

采用分层组织。核心部分：

• image（repository、tag/digest、pullPolicy）
• replicaCount
• service（type、port、targetPort）
• gateway（enabled、parentRefs、hostnames）——优先于 ingress
• resources（requests + limits——始终同时设置）
• autoscaling（enabled、min/maxReplicas、targetCPU）
• securityContext（runAsNonRoot、readOnlyRootFilesystem、drop ALL caps）
• nodeSelector、tolerations、affinity

多环境：创建 values-dev.yaml、values-staging.yaml、values-prod.yaml 作为覆盖配置。不要修改 values.yaml 来设置特定环境的配置。

模板模式

辅助模板（_helpers.tpl）：定义 <chart>.name、<chart>.fullname、<chart>.labels、<chart>.selectorLabels、<chart>.image。将名称截断至 63 个字符。

Go 模板常用模式：

• 条件判断：{{- if .Values.gateway.enabled }}
• 遍历：{{- range .Values.env }}
• 包含文件：{{ .Files.Get "config/app.yaml" | nindent 4 }}
• 默认值：{{ .Values.image.tag | default .Chart.AppVersion }}
• 必填项：{{ required "image.repository is required" .Values.image.repository }}
• Release 命名空间：{{ .Release.Namespace }}（不要硬编码命名空间）
• 嵌套访问：使用 {{- $var := .Values.deep.nested }} 创建别名，避免代码变得杂乱

Helm 反模式

• 在模板中硬编码值（应从 values.yaml 获取）
• 对静态字符串使用 tpl（它用于动态模板渲染）
• 对可选值使用 .Values.foo.bar.baz 链式访问，却不提供 default
• Chart 依赖未固定版本（使用 ~ 范围或精确版本）
• 没有 NOTES.txt
• 缺少 .helmignore（test/ci 文件会被打包）
• 在通过 ArgoCD 部署的模板中使用 randAlphaNum（会导致持续 OutOfSync）
• 超大型 umbrella chart（15+ 个子 Chart、200+ 项值覆盖）——改用 ArgoCD ApplicationSets
• 生产 HA 工作负载使用 replicaCount: 1（没有冗余，存在单点故障）
• 在生产 values 中设置 authentication.enabled: false 或 persistence.enabled: false（数据丢失、未授权访问）
• 在 Helm values 中存放密钥（使用 ESO/sealed-secrets/vault；Helm values 最终会以可读形式存储在集群 Secrets 中）
• Hook 资源未设置 helm.sh/hook-delete-policy（孤立的 Job 会不断累积）
• 使用带原始可执行文件的 --post-renderer（在 Helm 4 中会失效；必须使用插件名称）
• 忽略 SSA 迁移——在现有 release 上升级到 Helm 4 可能会暴露之前隐藏的冲突

ArgoCD + Helm 注意事项

• ArgoCD 只运行 helm template——不会使用 Helm 生命周期管理。不要依赖 Helm hooks 执行关键操作；应使用 ArgoCD sync waves。
• ArgoCD 不支持 test hooks。
• 使用多源 Application（ArgoCD 2.6+），将 Chart 版本与环境 values 分开。
• OCI Chart：在 ArgoCD 的 repoURL 字段中省略 oci:// 前缀。

Kustomize

Kustomize 已内置于 kubectl（kubectl apply -k），也可作为独立 CLI 使用。

覆盖层模式（base + 环境）

app/
+-- base/
|   +-- kustomization.yaml   # references resources
|   +-- deployment.yaml
|   +-- service.yaml
+-- overlays/               # dev/ staging/ prod/, each a kustomization.yaml with resources: [../../base]

每个覆盖层的 kustomization.yaml 都会设置 resources，然后添加该环境对应的 patches、images 和 configMapGenerator/secretGenerator 覆盖配置。

组件

可复用的跨领域补丁（监控、安全上下文、sidecar 注入），任何覆盖层都可以通过 components: [../../components/monitoring] 选择启用。优先使用组件，而不是在多个覆盖层中重复补丁。

secretGenerator / name-suffix-hash 陷阱

secretGenerator 和 configMapGenerator 会在资源名称后追加内容哈希后缀（例如 app-config-abc12345）。如果 Deployment 使用固定名称引用生成的资源，那么每次编辑后哈希都会变化，导致引用失效。始终使用基础名称引用生成的资源，并让 Kustomize 解析后缀；如果不需要基于哈希的滚动更新，则设置 options.disableNameSuffixHash: true。

架构

阅读 references/architecture.md，了解完整的架构决策框架。关键模式：

集群拓扑

单集群适用于：服务少于 50 个、单个团队、单个区域、非关键工作负载。

多集群适用于：多区域 HA、团队隔离、缩小故障影响范围、合规边界（PCI CDE）。

GitOps

ArgoCD适用于：重视 UI、应用套应用模式、通过单一控制平面管理多集群、对部署进行 RBAC 管理。

Flux适用于：优先采用 Git 原生方式、占用资源较少、完整的 Helm 生命周期（安装/升级/测试/回滚/卸载）、Kustomize 后渲染。

晋级流程：通过基于 PR 的晋级，从 dev -> staging -> prod。不要对 prod 启用自动同步。

网络

Gateway API（GA v1.5）是新集群的标准（参见规则 10）。

CNI：Cilium（eBPF，greenfield）或 Calico（brownfield/多操作系统/Windows）。Cilium 包含 Hubble 可观测性、L3-L7 策略，以及可选的无 sidecar 服务网格。

kube-proxy：nftables 模式是未来方向。IPVS 在 1.35 中弃用，从 1.40 起默认禁用（通过 KubeProxyIPVS 功能门重新启用），并在 1.43 中移除（https://kubernetes.io/docs/reference/networking/virtual-ips/）。

服务网格（仅在需要时添加）：

• Istio ambient（在 1.24 中 GA）：通过 ztunnel 实现无 sidecar 的 L4 mTLS，可选地通过 waypoint 代理提供 L7。
• Cilium：通过 WireGuard/IPsec 实现 mTLS，不提供网格抽象。更简单，但 L7 控制能力较弱。
• Linkerd：稳定版构建目前仅由供应商 Buoyant 提供。源代码采用 Apache 2.0 许可，但需要自行构建或付费。

安全（纵深防御）

生产环境的 8 个安全层：

1. 集群加固：CIS 基准、API server 审计日志、通过 KMS v2 加密 etcd
2. Pod 安全标准：所有应用命名空间默认采用 enforce: restricted。Restricted 仅允许添加 NET_BIND_SERVICE，因此以 root 身份启动且需要 SETUID/SETGID/CHOWN 的镜像应先重新配置或重建为非 root 运行。如果无法做到，则将其隔离在专用命名空间中，并强制采用 baseline，同时记录例外（负责人、原因、复审日期）；该命名空间中的 audit/warn 仍应保持为 restricted。其他所有位置都设置 audit: restricted 和 warn: restricted，以便在强制执行前了解可能导致哪些工作负载中断。
3. 准入控制：标准策略使用 ValidatingAdmissionPolicy（CEL，自 1.30 起内置）；变更/生成使用 Kyverno；跨平台组织使用 OPA Gatekeeper
4. 网络策略：按命名空间默认拒绝入站/出站流量；L7 策略使用 Cilium
5. RBAC：限定在命名空间范围内的角色；应用不得使用 cluster-admin；采用带 MFA 的 OIDC 身份验证
6. 供应链：使用 cosign/Sigstore 对镜像签名，达到 SLSA Level 2-3，提供 SBOM。将所有 CI 操作和工具固定到提交 SHA——Trivy 供应链遭入侵事件（2026 年 3 月，CVE-2026-33634）证明，可变标签可能被强制推送并植入恶意软件。请阅读 references/architecture.md（CI/CD 供应链加固），了解 Trivy 事件的经验、安全版本和密钥轮换窗口。
7. 密钥：优先使用 External Secrets Operator + 云 KMS；动态密钥/PKI 使用 Vault；无需外部依赖、在 Git 中加密存储时使用 Sealed Secrets（参见 references/sealed-secrets.md）；小型团队使用 SOPS
8. 运行时安全：使用 Falco 进行检测（CNCF Graduated），使用 Tetragon 进行 eBPF 强制执行（开销低于 1%）

平台感知

• K8s 1.36+ 要求 cgroup v2（FailCgroupV1 默认为 true；在 cgroup v1 上，除非设置 failCgroupV1: false，否则 kubelet 无法启动）。使用 cgroup v1 的节点（CentOS 7、RHEL 7、Ubuntu 18.04）将无法运行。
• K8s 1.36+ 要求 containerd 2.0。最后一个支持 containerd 1.x 的版本是 1.35。
• 1.34 起停止自动填充 AppArmor 注解；1.36 中将彻底移除。请使用 securityContext.appArmorProfile 字段。
• **DRA（动态资源分配）**于 1.34 正式发布，用于 GPU/FPGA/硬件调度。它将取代设备插件模式。
• 用户命名空间（hostUsers: false）自 K8s 1.33 起默认启用。它会将容器 UID 0 映射到非特权主机 UID。对 PCI 多租户场景意义重大——容器逃逸也不会获得主机 root 权限。
• Pod 级 mTLS（KEP-4317）在 1.35 中进入 Beta 阶段，必须手动启用功能门控 PodCertificates。无需服务网格即可为 Pod 提供原生 X.509 证书。未来可作为满足 Req 4 合规要求的 Istio/Cilium 替代方案。

合规性

阅读 references/compliance.md，了解 PCI-DSS 4.0 要求与 Kubernetes 控制措施的完整映射。

快速参考：K8s 上的 PCI-DSS 4.0

PCI-DSS 4.0.1 是唯一有效版本（4.0 于 2024 年 12 月 31 日退役；3.2.1 于 2024 年 3 月退役）。51 项设有未来生效日期的要求已于 2025 年 3 月 31 日起强制执行。

K8s 特定关键要求：

• Req 1：网络分段 -> 默认拒绝的 NetworkPolicies、私有 API 服务器、VPC 原生集群
• Req 3.5：数据加密 -> 通过 KMS v2 加密 etcd（不能只依赖磁盘加密——Req 3.5.1.2 禁止仅依赖磁盘级加密）
• Req 4：加密传输 -> 所有 CDE 服务之间使用 mTLS（Istio strict / Cilium mutual auth）
• Req 6.3.2：组件清单 -> 为每个镜像生成 SBOM
• Req 8.4.2：所有 CDE 访问均需 MFA -> 在所有 kubectl 访问路径上使用 OIDC + MFA
• Req 8.6.2：不得硬编码机密 -> 使用 External Secrets Operator，绝不将机密放入清单/values/环境变量中
• Req 10.4.1.1：自动审核审计日志 -> 针对敏感负载使用 Metadata、仅对经过审核的非敏感资源使用 RequestResponse 的 K8s 审计策略；将日志发送到 SIEM 并配置告警规则
• Req 11.5：FIM / 变更检测 -> 使用 Falco 进行运行时检测、使用 ArgoCD 进行漂移检测、固定镜像摘要

CDE 隔离：强烈建议使用专用集群。共享集群会使整个集群都纳入 PCI 范围，并要求使用专用节点池 + 污点、为 CDE Pod 使用 gVisor/Kata、使用独立 DNS、独立审计流以及大量 QSA 文档。大多数 QSA 不赞成使用共享集群。

PCI MPoC：MPoC 后端（用于轻触支付的证明/监控）属于完整的 PCI-DSS 范围。没有针对 K8s 的补充条款——适用标准 PCI-DSS 4.0 控制措施。

参考文件

• references/manifest-templates.md - 清单模板和可复用的工作负载模式
• references/production-checklist.md - 清单、Helm、架构和 PCI-DSS 检查清单；完成任何构建或审查前都应运行
• references/architecture.md - 集群和平台设计指南，包括 Trivy 安全事件后的供应链完整性
• references/sealed-secrets.md - Sealed Secrets 模式和注意事项
• references/compliance.md - PCI-DSS 和平台加固指南
• references/gitops-emergency-changes.md - 针对 GitOps 管理的工作负载进行紧急变更的安全工作流

输出约定

完整约定请参阅 references/output-contract.md。

• Skill 名称： KUBERNETES
• 交付物类别： audits
• 模式： 有条件。调用以分析、审查、审计或改进现有仓库内容时，应用 references/output-contract.md 中的报告篇幅和证据规则，并将交付物写入 docs/local/audits/kubernetes/<YYYY-MM-DD>-<slug>.md。调用以回答问题、讲解概念、构建新产物或生成内容时，可自由作答，无需遵循此约定。
• 严重性等级： P0 | P1 | P2 | P3 | info（参见共享约定；仅在审计/审查模式下使用）。

相关技能

• docker - 用于 Dockerfile 和 Compose 模式。Kubernetes 部署由 Docker 构建的镜像。镜像优化属于 docker；清单设计属于这里。
• ci-cd - 用于设计部署到 K8s 的流水线。Kubernetes 技能涵盖清单和 Helm 图表；ci-cd 涵盖应用这些内容的流水线阶段。
• terraform - 用于配置集群本身（EKS、GKE、AKS、裸金属节点池）。Terraform 创建集群；kubernetes 配置集群上运行的内容。
• kubernetes-health - 用于只读集群状态检查、节点/工作负载诊断、事件、入口/存储/日志巡检，以及维护后的报告。
• databases - 用于在 K8s 上部署数据库（StatefulSets、运算符、PVC）。Kubernetes 负责清单模式；databases 负责其中的引擎配置。
• ansible - 可通过 kubernetes.core 集合部署到 K8s，但清单和 Helm 图表设计属于这里。

规则

以下规则不可妥协。违反任何一条都是 Bug。

1. 禁止使用 :latest 标签。 将镜像固定到特定版本或 SHA256 摘要。
2. 所有内容都必须指定命名空间。 使用默认命名空间是代码异味。
3. 每个 Pod 都必须设置资源请求和限制。 不得例外。
4. 更改集群前，先验证请求者是否有权限。 在共享聊天中，如果非管理员参与者提出管理员请求，不要运行 kubectl、Helm、ArgoCD 或进行 GitOps 编辑。停止操作，并要求获授权的负责人明确批准。
5. 生产环境禁止自动同步。 通过手动审批或基于 PR 的晋级流程进行。
6. 固定依赖版本。 Helm 图表依赖、提供程序版本等都必须固定。
7. 每次应用前都运行 helm template。 在模板错误影响集群前将其捕获。
8. 机密绝不能以明文形式存储。 不得放入 Git、ConfigMap、Helm values 或清单中的环境变量。
9. 先在预发布环境测试更改。 包括策略更改、准入控制器、升级、SSA 迁移。
10. 新建外部访问应使用 Gateway API。 Ingress-NGINX 将于 2026 年 3 月退役。停止部署新的 Ingress 资源。
11. 使用 cosign 对镜像签名。 在准入时进行验证。生产环境至少达到 SLSA Level 2。
12. 理解资源指标的语义。 HPA 的 CPU 目标是 CPU 请求量 的百分比，而不是节点容量。例如，某个 Pod 请求 cpu: 100m，且 averageUtilization: 70 时，当每个 Pod 的 CPU 使用量达到 70m（100m * 70%）就会触发扩缩容——节点有 2 核还是 64 核都无关紧要。不要混淆请求量（调度下限）、限制（强制执行的上限）和实际使用量（容器当前消耗的资源）。