云原生发布于 2026/7/21更新于 2026/7/218分钟阅读顶有教育科技

containerd 2.3 LTS 对 Kubernetes 运维意味着什么

containerd 2.3 已进入 LTS 维护周期，本文解释 Kubernetes 节点运行时升级时需要关注的版本支持、CRI、runc、CNI 和回滚策略。

Kubernetes 节点真正负责拉镜像、创建容器、管理容器生命周期的组件，不是 kubelet 自己，而是容器运行时。现在最常见的运行时之一就是 containerd。

截至 2026 年，containerd 2.x 已经成为生产环境需要重点关注的版本线。其中 containerd 2.3 是 LTS 分支，官方维护周期到 2028 年 4 月。

这对 Kubernetes 运维很重要。

containerd 在 Kubernetes 中的位置

Kubernetes 通过 CRI 和容器运行时通信：

kubelet -> CRI -> containerd -> runc -> Linux kernel

当 Pod 创建失败时，问题可能出在很多层：

kubelet 参数错误
CRI 插件异常
containerd 配置错误
runc 不兼容
CNI 插件失败
镜像仓库或证书问题
cgroup、AppArmor、SELinux 限制

所以排障时不要只看 kubectl describe pod，还要会看节点上的运行时状态。

为什么 LTS 分支值得关注

containerd 官方维护页面显示，2.3 是 LTS 分支，维护周期更长。生产环境选择 LTS 分支的好处是：

安全修复周期更稳定。
适合长期运行的 Kubernetes 节点。
便于制定统一的节点镜像版本。
降低频繁 minor 升级带来的变更风险。

如果你的集群节点不是由云厂商完全托管，而是自己维护操作系统和运行时，LTS 分支尤其重要。

升级前先检查当前版本

在节点上执行：

containerd --version
ctr version
crictl version
runc --version

再检查 kubelet 使用的运行时端点：

ps aux | grep kubelet | grep container-runtime-endpoint

常见路径可能是：

unix:///run/containerd/containerd.sock

如果 crictl 没配置好，可以查看：

cat /etc/crictl.yaml

配置文件不要盲目覆盖

containerd 的配置通常在：

/etc/containerd/config.toml

升级时最危险的做法是直接用新默认配置覆盖旧配置。旧配置里可能有：

私有镜像仓库 mirror
sandbox image
cgroup driver
registry TLS 配置
runtime class
snapshotter
pause 镜像地址

建议先导出新默认配置对比：

containerd config default > /tmp/containerd-default.toml
diff -u /etc/containerd/config.toml /tmp/containerd-default.toml

再决定哪些字段要迁移。

重点检查 cgroup driver

Kubernetes 节点常见问题之一是 kubelet 和 containerd 的 cgroup driver 不一致。

检查 kubelet：

kubectl get node <node-name> -o yaml | grep -i cgroup

检查 containerd 配置：

grep -i SystemdCgroup /etc/containerd/config.toml

systemd 管理的现代 Linux 发行版上，通常建议使用 systemd cgroup。

升级后的节点验证

升级 containerd 后，不要只看服务启动：

systemctl status containerd

还要验证 CRI：

crictl ps
crictl images
crictl pods

再创建测试 Pod：

kubectl run runtime-test --image=nginx:alpine
kubectl get pod runtime-test -o wide
kubectl logs runtime-test

如果 Pod 一直 ContainerCreating，优先看：

journalctl -u containerd -f
journalctl -u kubelet -f

回滚策略

运行时升级必须有回滚方案。建议提前准备：

旧版本安装包
旧配置文件备份
节点 cordon/drain 流程
节点恢复后 uncordon 流程

示例：

kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

升级验证通过后：

kubectl uncordon <node>

总结

containerd 是 Kubernetes 节点稳定性的基础。2.3 LTS 的意义在于，它给自建集群提供了一个更适合长期维护的运行时版本线。

学习 Kubernetes 运维时，不要只停留在 kubectl。能理解 kubelet、CRI、containerd、runc、CNI 之间的关系，才算真正摸到节点层排障的门。