Kubernetes 1.35 发布后 Pod 安全上下文怎么核对：升级前后的兼容边界

Kubernetes 1.35 里，细粒度 supplemental groups 控制已经进入 GA，大家升级时最容易漏查的不是 API 字段本身，而是镜像里隐藏的组信息、CRI 运行时版本和节点是否支持严格模式。把这些条件一起核对，才能判断一个 Pod 是真的配置正确，还是暂时没触发兼容问题。

Kubernetes 1.35 这次变化到底影响什么

容器启动后，进程的 UID、主 GID 和 supplemental groups 共同决定它能否访问挂载卷。旧版本默认逻辑会自动合并容器镜像内置的组信息和 Pod 声明的配置，应用跑起来看似一切正常，但权限来源并没有全部写在工作负载清单里。

supplementalGroupsPolicy: Strict 的目标是让附加组只来自 Pod 的安全上下文等显式配置。Kubernetes 官方说明中，v1.35 已将该能力提升为 GA；对从更早版本升级的集群，尤其要留意从 beta 阶段开始出现的行为变化。

先查三层兼容性，再改 Pod 清单

整个核对流程的先后顺序很关键，控制面能正常识别配置字段，不代表每个节点和容器运行时都会按预期执行逻辑。建议把检查拆成三层递进：

控制面与 kubelet 版本

先确认升级目标和节点版本处在集群支持的偏差范围内：

kubectl version
kubectl get nodes -o wide
kubectl get nodes -o custom-columns=NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion,CRI:.status.nodeInfo.containerRuntimeVersion

如果节点还在跑老版本的 kubelet 或 CRI 组件，别直接把全局工作负载切到 Strict 模式。Kubernetes 官方 GA 说明里列了常见运行时的最低支持版本线：containerd 需要 v2.0 或更高版本，CRI-O 需要 v1.31 或更高版本。

节点能力字段

逐个节点检查能力字段。官方示例使用的是 .status.features.supplementalGroupsPolicy，它和其他新版本的节点声明字段不是一回事：

kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.features.supplementalGroupsPolicy}{"\n"}{end}'

如果输出混杂空值、false 和 true，先按节点池分批验证；不要把不支持 Strict 的节点和已验证节点混在同一个升级结论里。

Pod 是否显式声明了组

核对配置的时候要查 Deployment、StatefulSet 和 Job 的 Pod 模板，不要只看当前已经在运行的 Pod 实例：

kubectl -n orders get deploy checkout -o jsonpath='{.spec.template.spec.securityContext}\n'
kubectl -n orders get deploy checkout -o jsonpath='{.spec.template.spec.containers[*].securityContext}\n'

应用需要访问某个卷组时，把 runAsUser、runAsGroup 和 supplementalGroups 按实际需求写进清单。这里别急着复制一组看似安全的数字，先从镜像构建文件和挂载卷的属主属组确认它们的来源。

用一个最小 Pod 验证 Merge 与 Strict 的差异

可以先在单独的测试命名空间跑一个不带业务数据的测试 Pod，分别配置新旧两种策略，再进容器内部查看进程身份信息。验证的核心不用卡某个固定 GID，只要确认切换策略之后，附加组列表只剩清单里明明白白声明过的值就可以。

apiVersion: v1
kind: Pod
metadata:
  name: groups-policy-check
spec:
  securityContext:
    runAsUser: 10001
    runAsGroup: 10001
    supplementalGroups: [20001]
    supplementalGroupsPolicy: Strict
  containers:
    - name: check
      image: registry.k8s.io/e2e-test-images/agnhost:2.45
      command: ["sh", "-c", "id && sleep 3600"]

kubectl apply -f groups-policy-check.yaml
kubectl get pod groups-policy-check -o wide
kubectl exec groups-policy-check -- id

若创建阶段直接被拒绝，先看事件和节点条件：

kubectl describe pod groups-policy-check
kubectl get pod groups-policy-check -o jsonpath='{.status.conditions}'

创建失败不一定是清单的语法写错了，也有可能是Pod调度到了不支持这个能力的节点上。把Pod固定到已经验证过的节点池重新测试一次，才能分清是调度层面的问题还是运行时本身的兼容问题。

从旧行为迁移到 Strict 的落地顺序

1. 先复制生产工作负载到隔离命名空间，收集容器内 id 输出和卷访问结果。
2. 对节点按运行时版本分组，只在支持能力字段为 true 的池子里验证。
3. 为需要卷访问的工作负载补齐显式的 UID、GID 和 supplemental groups。
4. 先部署一个小流量副本，核对挂载卷读写、探针、日志和 sidecar 行为。
5. 确认没有依赖镜像内隐藏组信息后，再逐个工作负载切换并保留旧清单。

如果升级窗口内必须保留旧行为，可以暂时使用 Merge，但要把它当作兼容过渡，而不是最终的权限设计。尤其是多租户节点，隐藏组信息会让排查“谁能读这个卷”变得困难。

三个容易误判的结果

字段能提交，就代表运行时支持

不成立。API 版本和节点执行能力是两件事，必须检查节点状态以及容器运行时版本。

测试 Pod 能启动，就代表业务一定兼容

也不成立。业务镜像可能在启动脚本、文件权限或 sidecar 中依赖额外组，最小 Pod 只能验证基础链路，不能替代业务回归。

把策略改回 Merge 就算回滚完成

还要恢复工作负载清单和节点池调度约束，并核对卷访问与审计记录。否则表面恢复了，实际仍可能有一部分 Pod 使用了新策略。

相关问题

supplementalGroupsPolicy 和 Pod Security Standards 是一回事吗？

不是。前者控制容器附加组的来源，后者是对 Pod 安全属性的准入标准；两者可以同时使用，但检查维度不同。

为什么要检查 containerd 或 CRI-O 版本？

策略最终要由 kubelet 和容器运行时共同落实。运行时不支持时，控制面接受配置也不能保证容器得到预期身份。

生产环境应该直接使用 Strict 吗？

先做分池验证。只有当镜像和工作负载已经显式声明所需 UID/GID，并通过卷访问回归后，才适合逐步切换。

把升级结论写成可复查的清单

一条合格的 Kubernetes 1.35 升级记录，至少应包含控制面与 kubelet 版本、CRI 版本、每个节点的能力字段、工作负载安全上下文、测试 Pod 的 id 输出和卷访问结果。这样出现权限回归时，团队能快速判断是镜像、节点池还是策略切换导致的，而不是靠“看起来能启动”下结论。