支持用户命名空间
Kubernetes 自 v1.25 起支持使用用户命名空间运行 pod。本文档解释了
containerd 对该功能的支持。
什么是用户命名空间？
用户命名空间将容器内运行的用户与主机内的用户隔离开来。
在容器中以 root 用户身份运行的进程可以在主机中以不同的（非 root）用户身份运行。换句话说，进程在用户命名空间内的操作具有完全权限，但在命名空间外的操作则没有权限。
您可以使用此功能来减少受损容器对主机或同一节点中其他损害。有几个被评为 "高度 "或 "严重 "的安全漏洞在用户命名空间处于活动状态时无法被利用。预计用户命名空间也将缓解一些未来的漏洞。
有关用户命名空间的高级介绍，请参阅[kubernetes 文档]kube-intro
栈要求
Kubernetes 的实现在 1.27 版中进行了重新设计，因此，Kubernetes 1.27 之前和之后的版本要求有所不同。
请注意，如果尝试在 containerd 1.6 或更早版本中使用用户命名空间，pod.spec 中的 `hostUsers：false "设置将被无声地忽略。
Kubernetes 1.25 和 1.26
- Containerd 1.7
- 您可以使用 runc 或 crun 作为 OCI 运行时：
- runc 1.1 或更高版本
- crun 1.4.3 或更高版本
也可以使用 containerd 2.0 或更高版本，但[要求与 Kubernetes 1.27 及更高版本相同]，除了Linux 内核。请记住，所有要求都适用包括支持 idmap 挂载的文件系统。您可以使用 Linux版本：
- Linux 5.15：你将受到 [containerd 1.7 存储和延迟的
限制](#containerd 1.7 存储和延迟的 限制)，因为它不支持 overlayfs 的 idmap 挂载。 - Linux 5.19 或更高版本（推荐）：它不受 [containerd 1.7 存储和延迟限制]（#Limitations
限制，因为 overlayfs 在此内核版本上开始支持 idmap 挂载。
Kubernetes 1.27 或更高版本
- Linux 6.3 或更高版本
- Containerd 2.0 或更高版本
- 可使用 runc 或 crun 作为 OCI 运行时：
- runc 1.2 或更高版本
- crun 1.9 或更高版本
此外，pod 中的卷所使用的所有文件系统都需要内核支持 idmap挂载。Linux 6.3 中支持 idmap 挂载的常用文件系统有 btrfs、ext4、xfs、fat、tmpfs、overlayfs。
kubelet 负责向容器填充一些文件（如 configmap、secret 等）。该路径中使用的文件系统也需要支持 idmap 挂载。请参阅Kubernetes文档 获取更多信息。
使用用户命名空间创建 Kubernetes pod
首先检查你的 containerd、Linux 和 Kubernetes 版本。如果这些都没问题，那么就不需要对 conntainerd 进行特殊配置。你只需按照 Kubernetes网站中的步骤即可。
限制
你可以查看 Kubernetes 的限制 此处。请注意，不同的Kubernetes 版本有不同的限制，请务必查看您正在使用的 Kubernetes 版本的网站
不同的 containerd 版本也有不同的限制，本节将重点介绍这些限制。
containerd 1.7
containerd 1.7 中存在的一个限制是，它需要更改容器镜像中每个文件和目录的所有权。
这意味着它会产生存储开销，因为每次创建 Pod 时，容器镜像的大小都会重复(译者:没明白)。而且会严重影响容器启动延迟，因为进行这样的复制也需要时间。
您可以将 /sys/module/overlay/parameters/metacopy切换为 Y，以减少这一限制。
这将大大减少存储和性能开销，因为只有容器镜像中每个文件的 inode
而不是文件内容。这意味着存储空间，而且速度更快。不过，这也不是万能的。
如果要更改元数据拷贝参数，请确保更改方式在重启时具有持久性。您还应注意，此设置将用于所有容器，而不仅仅是启用了用户命名空间的容器。这将影响您手动拍摄的所有快照（如果您碰巧这样做）。在这种情况下，请确保在创建和恢复快照时使用相同的 /sys/module/overlay/parameters/metacopy 值。
containerd 2.0 及以上版本
containerd 1.7 中的存储和延迟限制在容器 2.0 及以上版本中不存在、如果使用覆盖快照器（默认情况下使用）。它根本不会占用更多存储空间、而且没有启动延迟。
这是通过将内核特性 idmap和容器 rootfs（容器镜像一起 挂载。这允许覆盖文件系统以不同的 UID/GID 显示镜像，而无需复制文件或 inodes，只需使用绑定挂载即可。
默认情况下，Containerd 将拒绝创建带有用户命名空间的容器。快照器和运行的内核不支持 overlayfs 的 idmap 挂载，则 Containerd 默认会拒绝创建带有用户名称空间的容器。 这是为了确保在使用昂贵的 chown 之前（在存储和 pod 启动延迟方面），确保您了解其影响并决定opt-in。请阅读 containerd 1.7 限制中的的解释。
如果你的内核不支持 overlayfs snapshotter 的 idmap 挂载，你会看到一个错误：
failed to create containerd container: snapshotter "overlayfs" doesn't support idmap mounts on this host, configure `slow_chown` to allow a slower and expensive fallback
从 5.19 版开始，Linux 支持在 overlayfs 上挂载 idmap。
你可以通过在配置中的 overlayfs快照器部分添加 slow_chown 字段，就可以选择慢速 chown：
[plugins."io.containerd.snapshotter.v1.overlayfs"]
slow_chown = true
请注意，只有 overlayfs 用户需要选择使用慢速 chown，因为只有它才是containerd 提供的更好的选择（在containerd 中只有 overlayfs 快照器支持 idmap 挂载）。如果你使用其他快照器。如果您使用另一个快照器，您将返回到昂贵的 chown，而无需opt-in。
不过，你可以仔细检查你的容器是否为容器镜像是否使用了 idmap 挂载：
mount | grep overlay
你应该在 lowerdir 参数中看到对 idmap 挂载的引用，在本例中，我们可以看到
idmapped"：
overlay on / type overlay (rw,relatime,lowerdir=/tmp/ovl-idmapped823885363/0,upperdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/1018/fs,workdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/1018/work)
使用 ctr 创建包含用户命名空间的容器
你也可以使用 ctr 创建带有用户命名空间的容器。这比较低级，请注意。
按照 此处 的说明创建一个 OCI bundle。然后，将 UID/GID 更改为 65536：
sudo chown -R 65536:65536 rootfs/
复制 this config.json 并将 XXX-path-to-rootfs 替换为刚刚授权的rootfs的绝对路径。
然后创建并启动容器：
sudo ctr create --config <path>/config.json userns-test
sudo ctr t start userns-test
这将在容器内打开一个 shell。你可以运行这个，以验证你是否在一个用户命名空间内：
root@runc:/# cat /proc/self/uid_map
0 65536 65536
输出结果应完全相同。