containerd 2.0 全面解读新特性、破坏性变更与迁移指南【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd导读本文以 docs/containerd-2.0.md 为骨架系统梳理 containerd 2.0 的重大更新——Transfer 与 Sandbox 服务转正、CRI 与 NRI/CDI 默认开启、守护进程配置升级到 version 3以及 Schema 1 镜像、Runtime V1 shim、AUFS snapshotter 等一批破坏性变更。读者阅读后可快速掌握 2.0 的核心能力、识别迁移风险点并获得可直接落地的配置与命令行操作示例。一、版本背景与总览containerd 2.0 是该项目进入 2.x 主线后的一个重要里程碑版本。与 1.x 相比2.0 不再只是小步迭代而是集中兑现了多年来积累的设计提案把 Transfer、Sandbox 等服务从实验状态提升为稳定 API同时果断移除了一批自 1.4~1.7 起就标记为废弃deprecated的能力推动社区向更现代、更安全的运行方式收敛。从本仓库的版本信息version/version.go可以看到containerd 以io.containerd.*命名空间组织所有插件与运行时组件。2.0 的变更面横跨服务层transfer、sandbox、introspection 等 gRPC/ttrpc 服务CRI 层内部 cri 插件internal/cri与外部插件封装plugins/cri客户端层Go 客户端库独立成包client运维层containerd守护进程配置、systemd 服务文件、ctr调试工具cmd/ctr。下文严格按官方 2.0 文档的 Whats new / Whats breaking / Whats changing 三个维度展开并结合仓库源码给出佐证。二、Whats new2.0 新增能力2.1 Transfer 服务正式转正StableTransfer 服务最早在 issue #7592 中提出2.0 中它被正式标记为稳定。其设计目标是提供一套与传输源/目的解耦的简单接口用于在任意源Source与目的Destination之间搬运 artifact 对象。Transfer 借鉴了 libchan 项目的核心思想把二进制流与数据通道作为 API 的一等公民从而在不频繁升级协议与 API 的前提下支撑更丰富的用例。从 core/transfer/transfer.go 可以看到其核心 Go 接口type Transferrer interface { Transfer(ctx context.Context, source any, destination any, opts ...Opt) error }对应的 proto 定义为见 core/transfer/transfer.go 与 docs/transfer.mdservice Transfer { rpc Transfer(TransferRequest) returns (google.protobuf.Empty); } message TransferRequest { google.protobuf.Any source 1; google.protobuf.Any destination 2; TransferOptions options 3; }Transfer 服务已在client.Transfer与ctr工具中集成用于向 containerd 执行 pull、push、import、export 镜像操作。官方转移操作矩阵如下详见 docs/transfer.md源Source目的Destination操作本地实现版本RegistryImage Storepull1.7Image StoreRegistrypush1.7对象流ArchiveImage Storeimport1.7Image Store对象流Archiveexport1.7对象流LayerMount/Snapshotunpack未实现Mount/Snapshot对象流Layerdiff未实现Image StoreImage Storetag1.7RegistryRegistry镜像仓库镜像未实现本地实现位于 core/transfer/local插件注册名称为io.containerd.transfer.v1可通过 containerd 配置启用[plugins] [plugins.io.containerd.transfer.v1]底层原理Streaming 服务。Transfer 之所以能同时支持 gRPC 与 ttrpc关键在于借助 streaming 服务传递二进制流与对象流客户端通过流管理器创建流以字符串流标识stream identifier随 proto RPC 传递服务端按标识取回流。进度Progress以异步回调方式从服务端发往客户端凭据Credentials则以同步回调方式在服务端遇到注册表鉴权请求时触发——这意味着镜像仓库的登录态可以始终保留在客户端侧服务端不会持有明文凭据。2.2 Sandbox 服务正式转正StableSandbox 服务在 issue #4131 中提出2.0 中同样被标记为稳定。它扩展了 containerd shim 的管理方式为 Pod、VM 等多容器场景提供更灵活、功能更丰富的抽象。结合 core/sandbox/controller.go 与 api/services/sandbox 中的 proto 定义可以推断Sandbox 控制器把“沙箱pod/VM 实例”与“容器沙箱内 workload”分层管理CRI 的 podsandbox 能力即构建于此之上。2.3 Sandboxed CRI 默认启用CRI 插件从遗留的 CRI server 切换到基于 sandbox controller 的 podsandbox 实现并且默认开启。这与此前“Sandbox 服务标记为稳定”的决定一脉相承——CRI 是 Sandbox 服务最大的消费方之一。2.4 Sandbox 属性支持运行时修改Update APISandbox 控制器新增Update接口gRPC 路径为/containerd.services.sandbox.v1.Controller/Update可以修改已存在沙箱的spec、runtime、extensions 与 labels。这让 Pod 级配置如资源扩展注解在运行期可调成为可能。2.5 NRI 默认启用NRINode Resource Interface是向 OCI 兼容运行时注入域/厂商特定逻辑的框架允许用户修改容器、执行附加动作、改进资源管理。2.0 起 NRI 默认开启。需要特别注意的运维含义NRI 插件被视为容器运行时的一部分访问 NRI 的权限通过限制系统级 NRI socket 的访问来控制。也就是说谁拥有 NRI socket 的访问权谁就拥有容器运行时的修改权部署时应像守护进程 socket 一样严格收敛权限。详细用法见 docs/NRI.md。2.6 CDI 默认启用CDIContainer Device Interface为设备厂商提供了一套标准机制用于描述访问 GPU 等特定资源所需的配置而不只是简单设备名。2.0 中 CDI 默认启用并且已纳入 Kubernetes Device Plugin 框架参见 Kubernetes Enhancement Proposal 4009。2.7 守护进程配置升级到 version 32.0 新增对 containerd 守护进程配置version 3的支持。守护进程在启动时会自动将旧配置迁移到最新版本迁移逻辑见 cmd/containerd/server/config/config.go其中通过version.ConfigVersion校验并调用MigrateConfigTo。这意味着旧版本配置在 2.0 守护进程上继续可用但官方建议主动迁移到最新版本以避免每次启动都执行迁移、优化守护进程启动时间。可以推断version 3 主要围绕插件目录结构、CRI 配置与 transfer/streaming 等新服务的默认值进行了规范化release 级别的配置说明见 RELEASES.md。2.8 Introspection API 新增 PluginInfoIntrospection 服务新增PluginInfo定义gRPC 路径/containerd.services.introspection.v1.Introspection/PluginInfo用于检视运行时插件的版本、特性features与注解annotations。ctr提供了对应的调试命令命令实现位于 cmd/ctr/commands/plugins/plugins.go 的inspect-runtime子命令内部调用client.RuntimeInfo并输出 JSON$ ctr plugins inspect-runtime --runtimeio.containerd.runc.v2 --runc-binaryrunc { Name: io.containerd.runc.v2, Version: { Version: v2.0.0-rc.X-XX-gXXXXXXXXX.m, Revision: v2.0.0-rc.X-XX-gXXXXXXXXX.m }, Options: { binary_name: runc }, Features: { ociVersionMin: 1.0.0, ociVersionMax: 1.2.0, ..., }, Annotations: null }从输出可以看到Features中的ociVersionMin/ociVersionMax直接反映了该运行时对 OCI 运行时规范版本的支持区间便于排查运行时兼容性问题。2.9 内置 tracing 插件支持 OTEL 标准环境变量2.0 为 containerd 内置 tracing 插件增加了对 OpenTelemetry 规范中标准 SDK 环境变量的支持见 pkg/tracing 与 docs/tracing.md。实现层面的启用前提如下务必注意必须同时设置OTEL_SDK_DISABLED且必须设置OTEL_EXPORTER_OTLP_ENDPOINT或OTEL_EXPORTER_OTLP_TRACES_ENDPOINT两者之一若未配置任何 endpointcontainerd 的 OTLP tracing 插件将保持禁用。2.10 Intel ISA-L igzip 支持containerd 客户端新增对 Intel ISA-Ligzip的支持如果系统存在 igzip客户端在 gzip 解压如拉取镜像时将优先使用它。官方文档指出基准测试显示 igzip 在 gzip 解压性能上优于 Go 内置 gzip 与外部 pigz 实现。注意这是客户端侧的加速能力是否生效取决于运行环境是否具备 igzip 库部署时可按需预装以提升镜像拉取解压吞吐。2.11 Image verifier 镜像校验插件Transfer 服务现在支持镜像校验插件image verifier plugins插件可实现“是否允许拉取该镜像”的策略例如强制要求镜像已签名、或强制要求镜像名称符合特定规则。关键实现约束插件是独立程序external plugins通过命令行参数与标准 I/O与 containerd 通信配置与开发指南见 docs/image-verification.md。2.12 CRI 支持用户命名空间User NamespacesCRI 插件现在支持以用户命名空间运行 Pod将 Pod 内的用户 ID 映射为主机上的不同用户 ID。这使得容器内 root 用户被隔离相比单独使用 seccomp 与 capabilities能进一步约束其在宿主机上的可用权限。前置条件需要 runc v1.2.0 或更高版本。2.13 CRI 支持递归只读挂载Recursive Read-Only MountsCRI 插件支持递归只读挂载用于禁止卷出现意外的可写子挂载submount。这为存储卷的只读语义提供了更严格的保证。2.14 CRI 默认开启非特权端口与 ICMPCRI 插件现在会为不使用宿主网络命名空间、也不使用用户命名空间的容器自动设置net.ipv4.ip_unprivileged-port-start0net.ipv4.ping_group_range0 2147483647效果是容器无需CAP_NET_BIND_SERVICE即可绑定 1024 以下端口无需CAP_NET_RAW即可执行ping。如需恢复旧行为可在 CRI 插件配置中显式关闭配置字段与源码对应关系见 internal/cri/config/config.go[plugins.io.containerd.grpc.v1.cri] enable_unprivileged_ports false enable_unprivileged_icmp false仓库的集成测试配置如 integration/client/testdata/default-1.7.toml中也体现了该字段的默认开启状态。2.15 废弃警告可通过 Introspection API 查询2.0 在 introspection 服务的Server响应/containerd.services.introspection.v1.Introspection/Server中加入了deprecation warningsctr工具通过ctr deprecations list展示。实现位于 cmd/ctr/commands/deprecations/deprecations.go命令会调用client.IntrospectionService().Server(ctx)将返回的DeprecationWarning含 ID、Message、LastOccurrence以表格或 JSON 输出# 人类可读的表格输出 $ ctr deprecations list ID LAST OCCURRENCE MESSAGE # 机器可读的 JSON 输出 $ ctr deprecations list --format json [{id:...,message:...,lastOccurrence:2026-01-01T00:00:00.00000000008:00}]对存量用户的价值社区已将该能力反向移植backport到 containerd 1.6 与 1.7 分支。因此运行containerd 1.6.27或 1.7.12的管理员即可查询到“标记为废弃且处于关键路径”的特性警告这为跨大版本1.x → 2.0迁移提供了非常实用的“排雷工具”先在自己的 1.x 环境跑ctr deprecations list --format json把命中的废弃项逐一处理再升级 2.0 会顺畅得多。三、Whats breaking破坏性变更与迁移动作3.1 Docker Schema 1 镜像支持默认关闭拉取 Docker Schema 1application/vnd.docker.distribution.manifest.v1prettyjws镜像的能力默认禁用。官方强烈建议将镜像迁移为 Docker Schema 2 或 OCI 镜像用最新版 Docker 或 nerdctl Buildkit 重新构建/推送。如确需临时恢复旧行为可设置环境变量# 对 containerd 守护进程影响 CRI 客户端如 Kubernetes、crictl CONTAINERD_ENABLE_DEPRECATED_PULL_SCHEMA_1_IMAGE1 # 对 ctr 客户端注意ctr 用户还必须追加 --local ctr --local image pull ...但请注意Schema 1 支持将在未来版本中彻底移除临时开关只用于过渡期。如何发现存量 Schema 1 镜像自 containerd 1.7.8 与 1.6.25 起Schema 1 镜像在拉取时会被打上io.containerd.image/converted-docker-schema1标签。可用如下命令扫描全命名空间ctr namespaces list --quiet | xargs -I{} -- ctr --namespace{} image list labels.io.containerd.image/converted-docker-schema13.2io_uring_*系统调用默认禁止以下系统调用已从默认 Seccomp 配置文件白名单中移除io_uring_enterio_uring_registerio_uring_setup原因大量被报告的 Linux 内核漏洞与io_uring相关其默认纳入白名单不再被推荐。对于依赖 io_uring 的合法负载如某些高性能存储/网络栈需要由管理员在运行时 Seccomp 配置中显式放行。3.3LimitNOFILE显式配置被移除参考 systemd 服务文件 containerd.service 中不再包含显式的LimitNOFILE配置该决定源于社区讨论 issue #8924。背后的机制需要理解containerd 的 rlimit 会被容器继承因此守护进程的LimitNOFILE会直接影响容器内的RLIMIT_NOFILE。官方建议使用 systemd 默认的LimitNOFILE配置。[!WARNING]重要运维提示在 systemd 版本低于 240 的平台上管理员应显式配置LimitNOFILE1024:524288否则可能回退到内核默认值4096导致高并发连接场景下文件描述符不足。3.4io.containerd.runtime.v1.linux与io.containerd.runc.v1移除自 containerd v1.4 起标记废弃的 Runtime V1io.containerd.runtime.v1.linux与 Runc V1io.containerd.runc.v1shim 已在 2.0 中移除。迁移目标明确使用io.containerd.runc.v2shim。3.5containerd.io/restart.logpath标签移除自 v1.5 起废弃的containerd.io/restart.logpath容器标签已移除应改用containerd.io/restart.loguri标签。3.6 CRI v1alpha2 API 移除自 v1.7 起废弃的 CRI v1alpha2 API 已移除需迁移到CRI v1。Kubernetes 用户可对照 RELEASES.md 中的 Kubernetes 支持矩阵确认自己所用 K8s 版本的兼容性。3.7 AUFS snapshotter 移除自 v1.5 起废弃的内置aufssnapshotter 已移除官方推荐改用overlayfssnapshotter。快照器选型说明见 docs/snapshotters/README.md。3.8cri-containerd-*-VERSION-OS-ARCH.tar.gz发布包移除自 v1.7 起废弃的cri-containerd-(cni-)-VERSION-OS-ARCH.tar.gz一体化发布包已从 release 中移除。新的安装方式是分别安装以下组件containerd 本体containerd-VERSION-OS-ARCH.tar.gzruncCNI plugins注意CRI 插件自 containerd 1.1 起就已内置于 containerd 本体因此无需单独安装 CRI。完整安装步骤见 docs/getting-started.md。四、Whats changing行为与配置变化4.1 containerd 客户端独立成包containerd 客户端 Go 库已迁移到独立包github.com/containerd/containerd/v2/client对应本仓库 client 目录。这降低了客户端对守护进程内部实现的依赖便于独立演进版本。基于客户端二次开发的入门示例见 docs/getting-started.md 中的 “Implementing your own containerd client”。4.2 CRI registry 属性废弃以下[plugins.io.containerd.grpc.v1.cri.registry]属性已废弃将在未来版本移除废弃属性迁移方案mirrorsCRIRegistryMirrors改用config_path见 docs/hosts.mdauthsCRIRegistryAuths改用 KubernetesImagePullSecretsconfigsCRIRegistryConfigs改用config_path见 docs/hosts.md4.3 Go-plugin 动态库插件废弃将 Go-plugin 库*.so即“动态插件”作为 containerd 运行时插件的方式已废弃将在未来版本移除。受影响的配置特征containerd 配置根级存在plugin_dir。建议迁移到proxy 或 binary 外部插件模式详见 docs/PLUGINS.md。4.4 events Envelope 打包方式废弃以下两个 events Envelope 类型支持已废弃将在未来版本移除service.events.Envelopettrpc.events.Envelope建议统一迁移到types.Envelope。4.5 CRI CNI 配置模板支持扩展自 v1.7.0 起曾标记废弃的 CRI 配置[plugins.io.containerd.grpc.v1.cri.cni.conf_template]支持被扩展而非移除即该能力在 2.0 中继续可用。五、升级 2.0 的检查清单结合全文这里给出一份可操作的迁移自检清单镜像层面确认无 Docker Schema 1 镜像用io.containerd.image/converted-docker-schema1标签扫描如有则重新构建为 Schema 2/OCI运行时层面确认所有容器使用io.containerd.runc.v2shim未引用已移除的 v1 shimCRI 层面确认 K8s 版本支持 CRI v1如有自定义 CRI registrymirrors/auths/configs配置迁移到config_path与ImagePullSecrets快照器层面若使用 aufs切换为 overlayfs安全策略层面评估负载是否依赖io_uring_*系统调用与 1024 以下端口绑定、ping等默认行为变化可用enable_unprivileged_ports/enable_unprivileged_icmp回退systemd 层面systemd 240 的平台显式配置LimitNOFILE1024:524288升级前体检在 1.6.27/1.7.12 环境运行ctr deprecations list --format json逐一处理命中的废弃项后再升级配置层面将守护进程配置显式升级到version 3避免每次启动时的自动迁移开销。六、总结containerd 2.0 是一次“收敛与兑现”的版本Transfer、Sandbox 服务正式稳定Sandboxed CRI、NRI、CDI 默认开启Introspection 提供插件信息与废弃警告的机器可读查询同时果断移除 Schema 1 镜像、Runtime V1 shim、AUFS snapshotter、CRI v1alpha2 等历史包袱。对于存量部署建议先借助 backport 到 1.6/1.7 的ctr deprecations list完成“体检”再按本文清单逐项迁移即可平稳过渡到 2.0 的新架构。【免费下载链接】containerdAn open and reliable container runtime项目地址: https://gitcode.com/GitHub_Trending/co/containerd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考