支持用户命名空间
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 存储和延迟的
限制,因为它不支持 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
输出结果应完全相同。