Containerd的Bug導(dǎo)致容器被重建！如何避免？

最近我們關(guān)注到一個(gè)關(guān)于containerd 運(yùn)行時(shí)的issue

（https://github.com/containerd/containerd/issues/7843），該問題在 containerd v1.6.9/v1.5.15 被引入。出現(xiàn)的問題是，當(dāng) containerd 重啟后，在其中運(yùn)行的 Pod 元數(shù)據(jù)中關(guān)于網(wǎng)絡(luò)相關(guān)的數(shù)據(jù)（如 pod ip）丟失，核心原因在于部分?jǐn)?shù)據(jù)沒有落盤。

受影響的版本：

• v1.6.9 ~ v1.6.14，問題在 v1.6.15 版本中被修復(fù)。

• v1.5.15 ~ v1.5.16，問題在 v1.5.17 版本中被修復(fù)。

通過以下步驟，可以快速重現(xiàn)該問題，并驗(yàn)證該問題的修復(fù)情況。

本文使用 rke2 為例進(jìn)行演示，版本為 rke2 v1.24.9+rke2r1，該版本使用了 k3s-containerd v1.6.12-k3s1，受該 containerd 問題影響。

在 containerd 的默認(rèn)行為中，重啟 containerd 服務(wù)不會(huì)影響正在運(yùn)行的業(yè)務(wù)容器，并在啟動(dòng)容器時(shí)，通過將容器父進(jìn)程綁定 Pid 1 的方式進(jìn)行體現(xiàn)。即使使用 systemctl 對(duì)服務(wù)進(jìn)行重啟，也不會(huì)影響到已經(jīng)在運(yùn)行的容器狀態(tài)。

#配置rke2使用國(guó)內(nèi)鏡像倉(cāng)庫(kù)下載鏡像
mkdir-p/etc/rancher/rke2
echo"system-default-registry:registry.cn-hangzhou.aliyuncs.com">/etc/rancher/rke2/config.yaml
#使用命令安裝rke2，以下命令使用了我們?cè)趪?guó)內(nèi)維護(hù)的rke2安裝鏡像腳本，會(huì)從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

#啟動(dòng)rke2服務(wù)，并等待服務(wù)啟動(dòng)成功
systemctlstartrke2-server

#配置rke2相關(guān)的PATH路徑以及kube-config路徑
exportKUBECONFIG=/etc/rancher/rke2/rke2.yaml
exportPATH=/var/lib/rancher/rke2/bin:$PATH

#使用kubectl查詢當(dāng)前集群狀態(tài)
kubectlgetpo-A|greprke2-metrics-server-5b987d776b-gqxv9

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

至此，rke2 單節(jié)點(diǎn)服務(wù)啟動(dòng)完成，但我們的目標(biāo)是 containerd，接下來繼續(xù)操作：

#配置containerd相關(guān)環(huán)境變量
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 詳情中的網(wǎng)絡(luò)部分內(nèi)容，并對(duì) containerd 進(jìn)行重啟，對(duì)問題進(jìn)行重現(xiàn)：

#查詢metrics-serverpod的詳情
crictlinspectpbfad445917423|jq.status.network

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

#停止rke2-server服務(wù)并單獨(dú)啟動(dòng)containerd，避免kubelet影響重現(xiàn)結(jié)果
systemctlstoprke2-server
#單獨(dú)啟動(dòng)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 運(yùn)行狀態(tài)

crictlpods|greprke2-metrics-server

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

#再次查詢metrics-serverpod詳情
crictlinspectpbfad445917423|jq.status.network

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

從最后的返回結(jié)果可以看出，containerd 重啟后容器的 IP 丟失。

通過在上述例子中重啟 rke2-server 可以看到，由于 ip 信息丟失，導(dǎo)致了業(yè)務(wù)容器被重建，帶來了業(yè)務(wù)中斷的風(fēng)險(xiǎn)。

#在中斷containerd進(jìn)程后，重啟rke2-server進(jìn)程(以下數(shù)據(jù)為重新驗(yàn)證后的數(shù)據(jù))
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 發(fā)生了重啟，在 crictl pods 返回中可以看到重新創(chuàng)建的 pods。

下載新版本 containerd，這次驗(yàn)證使用 k3s-containerd v1.6.14+k3s1。該版本為 Rancher 在 containerd v1.6.15 發(fā)布前緊急發(fā)布的修復(fù)補(bǔ)丁版本。

#拉取新鏡像
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

#關(guān)閉當(dāng)前運(yùn)行的容器
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

#啟動(dòng)rke2
systemctlstartrke2-server
#此時(shí)使用crictl查詢新的metrics-serverpod
crictlpods|grep"Ready"|grepmetrics-server
#ad8b101f819df3minutesagoReadyrke2-metrics-server-5b987d776b-gqxv9kube-system1(default)

#停止rke2并使用命令行啟動(dòng)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 運(yùn)行狀態(tài)

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

可以看到 containerd 重啟后，pod ip 沒有丟失。

RKE2 以下版本受該 issue 影響：

• v1.23.15+rke2r1

• v1.24.9+rke2r1

• v1.25.5+rke2r1

• v1.26.0+rke2r1

該 issue 在 2022 年 12 月 20 日被提交，RKE2 團(tuán)隊(duì)在 2023 年 1 月 6 日緊急合并了 containerd 中修復(fù)該 issue 的 commit，發(fā)布了 k3s-containerd v1.6.14+k3s1 版本，并發(fā)布了新的 rke2 rc 版本進(jìn)行測(cè)試驗(yàn)證。

最終在 1 月 11 日，RKE2 團(tuán)隊(duì)發(fā)布以下已經(jīng)修復(fù) containerd 問題的版本：

• v1.23.16+rke2r1

• v1.24.9+rke2r2

• v1.25.5+rke2r2

• v1.26.0+rke2r2

RFO 是 Rancher For openEuler 的縮寫，顧名思義，目的在于面向 openEuler 打造 Rancher 基礎(chǔ)平臺(tái)。

由于 RFO 版本發(fā)布周期在 RKE2 之后，RFO 并沒有受到該 issue 影響，并在近期發(fā)布了以下版本：

• 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

由于操作系統(tǒng)的軟件包發(fā)布存在一定的時(shí)間延后性，在大部分情況下都無法及時(shí)修復(fù)軟件出現(xiàn)的問題。像 CVE、功能缺陷等問題都比較緊急，等待操作系統(tǒng)供應(yīng)商提供修復(fù)版本將是一個(gè)漫長(zhǎng)的過程，甚至有時(shí)候由于一些限制，操作系統(tǒng)提供商無法提供新版本的軟件包，這會(huì)給系統(tǒng)運(yùn)行帶來不確定因素。

在這種情況下，將軟件自身依賴的組件打包到自己的 rootfs 中進(jìn)行分發(fā)，能更好地對(duì)其進(jìn)行管理和升級(jí)，避免給系統(tǒng)運(yùn)行帶來風(fēng)險(xiǎn)以及潛在的損失。