技术
containerd
业界标准的容器运行时
containerd 是一个容器运行时,管理主机上容器的完整生命周期 —— 镜像传输与存储、容器的执行与监管,以及底层的存储和网络挂接。它是大多数托管 Kubernetes 产品背后的默认运行时,也是 Docker 本身的底层。
工作原理
containerd 作为守护进程运行在每个节点上,并暴露一个 gRPC API,供更高层的系统使用 —— Kubernetes 的 kubelet(通过容器运行时接口 CRI)或 Docker Engine —— 来拉取镜像和启动容器。它将实际的进程执行委托给更低层的运行时(通常是 runc),使 containerd 专注于生命周期管理,而不是命名空间和 cgroup 的具体机制。
核心概念
- Image(镜像) —— 从镜像仓库拉取的不可变、分层的文件系统包。
- Snapshot(快照) —— containerd 根据镜像的各层为运行中的容器构建的写时复制文件系统。
- Task(任务) —— 容器的一个运行实例,由一个操作系统级进程支撑。
- Namespace(命名空间)(containerd 自己的,与 Kubernetes 命名空间不同)—— 在同一主机上隔离属于不同客户端的容器和资源。
为什么团队依赖 containerd
- 精简而专注。 它只做好一件事 —— 容器生命周期管理 —— 而不是捆绑 CLI、构建工具和编排功能。
- 原生支持 CRI。 它直接实现 Kubernetes 的容器运行时接口,因此 kubelet 与它通信时无需额外的 shim 层。
- 久经考验。 它是绝大多数生产环境 Kubernetes 集群底层的运行时。
- 已毕业的 CNCF 项目。 其治理和安全实践由托管 Kubernetes 本身的同一个基金会审核。
快速开始
在大多数托管的 Kubernetes 平台上,containerd 已经是配置好的运行时 —— 无需安装任何东西。若你确实需要直接配置它(自行管理的集群、裸金属节点,或使用 nerdctl 的本地开发),下面的指南涵盖了常见的配置方式。