Kubernetes（1.31 到 1.35）集群、CRI containerd（1.7 到 2.3）升级流程与问题记录

引言Kubernetes 作为云原生生态的核心编排平台，其版本演进速度极快。从 1.31 到 1.35 版本，社区引入了多项重要特性，如改进的调度器、增强的存储 CSI 支持以及更精细的安全策略。同时，作为容器运行时接口（CRI）的默认实现，containerd 从 1.7 升级到 2.3 版本，带来了性能优化和 API 变更。本文基于实际生产环境升级经验，详细记录从 Kubernetes 1.31 到 1.35 及 containerd 1.7 到 2.3 的升级流程，并深入剖析关键原理与常见问题。## 升级前的准备与原理剖析### 版本兼容性矩阵在升级前，必须理解 Kubernetes 与 containerd 的版本兼容性。Kubernetes 1.31 要求 containerd >= 1.6.0，而 1.35 则要求 containerd >= 2.0。升级过程中，建议遵循“先升级 containerd，再升级 Kubernetes”的顺序，因为 Kubernetes 新版本依赖 containerd 的新 API 特性。### 关键原理：Kubelet 与 CRI 的交互Kubelet 通过 CRI 接口调用 containerd 的 gRPC 服务（默认监听 /run/containerd/containerd.sock）。升级后，Kubelet 可能调用新版本的 CRI API（如 v1alpha2 或 v2），containerd 必须支持对应版本。例如，containerd 2.0 废弃了 v1alpha2 API，仅保留 v2 API，因此 Kubernetes 1.35 必须使用支持 v2 的 containerd 配置。## 升级流程详解### 1. 升级 containerd 从 1.7 到 2.3#### 步骤 1：备份现有配置bash# 备份 containerd 配置和状态文件cp /etc/containerd/config.toml /etc/containerd/config.toml.baksystemctl stop containerd#### 步骤 2：安装新版本 containerdbash# 以 Ubuntu 20.04 为例，添加 containerd 官方仓库curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -sudo add-apt-repository "deb https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"sudo apt-get updatesudo apt-get install containerd.io=2.3.0-1#### 步骤 3：配置 containerd 支持 v2 CRI APIbash# 编辑 /etc/containerd/config.toml，关键配置如下cat > /etc/containerd/config.toml << 'EOF'version = 2[plugins."io.containerd.grpc.v1.cri"] # 启用 v2 API（默认已启用） disable_cri = false # 设置 sandbox 镜像（必须与 Kubernetes 版本匹配） sandbox_image = "registry.k8s.io/pause:3.9"[plugins."io.containerd.grpc.v1.cri".containerd] default_runtime_name = "runc"[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] runtime_type = "io.containerd.runc.v2" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = trueEOFsystemctl restart containerd#### 步骤 4：验证 containerd 版本bash# 检查 containerd 版本和 CRI API 支持containerd --versioncrictl version# 输出示例：# containerd github.com/containerd/containerd v2.3.0# RuntimeName: containerd, RuntimeVersion: 2.3.0, RuntimeApiVersion: v2### 2. 升级 Kubernetes 从 1.31 到 1.35#### 步骤 1：逐版本升级（1.31 -> 1.32 -> 1.33 -> 1.34 -> 1.35）bash# 以升级到 1.32 为例，使用 kubeadmkubeadm upgrade plan --node-name master1kubeadm upgrade apply v1.32.0 --etcd-upgrade=false# 升级 kubelet 和 kubectlapt-get install -y kubelet=1.32.0-00 kubectl=1.32.0-00systemctl restart kubelet#### 步骤 2：处理 containerd 与 kubelet 的兼容性问题在升级到 1.35 时，可能遇到 kubelet 无法连接 containerd 的 v1alpha2 API。解决方案是确保 containerd 配置中只启用 v2 API，并重启服务。python#!/usr/bin/env python3# 示例：自动检测 containerd 配置中的 API 版本import configparserdef check_cri_api_version(config_path="/etc/containerd/config.toml"): """检查 containerd 配置中的 CRI API 版本设置""" config = configparser.ConfigParser() config.read(config_path) try: # 读取 version 字段 version = config.get('plugins."io.containerd.grpc.v1.cri"', 'version', fallback='v2') print(f"当前 CRI API 版本: {version}") if version != 'v2': print("警告：建议升级到 v2 API 以兼容 Kubernetes 1.35") return False return True except Exception as e: print(f"配置解析错误: {e}") return Falseif __name__ == "__main__": check_cri_api_version()#### 步骤 3：验证集群状态bash# 检查节点状态和组件版本kubectl get nodes -o widekubectl version --short# 输出示例：# Client Version: v1.35.0# Server Version: v1.35.0# 所有节点 Ready 状态## 问题记录与解决方案### 问题 1：Kubelet 启动失败，报错“Failed to get sandbox image”现象：升级 containerd 后，kubelet 日志显示 failed to get sandbox image "registry.k8s.io/pause:3.8"。 原因：containerd 2.0 要求 sandbox 镜像版本 >= 3.9，而旧配置中使用了 3.8。 解决方案：更新配置中的 sandbox_image 为 registry.k8s.io/pause:3.9，并重启 containerd。### 问题 2：Pod 创建失败，提示“rpc error: code = Unimplemented”现象：使用 crictl runp 创建 pod 时失败，错误信息包含 runtime v1alpha2 not supported。 原理：containerd 2.3 默认仅支持 v2 CRI API，而某些旧客户端（如旧版 crictl）仍调用 v1alpha2。 解决方案：升级 crictl 至最新版本，或设置环境变量 CONTAINER_RUNTIME_ENDPOINT 指向 v2 socket。bash# 升级 crictl 并测试crictl version# 输出应显示 RuntimeApiVersion: v2crictl pods### 问题 3：kubeadm upgrade apply 超时现象：升级过程中 kubeadm upgrade apply 卡在“Waiting for control plane to be ready”并超时。 原因：etcd 集群在升级过程中出现 leader 选举延迟。 解决方案：手动重启 etcd 或增加 --etcd-upgrade=true 参数让 kubeadm 自动处理。## 总结从 Kubernetes 1.31 到 1.35 及 containerd 1.7 到 2.3 的升级，本质上是 API 版本迁移和依赖关系更新的过程。核心要点包括： 1. 版本兼容性：遵循“containerd 先升级，Kubernetes 后升级”的顺序，确保 CRI API 版本匹配。 2. 配置更新：containerd 2.0+ 废弃了 v1alpha2 API，必须配置 v2 API 并更新 sandbox 镜像。 3. 逐版本升级：Kubernetes 不支持跨主要版本直接升级，需按 1.31→1.32→…→1.35 逐步操作。 4. 问题排查：遇到错误时优先检查 kubelet 和 containerd 日志（journalctl -u kubelet 和 journalctl -u containerd），定位到具体的 API 不兼容或配置错误。通过遵循上述流程和原理，可以平稳完成升级，同时避免生产环境的中断。未来，随着 Kubernetes 和 containerd 的持续演进，类似的升级策略将保持适用——核心是理解 API 层的变化和组件间的依赖关系。