共计 5342 个字符，预计需要花费 14 分钟才能阅读完成。
作者简介
邓宇星，SUSE Rancher 中国区软件架构师，6 年云原生畛域教训，参加 Rancher 1.x 到 Rancher 2.x 版本迭代，目前负责 Rancher For openEuler(RFO) 我的项目开发。
最近咱们关注到一个对于 containerd 运行时的 issue，该问题在 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 装置镜像脚本，会从 aliyun OSS 下载 RKE2 资源
curl -sfL https://rancher-mirror.oss-cn-beijing.aliyuncs.com/rke2/install.sh | INSTALL_RKE2_MIRROR=cn INSTALL_RKE2_VERSION=v1.24.9+rke2r1 sh -
# [INFO] using v1.24.9-rke2r1 as release
# [INFO] downloading checksums at https://rancher-mirror.rancher.cn/rke2/releases/download/v1.24.9-rke2r1/sha256sum-amd64.txt
# [INFO] downloading tarball at https://rancher-mirror.rancher.cn/rke2/releases/download/v1.24.9-rke2r1/rke2.linux-amd64.tar.gz
# [INFO] verifying tarball
# [INFO] unpacking tarball file to /usr/local
# 启动 rke2 服务，并期待服务启动胜利
systemctl start rke2-server
# 配置 rke2 相干的 PATH 门路以及 kube-config 门路
export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
export PATH=/var/lib/rancher/rke2/bin:$PATH
# 应用 kubectl 查问以后集群状态
kubectl get po -A | grep rke2-metrics-server-5b987d776b-gqxv9
# kube-system rke2-metrics-server-5b987d776b-gqxv9 1/1 Running 0 15m至此，rke2 单节点服务启动实现，但咱们的指标是 containerd，接下来持续操作：
# 配置 containerd 相干环境变量
export CRI_CONFIG_FILE=/var/lib/rancher/rke2/agent/etc/containerd/config.toml CONTAINER_RUNTIME_ENDPOINT=unix:///var/run/k3s/containerd/containerd.sock
# 应用 crictl 查问 pods 以及 container 信息
crictl pods | grep rke2-metrics-server
# bfad445917423 18 minutes ago Ready rke2-metrics-server-5b987d776b-gqxv9 kube-system 0 (default)
crictl ps | grep rke2-metrics-server
# db5d6392a310e f6dc23a68f5fb 18 minutes ago Running metrics-server 0 bfad445917423 rke2-metrics-server-5b987d776b-gqxv9
咱们以 metrics-server 的 pod 为例，查问 pod 详情中的网络局部内容，并对 containerd 进行重启，对问题进行重现：
# 查问 metrics-server pod 的详情
crictl inspectp bfad445917423 | jq .status.network
# {# "additionalIps": [],
# "ip": "10.42.0.6"
# }
# 进行 rke2-server 服务并独自启动 containerd，防止 kubelet 影响重现后果
systemctl stop rke2-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 运行状态
crictl pods | grep rke2-metrics-server
# bfad445917423 24 minutes ago Ready rke2-metrics-server-5b987d776b-gqxv9 kube-system 0 (default)
# 再次查问 metrics-server pod 详情
crictl inspectp bfad445917423 | jq .status.network
# {# "additionalIps": [],
# "ip": ""
# }从最初的返回后果能够看出，containerd 重启后容器的 IP 失落。
问题影响
通过在上述例子中重启 rke2-server 能够看到，因为 ip 信息失落，导致了业务容器被重建，带来了业务中断的危险。
# 在中断 containerd 过程后，重启 rke2-server 过程(以下数据为从新验证后的数据)
systemctl restart rke2-server
kubectl get po -A |grep rke2-metrics-server-5b987d776b-8vg69
# kube-system rke2-metrics-server-5b987d776b-8vg69 1/1 Running 2 (115s ago) 23m
crictl pods | grep rke2-metrics-server
# caba6d8d15823 41 seconds ago Ready rke2-metrics-server-5b987d776b-8vg69 kube-system 1 (default)
# 2dec6a11fd36f 22 minutes ago NotReady rke2-metrics-server-5b987d776b-8vg69 kube-system 0 (default)能够看到，在 rke2-server 重启后，应用了 cni 的 pod 产生了重启，在 crictl pods 返回中能够看到从新创立的 pods。
问题修复验证
下载新版本 containerd，这次验证应用 k3s-containerd v1.6.14+k3s1。该版本为 Rancher 在 containerd v1.6.15 公布前紧急公布的修复补丁版本。
# 拉取新镜像
docker pull rancher/hardened-containerd:v1.6.14-k3s1-build20230105
mkdir container-new
cd container-new
# 从镜像中获取新版本 containerd
docker run --rm -it -v ${PWD}:/output rancher/hardened-containerd:v1.6.14-k3s1-build20230105 cp -r /usr/local/bin /output
./output/bin/containerd --version
# containerd github.com/k3s-io/containerd v1.6.14-k3s1 6f9c63d571f5026e85a0768f0f2ef03d1c8dbc6e
# 敞开以后运行的容器
pkill -f /var/lib/rancher/rke2/data/v1.24.9-rke2r1-d4d8faf800d0/bin/containerd-shim-runc-v2
# 替换 containerd binary 版本
cp ./bin/* /var/lib/rancher/rke2/bin
/var/lib/rancher/rke2/bin/containerd --version
# containerd github.com/k3s-io/containerd v1.6.14-k3s1 6f9c63d571f5026e85a0768f0f2ef03d1c8dbc6e
# 启动 rke2
systemctl start rke2-server
# 此时应用 crictl 查问新的 metrics-server pod
crictl pods | grep "Ready" |grep metrics-server
# ad8b101f819df 3 minutes ago Ready rke2-metrics-server-5b987d776b-gqxv9 kube-system 1 (default)
# 进行 rke2 并应用命令行启动 containerd
systemctl stop rke2-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 运行状态
crictl inspectp ad8b101f819df | 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 中进行散发，能更好地对其进行治理和降级，防止给零碎运行带来危险以及潜在的损失。
对于 RFO 的我的项目阐明和部署应用，请点击《Rancher RFO 正式 GA》。
