Containerd的Bug导致容器被重建！如何避免？

最近我们关注到一个关于containerd 运行时的issue

（https://github.com/containerd/containerd/issues/7843），该问题在 containerd v1.6.9/v1.5.15 被引入。出现的问题是，当 containerd 重启后，在其中运行的 Pod 元数据中关于网络相关的数据（如 pod ip）丢失，核心原因在于部分数据没有落盘。

受影响的版本：

• v1.6.9 ~ v1.6.14，问题在 v1.6.15 版本中被修复。

• v1.5.15 ~ v1.5.16，问题在 v1.5.17 版本中被修复。

通过以下步骤，可以快速重现该问题，并验证该问题的修复情况。

本文使用 rke2 为例进行演示，版本为 rke2 v1.24.9+rke2r1，该版本使用了 k3s-containerd v1.6.12-k3s1，受该 containerd 问题影响。

在 containerd 的默认行为中，重启 containerd 服务不会影响正在运行的业务容器，并在启动容器时，通过将容器父进程绑定 Pid 1 的方式进行体现。即使使用 systemctl 对服务进行重启，也不会影响到已经在运行的容器状态。

——问题重现——

#配置rke2使用国内镜像仓库下载镜像
mkdir-p/etc/rancher/rke2
echo"system-default-registry:registry.cn-hangzhou.aliyuncs.com">/etc/rancher/rke2/config.yaml
#使用命令安装rke2，以下命令使用了我们在国内维护的rke2安装镜像脚本，会从aliyunOSS下载RKE2资源
curl-sfLhttps://rancher-mirror.oss-cn-beijing.aliyuncs.com/rke2/install.sh|INSTALL_RKE2_MIRROR=cnINSTALL_RKE2_VERSION=v1.24.9+rke2r1sh-
#[INFO]usingv1.24.9-rke2r1asrelease
#[INFO]downloadingchecksumsathttps://rancher-mirror.rancher.cn/rke2/releases/download/v1.24.9-rke2r1/sha256sum-amd64.txt
#[INFO]downloadingtarballathttps://rancher-mirror.rancher.cn/rke2/releases/download/v1.24.9-rke2r1/rke2.linux-amd64.tar.gz
#[INFO]verifyingtarball
#[INFO]unpackingtarballfileto/usr/local

#启动rke2服务，并等待服务启动成功
systemctlstartrke2-server

#配置rke2相关的PATH路径以及kube-config路径
exportKUBECONFIG=/etc/rancher/rke2/rke2.yaml
exportPATH=/var/lib/rancher/rke2/bin:$PATH

#使用kubectl查询当前集群状态
kubectlgetpo-A|greprke2-metrics-server-5b987d776b-gqxv9

#kube-systemrke2-metrics-server-5b987d776b-gqxv91/1Running015m

至此，rke2 单节点服务启动完成，但我们的目标是 containerd，接下来继续操作：

#配置containerd相关环境变量
exportCRI_CONFIG_FILE=/var/lib/rancher/rke2/agent/etc/containerd/config.tomlCONTAINER_RUNTIME_ENDPOINT=unix:///var/run/k3s/containerd/containerd.sock
#使用crictl查询pods以及container信息
crictlpods|greprke2-metrics-server

#bfad44591742318minutesagoReadyrke2-metrics-server-5b987d776b-gqxv9kube-system0(default)

crictlps|greprke2-metrics-server

#db5d6392a310ef6dc23a68f5fb18minutesagoRunningmetrics-server0bfad445917423rke2-metrics-server-5b987d776b-gqxv9

我们以 metrics-server 的 pod 为例，查询 pod 详情中的网络部分内容，并对 containerd 进行重启，对问题进行重现：

#查询metrics-serverpod的详情
crictlinspectpbfad445917423|jq.status.network

#{
#"additionalIps":[],
#"ip":"10.42.0.6"
#}

#停止rke2-server服务并单独启动containerd，避免kubelet影响重现结果
systemctlstoprke2-server
#单独启动containerd
containerd-c/var/lib/rancher/rke2/agent/etc/containerd/config.toml-a/run/k3s/containerd/containerd.sock--state/run/k3s/containerd--root/var/lib/rancher/rke2/agent/containerd

通过新的 terminal，使用 crictl 查询 containerd 运行状态

crictlpods|greprke2-metrics-server

#bfad44591742324minutesagoReadyrke2-metrics-server-5b987d776b-gqxv9kube-system0(default)

#再次查询metrics-serverpod详情
crictlinspectpbfad445917423|jq.status.network

#{
#"additionalIps":[],
#"ip":""
#}

从最后的返回结果可以看出，containerd 重启后容器的 IP 丢失。

——问题影响——

通过在上述例子中重启 rke2-server 可以看到，由于 ip 信息丢失，导致了业务容器被重建，带来了业务中断的风险。

#在中断containerd进程后，重启rke2-server进程(以下数据为重新验证后的数据)
systemctlrestartrke2-server
kubectlgetpo-A|greprke2-metrics-server-5b987d776b-8vg69

#kube-systemrke2-metrics-server-5b987d776b-8vg691/1Running2(115sago)23m

crictlpods|greprke2-metrics-server

#caba6d8d1582341secondsagoReadyrke2-metrics-server-5b987d776b-8vg69kube-system1(default)
#2dec6a11fd36f22minutesagoNotReadyrke2-metrics-server-5b987d776b-8vg69kube-system0(default)

可以看到，在 rke2-server 重启后，使用了 cni 的 pod 发生了重启，在 crictl pods 返回中可以看到重新创建的 pods。

——问题修复验证——

下载新版本 containerd，这次验证使用 k3s-containerd v1.6.14+k3s1。该版本为 Rancher 在 containerd v1.6.15 发布前紧急发布的修复补丁版本。

#拉取新镜像
dockerpullrancher/hardened-containerd:v1.6.14-k3s1-build20230105
mkdircontainer-new
cdcontainer-new
#从镜像中获取新版本containerd
dockerrun--rm-it-v${PWD}:/outputrancher/hardened-containerd:v1.6.14-k3s1-build20230105cp-r/usr/local/bin/output
./output/bin/containerd--version
#containerdgithub.com/k3s-io/containerdv1.6.14-k3s16f9c63d571f5026e85a0768f0f2ef03d1c8dbc6e

#关闭当前运行的容器
pkill-f/var/lib/rancher/rke2/data/v1.24.9-rke2r1-d4d8faf800d0/bin/containerd-shim-runc-v2
#替换containerdbinary版本
cp./bin/*/var/lib/rancher/rke2/bin
/var/lib/rancher/rke2/bin/containerd--version
#containerdgithub.com/k3s-io/containerdv1.6.14-k3s16f9c63d571f5026e85a0768f0f2ef03d1c8dbc6e

#启动rke2
systemctlstartrke2-server
#此时使用crictl查询新的metrics-serverpod
crictlpods|grep"Ready"|grepmetrics-server
#ad8b101f819df3minutesagoReadyrke2-metrics-server-5b987d776b-gqxv9kube-system1(default)

#停止rke2并使用命令行启动containerd
systemctlstoprke2-server
containerd-c/var/lib/rancher/rke2/agent/etc/containerd/config.toml-a/run/k3s/containerd/containerd.sock--state/run/k3s/containerd--root/var/lib/rancher/rke2/agent/containerd

通过新的 terminal，使用 crictl 查询 containerd 运行状态

crictlinspectpad8b101f819df|jq.status.network
#{
#"additionalIps":[],
#"ip":"10.42.0.13"
#}

可以看到 containerd 重启后，pod ip 没有丢失。

—— RKE2 与 RFO——

RKE2 以下版本受该 issue 影响：

• v1.23.15+rke2r1

• v1.24.9+rke2r1

• v1.25.5+rke2r1

• v1.26.0+rke2r1

该 issue 在 2022 年 12 月 20 日被提交，RKE2 团队在 2023 年 1 月 6 日紧急合并了 containerd 中修复该 issue 的 commit，发布了 k3s-containerd v1.6.14+k3s1 版本，并发布了新的 rke2 rc 版本进行测试验证。

最终在 1 月 11 日，RKE2 团队发布以下已经修复 containerd 问题的版本：

• v1.23.16+rke2r1

• v1.24.9+rke2r2

• v1.25.5+rke2r2

• v1.26.0+rke2r2

RFO 是 Rancher For openEuler 的缩写，顾名思义，目的在于面向 openEuler 打造 Rancher 基础平台。

由于 RFO 版本发布周期在 RKE2 之后，RFO 并没有受到该 issue 影响，并在近期发布了以下版本：

• v1.23.16+rfor1

• v1.24.9+rfor1

• v1.24.10+rfor1

• v1.25.5+rfor1

• v1.25.6+rfor1

• v1.26.0+rfor1

• v1.26.1+rfor1

—— 写在最后 ——

由于操作系统的软件包发布存在一定的时间延后性，在大部分情况下都无法及时修复软件出现的问题。像 CVE、功能缺陷等问题都比较紧急，等待操作系统供应商提供修复版本将是一个漫长的过程，甚至有时候由于一些限制，操作系统提供商无法提供新版本的软件包，这会给系统运行带来不确定因素。

在这种情况下，将软件自身依赖的组件打包到自己的 rootfs 中进行分发，能更好地对其进行管理和升级，避免给系统运行带来风险以及潜在的损失。

---

审核编辑 ：李倩