核心是建立容器与宿主机间明确、安全、可预期的UID/GID映射关系，需分三层配置：宿主机层预分配子UID范围（如app-team:100000:65536），运行时层启用userns-remap（Docker需配daemon.json），Kubernetes层通过securityContext.runAsUser声明映射内UID（如0），并闭环验证文件归属与权限隔离。
核心是让容器内用户身份在宿主机上有明确、安全、可预期的对应关系，而不是默认共享 root 或随意匹配。关键不在“怎么设”，而在“谁管映射、在哪配、怎么验证”。
宿主机层：预分配子 UID/GID 范围
这是整个映射体系的地基，必须提前规划、全局唯一、避开系统保留 ID（0–999）。
- 为每个租户或服务用户在 /etc/subuid 和 /etc/subgid 中分配连续 65536 个 ID（最小推荐范围）
- 例如：app-team:100000:65536 表示该用户可在宿主机使用 UID 100000–165535，映射到容器内 0–65535
- 多个租户需严格错开起始值（如 100000、165536、231072），避免映射重叠导致权限越界
- 确保该用户真实存在：getent passwd app-team 应返回有效条目
容器运行时层：启用命名空间重映射
仅配 subuid/subgid 不生效，必须由 Docker、containerd 或 LXD 显式开启用户命名空间支持。
- Docker：在 /etc/docker/daemon.json 中添加 {"userns-remap": "app-team"}，重启 dockerd
- containerd（Kubernetes 默认）：需在 /etc/containerd/config.toml 中启用 userns_remap = "app-team" 并配置 userns_path
- LXC/LXD：对容器设置 lxc.idmap = u 0 100000 65536 和 lxc.idmap = g 0 100000 65536
- 验证是否生效：docker info | grep "Userns" 或查看容器进程在宿主机的 UID（应为 100000+）
Kubernetes 层：通过 securityContext 约束运行身份
即使底层启用了 user namespace，Pod 仍需显式声明用户，否则可能 fallback 到默认行为或触发拒绝。
- 在 Pod spec 中设置 securityContext.runAsUser 和 securityContext.fsGroup
- 值应落在映射范围内（如 0–65535），而非宿主机原始 UID；例如 runAsUser: 0 在映射后实际为宿主机 UID 100000
- 挂载 hostPath 或本地 PV 时，确保目标目录属主为映射起始 UID（chown 100000:100000 /mnt/data）
- 避免混用：runAsUser: 1000 + userns-remap 可能导致双重映射失败，优先统一用 0
文件挂载与验证：闭环检查权限表现
映射配置完成不等于权限就通了，必须验证容器内操作与宿主机文件归属的一致性。
- 容器内创建文件：touch /data/test，然后在宿主机执行 ls -n /mnt/data，确认 UID/GID 显示为 100000
- 容器内执行 id，应显示 uid=0、gid=0（即容器视角的 root）
- 尝试在容器内修改 /etc/hosts 或加载模块，应被拒绝（证明隔离生效）
- 若挂载 NFS 或 CephFS，需额外确认存储端支持 ID 映射（如 NFSv4.2 的 idmapd 配置）
