runAsNonRoot 报 non-numeric user：镜像用户名不足以验证 UID

Linux Pod 已经调度，镜像也已拉取，却不能启动，事件出现 image has non-numeric user (appuser), cannot verify user is non-root。镜像里即使已经创建了 appuser，这项启动检查仍可能失败。

这条错误表示 kubelet 取得了镜像中的用户名，却没有可用于非 root 检查的数字 UID，同时有效安全配置没有提供 runAsUser。它不证明 /etc/passwd 缺少该用户，也不证明这个用户实际是 root。

对照实际镜像与有效安全配置

先确认出错容器，包括 init container。以下命令读取对象，名称需替换：

kubectl -n team-app describe pod api-abc12
kubectl -n team-app get pod api-abc12 -o yaml
kubectl -n team-app get deployment api -o yaml

核对真实镜像标签或 digest，以及 Pod 层和该容器层的 securityContext。容器中的同名设置会覆盖 Pod 层设置；只看到 Pod 配了某个 UID，还要确认容器有没有另行覆盖。读取现有镜像的可信构建配置和身份记录，确认应用设计使用的 UID、GID，而不把镜像用户名当作数字身份。

Kubernetes 1.35 的 Linux 校验路径在启用 runAsNonRoot 时，会拒绝 runAsUser: 0。未指定 runAsUser，而镜像返回的身份只有用户名时，便无法完成这项数字检查。关闭 runAsNonRoot 只会绕过保护，并没有把运行身份核实清楚。

使用已经核实、与应用相容的数字身份

确认镜像中的应用账号实际 UID、GID 后，可以在原工作负载模板中显式配置。以下是容器层局部示例；10001 必须替换为这个镜像已经确认的身份，不能随意挑一个非零数字：

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  runAsGroup: 10001

这段放在实际目标容器下。若多个容器有不同身份，不要把一个容器的 UID 套给所有容器；Pod 层配置也应核对各容器的继承与覆盖。通过原部署入口修改模板，保留其他安全设置。

自己维护镜像时，也可以把最终 Dockerfile 的 USER 改为经核实的数字 UID/GID，再按正常构建和发布流程切换新镜像。这会改变最终运行身份声明，仍需与程序所需目录和挂载相容。不要为了通过校验给第三方镜像强加一个陌生 UID。

如果错误实际是 scratch 中根本无法解析用户名，处理方向不同，可看scratch 的 USER 与用户记录。把账号记录复制到镜像，并不自动解决 kubelet 这里只取得用户名的非 root 校验问题。

校验通过以后，还要验收权限

数字身份通过启动检查，只说明这一步可以继续。应用仍可能因为日志目录、缓存、挂载卷或证书文件的权限而失败；先按设计核对每条必要路径的数字属主、组与访问方式。

fsGroup 处理组访问，不代替 runAsUser 指定用户 UID。卷的组权限还受到存储驱动及实际处理路径限制，相关情况见CSI 卷的 fsGroup 检查。不把整个卷改成全员可写，也不通过特权容器掩盖身份问题。

更新前保留旧镜像、审定模板和恢复方式，安排新 Pod 的替换。验收应确认非 root 校验错误消失、应用实际 UID/GID 符合约定，必要文件读写和业务请求均正常。只看到对象创建成功或容器短暂启动，仍不够。

失败时从原管理入口恢复审定配置或镜像，核对新旧实例的业务状态。已经修改的卷权限不会随着模板回退自动恢复，应按保存的权限与数据恢复方案处理。