K3s + Sysbox：让容器拥有“虚拟机的灵魂”
K3s 二进制文件集成了运行生产级、符合 CNCF 标准的 Kubernetes 集群所需的全部组件，包括 containerd、runc、kubelet 等。在本文中，我们将介绍 containerd 如何与 OCI runtime 通信，并探讨如何在 K3s 中添加另一个容器运行时 —— Sysbox，以及它在运行系统级 Pod 时的应用场景。Containerd 与 Runc 的关系
首先，让我们简要了解一下 containerd 是如何与 runc 协作的。containerd 是一个常驻的守护进程，主要负责以下任务：
[*]镜像管理：从镜像仓库拉取并存储镜像。
[*]容器管理：管理容器生命周期（创建、启动、停止、删除）。
[*]快照管理：通过 snapshotter 管理容器文件系统层。
[*]运行时管理：将容器创建的任务委托给兼容 OCI 的运行时（如 runc）。
当你在 Kubernetes 中创建 Pod 时，kubelet 会通过 containerd 实现的 CRI 插件 向 containerd 发送请求，要求创建 Pod sandbox（RunPodSandbox）并创建容器（CreateContainer）。containerd 随后会启动一个 shim 进程，该进程在 containerd 与 OCI runtime（如 runc）之间充当中间层。
shim 的存在有一个关键作用：即便 containerd 守护进程崩溃或重启，容器依然可以继续运行。
在启动过程中，shim 会生成 OCI runtime 所需的 bundle（包括 config.json 和 rootfs 路径），然后调用 runc 二进制文件。runc 读取 config.json，配置容器的 namespace 和 cgroup，最后启动容器进程。
runc 是直接与 Linux 内核交互的组件——它负责配置 cgroup、namespace、seccomp、权限和挂载。当容器创建完成后，runc 就会退出，shim 则继续负责容器生命周期与 I/O 的管理。
Sysbox Runtime 简介
Sysbox 是由 Nestybox 创建的开源新一代容器运行时。与传统的 runc 不同，Sysbox 专为运行 “系统容器（system containers）” 而设计。它利用 Linux 用户命名空间（user namespaces） 以及其他内核特性，为容器提供更接近轻量虚拟机的行为。
这意味着，你可以在一个 Pod 中运行 Docker、Systemd、containerd，甚至 K3s 本身——而无需使用特权模式（privileged mode）。
简而言之，Sysbox 填补了应用容器与虚拟机之间的空白。它的典型应用场景包括：
[*]在 Kubernetes 中运行 Kubernetes（K8s-in-K8s）。
[*]构建需要完整操作系统环境的 CI/CD 流水线。
[*]提供具备虚拟机隔离级别但速度接近容器的开发环境。
目前，Sysbox 官方仅支持 CRI-O。
CRI-O 原生支持 Linux 用户命名空间，这是 Sysbox 运行的基础。
虽然 containerd 自 v2.0 起也加入了 user namespace 支持，但此前 sysbox-runc 存在一个 bug，导致与 containerd 不兼容。
Sysbox-runc 与 Containerd 的集成
经过排查这个问题之后，我们发现问题的根源在于 containerd 无法执行 sysbox-runc 的一个子命令 features，导致出现以下错误：
level=debug msg="failed to introspect features of runtime \"sysbox-runc\"" error="failed to unmarshal Features (*anypb.Any): type with url : not found"由于无法正确检测到 Sysbox 的功能特性，containerd 认为 sysbox-runc 不支持 user namespace，进而导致容器创建失败。该问题现已在 sysbox-runc 仓库中修复，使得 containerd 能够正确地与 sysbox-runc 协作运行。
在 K3s 中运行 Sysbox-runc
若要在 K3s 中使用 sysbox-runc，你需要首先拥有一个已运行的 K3s 集群。然后安装最新版本的 Sysbox。但由于 containerd 支持修复尚未合并到 Sysbox 主仓库（仅在 sysbox-runc 中），因此需要从源码构建最新版。
1. 安装 Docker
在构建 Sysbox 之前，请确保系统中已安装 Docker。
2. 克隆仓库并准备代码
git clone --recursive https://github.com/nestybox/sysbox.git
cd sysbox/sysbox-runc
git pull origin main
cd ..
make IMAGE_BASE_DISTRO=ubuntu IMAGE_BASE_RELEASE=jammy sysbox-static构建完成后，你可以将生成的二进制文件复制到 /usr/bin，或者直接在同一台运行 containerd 的机器上执行：
make install3. 启动 Sysbox
sysbox4. 创建 Sysbox RuntimeClass
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
name: sysbox-runc
handler: sysbox-runc5. 在 containerd 中添加 Sysbox 运行时配置
创建文件 /var/lib/rancher/k3s/agent/etc/containerd/config.toml.tmpl：
runtime_type = "io.containerd.runc.v2"
SystemdCgroup = false
BinaryName="/usr/bin/sysbox-runc"6. 使用 Sysbox 运行 Pod
apiVersion: v1
kind: Pod
metadata:
name: ubuntu
spec:
runtimeClassName: sysbox-runc
hostUsers: false
containers:
- name: ubuntu2204
image: ubuntu:22.04
command: ["sleep", "40000000000"]
restartPolicy: Never总结
Sysbox 为 Kubernetes 带来了新的能力：它允许在容器中运行系统级工作负载，具备强隔离性，同时不依赖特权模式。结合 K3s 使用后，它可以实现以下创新场景：
[*]在 Kubernetes 中运行 Kubernetes（如 K3k 虚拟集群）。
[*]为开发者提供安全、轻量的类似于虚拟机的沙箱。
[*]在 Pod 中运行系统守护进程或嵌套的容器引擎。
虽然目前 Sysbox 官方仅支持 CRI-O，但随着 sysbox-runc 的修复，它已经可以与 containerd 正常配合使用，从而实现与 K3s 的集成。
这也标志着容器生态的发展方向正在从传统的“应用容器”，逐步迈向更加灵活、具备系统级能力的“系统容器”。
如果你正在使用 K3s，并希望在 Pod 中探索系统级工作负载，Sysbox 无疑是一个值得尝试的方案，它让你在保持原生 Kubernetes 工作流的同时，获得接近虚拟机的隔离体验。
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ 感谢，下载保存了 新版吗？好像是停更了吧。 感谢发布原创作品，程序园因你更精彩 不错，里面软件多更新就更好了 感谢分享，学习下。 谢谢分享，试用一下 热心回复！ 收藏一下 不知道什么时候能用到 这个有用。 过来提前占个楼 谢谢分享，辛苦了 很好很强大我过来先占个楼 待编辑 这个好，看起来很实用 喜欢鼓捣这些软件，现在用得少，谢谢分享！ 收藏一下 不知道什么时候能用到 感谢分享，下载保存了，貌似很强大 过来提前占个楼 不错，里面软件多更新就更好了 东西不错很实用谢谢分享
页:
[1]
2