Kubernetes v1.37 Rootless Kubelet Beta 节点权限怎么核对

Kubernetes v1.37 把 KubeletInUserNamespace（也就是常说的 Rootless mode）提升到了 Beta。真正容易误判的地方是：Beta feature gate 默认开启，只说明组件具备这项能力，并不会把一台原本以 root 运行的节点自动改成 rootless。核对节点权限时，应该直接看 Node 对象的 status.nodeInfo.runningInUserNamespace，再决定是否给它打标签、加污点。

官方地址：https://kubernetes.io/

先分清 Beta 开关和 rootless 节点

官方说明里，rootless 模式是让 kubelet、CRI/OCI runtime、CNI 插件和 kube-proxy 借助 Linux user namespace 以宿主机非 root 用户运行。它和 Pod 的 user namespace 不是同一个概念：hostUsers: false 只改变 Pod 的用户命名空间，节点组件仍可能以 root 运行。

因此升级 v1.37 后，不能只看 feature gate 或版本号下结论。我的做法是先记录节点名、版本和状态字段，再把需要宿主机真实 root 能力的组件列出来。官方给出的收益是降低容器逃逸后对宿主机的影响，但 user namespace 不能替代内核、seccomp 和运行时加固，也可能与某些 CNI、CSI 驱动存在兼容性边界。

用 kubectl 核对节点的实际状态

单节点核对可以直接读取 JSONPath。下面的命令只读取 Node 对象，不会修改集群；代码中的注释解释了字段和输出目的。

# 读取指定节点是否运行在 Linux user namespace 中
kubectl get node NODE_NAME -o jsonpath='{.status.nodeInfo.runningInUserNamespace}{"\n"}'

# 批量列出节点名和状态，便于发现混合节点
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.runningInUserNamespace}{"\n"}{end}'

输出为 true 时，说明该节点报告自己正在 user namespace 中运行；输出为 false 或字段为空时，不要凭一条命令猜测原因，继续查看 kubelet、容器运行时和集群创建工具的 rootless 配置。尤其是旧节点或混合版本节点，字段缺失本身就是需要人工确认的信号。

用标签和污点把 rootless 节点隔离出来

确认事实后，建议先加一个团队约定的标签，方便报表、亲和性和发布策略使用。标签名和污点键只是示例，生产环境应统一命名并纳入变更记录。

# 把已确认的 rootless 节点标成可筛选的调度边界
kubectl label node NODE_NAME node.kubernetes.io/rootless=true --overwrite

# 需要强制阻止普通 Pod 进入时再加 NoSchedule 污点
kubectl taint node NODE_NAME node.kubernetes.io/rootless=true:NoSchedule

NoSchedule 会影响没有对应容忍度的新 Pod，所以不要把加污点当作核对命令的附带动作。更稳妥的灰度顺序是先贴标签、观察 DaemonSet 和系统组件，再逐步迁移普通业务；只有确认调度边界和容忍度都清楚后，才在目标节点上启用污点。

升级后先做兼容性灰度

这项变化更像是权限边界的细化，而不是打开开关就能完成的安全升级。官方特别提醒，部分 CNI、CSI 驱动可能依赖更高的宿主机权限；节点上的网络初始化、存储挂载、设备插件和需要特权的 DaemonSet 都应列入灰度清单。建议选择一台非关键节点，记录 Pod 创建、网络连通、卷挂载和节点重启后的恢复情况，再扩大范围。

同时不要把 Pod 的 hostUsers: false 与节点 rootless 互相替代。两者可以组合，但排查问题时要分别记录：一个回答“Pod 内的用户如何映射”，另一个回答“节点组件在宿主机上以什么权限工作”。

常见问题

v1.37 升级后 feature gate 默认开启，节点就自动 rootless 了吗？

不是。默认开启只代表功能门控状态改变；是否使用 user namespace 仍取决于节点的实际启动方式。

runningInUserNamespace 字段为空能当作 false 吗？

不能直接等同。空值可能来自字段未报告、版本混用或实现差异，应补查 kubelet、运行时和节点创建方式。

为什么不一确认就给 rootless 节点加 NoSchedule？

因为污点会改变后续调度，可能让系统 DaemonSet、CNI 或 CSI 组件无法落盘。先标签、再盘点、后灰度，更容易定位影响。

这次 Beta 的实际价值，不是让所有节点立刻切换权限，而是让管理员能看到并管理这条边界。把 runningInUserNamespace 当作事实字段，把标签和污点当作调度策略，最后用驱动兼容性和节点恢复测试来决定推广范围，升级判断会更稳。