containerd
containerd 是一个开源、业界标准的容器运行时及配套平台,用于管理容器镜像和容器生命周期。
最近更新 2026年10月14日
AI 爬虫读取
1次请求
1家公司- Anthropic1
- 词条页
- 1
- 争议页
- 0
- JSON · MD
- 0
- 首次读取
- 2026年11月4日
- 最近读取
- 2026年11月4日
统计自 2026年10月28日 · 数据来自本站服务器日志
概览
containerd 是一个开源容器运行时项目,专注于可靠运行容器所需的核心生命周期操作。它负责镜像传输与存储、容器创建、执行、监控、网络集成以及与运行时的交互,而将更高层的编排和开发者工作流交由其他系统处理。该项目被广泛用作云原生基础设施的基础组件,尤其是在 Kubernetes 集群和托管容器平台中。 该项目起源于 Docker 内部,旨在将底层容器执行引擎与 Docker 更广泛的应用和开发者体验分离。Docker 于 2015 年宣布 containerd 为一个独立的核心组件,旨在提供稳定、可复用的运行时层。2017 年,Docker 将 containerd 捐赠给云原生计算基金会(CNCF),使该项目与 Kubernetes 及其他云原生技术一同置于中立的开源治理环境中。containerd 随后成为 CNCF 的独立项目,并于 2019 年达到毕业状态。 其架构刻意采用模块化设计。守护进程暴露 API,并通过插件实现镜像分发、内容存储、快照器、元数据、运行时集成和网络相关功能等能力。OCI 兼容的镜像和运行时是其互操作性模型的核心。该项目通常使用 runc 作为默认的底层运行时,同时通过其运行时接口支持替代运行时。Kubernetes 通过容器运行时接口(CRI)与 containerd 交互,使 Kubernetes 节点无需完整的 Docker Engine 栈即可运行容器。 containerd 主要并非作为终端用户应用来推广。其用户是平台工程师、云提供商、Linux 发行版厂商、Kubernetes 运维人员、企业基础设施团队以及构建容器平台的开发者。它被多个商业和开源产品嵌入或作为运行时组件提供,包括 Kubernetes 发行版和托管容器服务。这种嵌入式角色意味着该品牌对终端用户的可见度通常低于构建在其之上的平台,尽管它是一项重要的基础设施依赖。 该项目在 CNCF 下通过开源社区流程进行治理。其开发、发布、文档、安全响应和生态系统关系由来自 Docker、云提供商、基础设施供应商、Linux 发行版厂商和独立工程团队的贡献者共同维护。该项目本身没有单独披露的公司总部、公开股票上市或传统的管理层结构。其当前定位是一个中立、可移植、生产级的容器运行时,以及云原生计算的关键构建块。
沿革
containerd 源于 Docker 对专注、可复用的核心运行时的需求。2015 年,Docker 宣布启动该项目,旨在从更庞大的 Docker Engine 中抽取出容器管理的基本功能,并使其可供其他平台使用。其设计将镜像处理、文件系统快照、容器进程监管和运行时调用等底层任务,与镜像构建、开发者命令、应用打包和编排等更高层的关注点分离开来。 随着容器技术扩展到 Docker 产品生态之外,这种分离变得愈发重要。云服务商、Linux 发行版、Kubernetes 用户和基础设施厂商都希望获得一个可以嵌入、而无需采纳 Docker Engine 全部组件的运行时。containerd 采用开放接口以及兼容 OCI 的镜像和运行时标准,使其适合这一角色。其基于守护进程的架构也为需要创建和管理容器的工具提供了稳定的服务边界。 2017 年 3 月,Docker 将 containerd 捐赠给云原生计算基金会。此次捐赠使该项目归属于一个与 Kubernetes 及其他云原生技术相关的中立基金会。这也促成了更广泛的技术参与,并帮助 containerd 确立为通用基础设施项目,而非仅服务于 Docker 的实现。大约在这一时期,项目持续完善其插件模型、镜像分发支持、快照器抽象、运行时集成和运维工具。 2017 年 containerd 1.0 的发布标志着一个重要的稳定节点。Kubernetes 随后通过容器运行时接口将 containerd 采纳为主要运行时选项之一。当 Kubernetes 弃用并最终移除对名为 dockershim 的 Docker Engine 集成的直接依赖时,这一关系变得更加重要。这一转变并未使 Docker 镜像过时:containerd 继续支持 OCI 和兼容 Docker 的镜像,同时提供 Kubernetes 节点所需的运行时服务。 CNCF 于 2019 年宣布 containerd 毕业。毕业表明该项目已展现出持续的生产使用、活跃且多元的社区、有文档记录的治理以及成熟的技术基础。后续版本系列扩展了功能和运维可靠性。2021 年发布的 containerd 1.6 成为生产部署的重要长期分支,而之后的版本继续在运行时支持、镜像管理、插件行为和平台兼容性方面进行改进。 containerd 2.0 于 2024 年作为新的主要版本发布。该版本体现的是项目 API、插件生命周期和支持集成的演进,而非其基本使命的改变。纵观其历史,containerd 始终有意保持范围狭窄:它提供核心容器生命周期基础设施,而不是试图取代编排系统、容器构建工具、镜像仓库或完整的开发者平台。 如今,containerd 作为 CNCF 托管的开源项目运行,贡献者来自整个云原生生态。基础设施团队直接使用它,也通过 Kubernetes 发行版、托管 Kubernetes 服务、容器平台和 Linux 软件包间接使用它。其重要性较少来自消费者认知,而更多来自它在软件供应链中的位置:它是连接容器镜像、操作系统、底层运行时和编排系统的通用运行时层。
- 2024
containerd 2.0
[2]该项目发布了 2.0 主要版本,更新了接口和插件行为,同时保持其作为核心容器运行时的角色。
- 2021
containerd 1.6 系列
[2]1.6 发布系列继续在生产环境中得到采用,并扩展了运行时、镜像、插件和平台能力。
- 2019
CNCF 毕业
[4]containerd 在展示了成熟度、采用率、治理和社区健康后,从 CNCF 孵化流程中毕业。
- 2017
捐赠给 CNCF
[3]Docker 将 containerd 捐赠给云原生计算基金会,以实现中立治理和更广泛的生态系统协作。
- 2017
containerd 1.0
[2]首个 1.0 版本建立了稳定的面向生产的运行时基础和插件架构。
- 2015
Docker 推出 containerd
[1]Docker 宣布 containerd 为一个专注的核心容器运行时,旨在可在完整的 Docker Engine 产品之外复用。
产品与定位
一个中立、开源、生产级容器运行时,是 Kubernetes、云平台和容器工具链的核心基础设施层。
容器运行时 · 2015
containerd 守护进程
containerd 主服务负责管理容器镜像、元数据、快照、容器进程以及运行时连接,提供上层工具和编排平台所使用的核心守护进程与 API 接口。
Kubernetes 集成
CRI 插件
容器运行时接口(CRI)插件使 Kubernetes kubelet 能够将 containerd 用作节点运行时。它把 Kubernetes 的运行时操作转换为 containerd 服务,并集成镜像与 Pod 沙箱管理。
运行时进程管理
containerd-shim
shim 架构使容器进程独立于主守护进程进行管理,有助于在守护进程发生事件时保持运行中的工作负载,并允许不同的运行时实现与 containerd 集成。
容器文件系统存储
快照器框架
快照器为容器镜像和可写容器文件系统提供可插拔的文件系统层存储。该抽象支持不同的存储技术和部署需求。
品牌决策
2024
containerd 2.0 发布换代背景
该项目需要一个新的主版本线来演进 API、插件行为和支持的集成。
采取的行动
社区发布了 containerd 2.0。
后续影响
新主版本延续了 containerd 作为生产运行时的角色,同时建立了新的兼容性和维护基线。
2019
CNCF 毕业战略背景
containerd 已在生产环境中获得广泛采用,并建立了成熟的贡献者和治理模式。
采取的行动
CNCF 将 containerd 从孵化阶段毕业。
后续影响
毕业巩固了 containerd 作为稳定、厂商中立的基础设施层的地位。
2017
将 containerd 移交 CNCF 中立治理并购背景
Docker 的运行时组件与 Docker 自身产品栈之外的项目和厂商日益相关。
采取的行动
Docker 将 containerd 作为开源项目捐赠给云原生计算基金会。
后续影响
该项目获得了中立基金会治理,并成为云原生生态系统中可广泛复用的组件。
来源5 个来源
引用本词条: 请引用规范词条页。 /brand-wiki/containerd · 编辑方针 · 词条如何编纂