Kubernetes 1.34 升级 1.35 踩坑：一个废弃参数让 kubelet 重启 40 次

近日见闻

这几天应该有很多打工人已经踏上返乡的旅途了吧，一转眼就马上要过年了。

最近AI模型都在不断发布新版本，2月11日晚智谱新模型GLM-5发布，网传DeepSeek将在今年2月中旬农历新年期间推出新一代旗舰AI模型DeepSeek V4,MiniMaxM2.5模型也即将正式上线，真是百花齐放，都用不过来了！直接看下模型以及工具排行榜

提前祝各位马年快乐，一切顺利！

Kubernetes 1.35 升级：kubelet 启动失败踩坑记

前几天 Kubernetes 集群从 1.34.0 到 v1.35.0 时，遇到了一个意想不到的问题，kubelet 服务启动不了，反复重启了 40 多次...

可是我是按照官方升级流程来的啊，到底怎么回事？具体的命令行各位直接看官方文档，这里不详细展示了，主要分享下遇到的问题及解决方案。

https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/cluster-upgrade/

现象是这样的

升级完 kubelet 到 v1.35.0 后，工作节点一直无法加入集群：

$ systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
   Active: activating (auto-restart) (Result: exit-code)
  Process: 43236 ExecStart=/usr/local/bin/kubelet (code=exited, status=1/FAILURE)

服务一直在自动重启，启动次数已经达到 40+ 次

关键错误信息

查看日志发现这么一行：

E0205 22:45:35.937433   43236 run.go:72] "command failed" err="failed to parse kubelet flag: unknown flag: --pod-infra-container-image"

unknown flag: --pod-infra-container-image - 这是什么鬼？

排查过程

第一步：检查配置文件

先看看 kubeadm 的配置文件：

$ cat /etc/kubernetes/kubeadm-config.yaml

发现里面有这段配置：

nodeRegistration:
  criSocket: unix:///var/run/containerd/containerd.sock
  kubeletExtraArgs:
    - name: cgroup-driver
      value: systemd
    - name: pod-infra-container-image  # 这个参数！
      value: "registry.k8s.io/pause:3.10.1"

找到了！就是这个 pod-infra-container-image 参数

第二步：修复

既然都unknown了，看起来这个参数已经废弃了，直接删除它：

nodeRegistration:
  criContainerRuntime: /var/run/containerd/containerd.sock
  kubeletExtraArgs:
    - name: cgroup-driver
      value: systemd

重启 kubelet...

结果：问题依然存在...

第三步：分析

为什么修改了配置文件，问题还在呢？

经过一番研究，发现了关键：

kubeadm 的配置文件不会直接被 kubelet 读取！

实际流程是这样的：

1. kubeadm join 阶段
   ├─ 读取 kubeadm-config.yaml
   └─ 生成 kubeadm-flags.env（这才是实际传给 kubelet 的参数）

2. kubelet 启动阶段
   ├─ systemd 读取 kubeadm-flags.env
   └─ 将参数传递给 kubelet 进程

虽然修改了 kubeadm-config.yaml，但 kubeadm-flags.env 还是旧的！

第四步：找到真凶

$ cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS="--pod-infra-container-image=registry.k8s.io/pause:3.10.1 ..."

里面果然还包含那个废弃的参数！

问题根源

为什么会出现这个问题？

这就涉及到 Kubernetes 的历史了：

时间线

关键事件

Kubernetes 1.24（2022年5月）是一个重要的里程碑：

• • 正式移除了 dockershim
• • --pod-infra-container-image 随之一起被移除
• • 容器运行时（containerd/CRI-O）自动处理 pause 容器

为什么会有这个问题？

kubeadm 和 kubelet 对废弃参数的处理策略不同：

• • kubeadm：为了向后兼容，可能接受旧参数配置
• • kubelet：严格验证，遇到废弃参数直接拒绝

这导致了"宽松输入，严格处理"的问题

官方更新日志

查看 Kubernetes 1.35 的官方发布说明，了解最新的变更和改进：

• • Kubernetes 1.35.0 Release Notes[1] - 官方发布说明
• • Kubernetes v1.35 Sneak Peek[2] - 官方博客前瞻
• • Kubernetes Releases[3] - 版本发布历史

解决方案

快速修复

直接删除包含旧参数的配置文件，让 kubeadm 重新生成：

# 1. 删除旧配置
sudo rm /var/lib/kubelet/kubeadm-flags.env

# 2. 重新加载 systemd 配置
sudo systemctl daemon-reload

# 3. 重启 kubelet
sudo systemctl restart kubelet

# 4. 验证状态
sudo systemctl status kubelet

搞定！kubelet 正常启动了

其他方案

如果想手动修改：

# 编辑文件
sudo vi /var/lib/kubelet/kubeadm-flags.env

# 删除 --pod-infra-container-image 参数
# 保留其他有效参数

推荐升级流程

1. 准备阶段
   ├─ 阅读新版本 Release Notes
   ├─ 检查兼容性
   ├─ 备份配置
   └─ 测试环境验证

2. 升级控制平面
   ├─ 升级 kubeadm
   ├─ 执行 upgrade plan
   └─ 升级控制平面组件

3. 升级工作节点（逐个进行）
   ├─ Drain 节点
   ├─ 升级组件
   ├─ 重启 kubelet
   └─ 验证状态

4. 验证阶段
   ├─ 检查所有节点
   ├─ 验证 Pod 状态
   └─ 测试应用功能

知识点

Pause 容器是什么？

每个 Pod 启动时会先启动一个特殊的"基础容器"（pause container），它的作用是：

• • 设置 Pod 的网络命名空间
• • 设置 PID 命名空间
• • 为同一 Pod 中的所有容器共享这些命名空间

容器启动后进入"暂停"状态，只负责持有命名空间，不运行实际应用

CRI 时代的变化

dockershim 时代：

--pod-infra-container-image=registry.k8s.io/pause:3.10.1

CRI 时代：

• • 不需要指定参数
• • 容器运行时自动处理

containerd 配置示例

如果要自定义 pause 镜像：

# /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.10.1"

预防措施

升级前检查清单

1. 检查当前版本

kubectl version
kubelet --version
kubeadm version

2. 阅读版本变更日志

• • 关注弃用的 API
• • 关注移除的功能
• • 关注行为变更

3. 检查配置文件

cat /etc/kubernetes/kubeadm-config.yaml
sudo cat /var/lib/kubelet/kubeadm-flags.env

4. 搜索废弃参数

grep -r "pod-infra-container-image" /etc/kubernetes/ /var/lib/kubelet/
grep -r "network-plugin" /etc/kubernetes/ /var/lib/kubelet/

5. 备份配置

sudo cp -r /etc/kubernetes /etc/kubernetes.backup.$(date +%Y%m%d)

常见问题

Q1: 如何确认当前使用的容器运行时？

# 方法 1：查看 kubelet 日志
sudo journalctl -u kubelet | grep "Container runtime"

# 方法 2：查看节点详情
kubectl describe node <node-name> | grep "Container Runtime Version"

# 方法 3：查看进程
ps aux | grep containerd

Q2: 升级后 kubelet 无法启动，可能还有什么问题？

除了 --pod-infra-container-image，还可能遇到：

• • --network-plugin（已移除）
• • --cgroup-driver（已废弃）
• • 配置文件格式不兼容
• • 依赖问题

Q3: 如何自定义 pause 镜像？

在容器运行时配置中指定：

# 修改 containerd 配置
sudo vi /etc/containerd/config.toml

# 添加或修改
[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "your-registry.com/pause:3.10.1"

# 重启 containerd
sudo systemctl restart containerd

总结

核心问题

1. 1. Kubernetes 1.24 移除了 dockershim
2. 2. --pod-infra-container-image 参数随之被移除
3. 3. kubeadm 可能生成了包含废弃参数的配置
4. 4. kubelet 严格验证参数导致启动失败

关键学习点

理解版本兼容性

• • 各组件对废弃参数的处理策略可能不同
• • 需要同时升级所有组件

理解配置文件机制

• • kubeadm-config.yaml 是 kubeadm 的配置
• • kubeadm-flags.env 是实际传给 kubelet 的参数

升级最佳实践

• • 升级前仔细阅读 Release Notes
• • 在测试环境先验证
• • 备份配置和数据

经验教训

不要假设向后兼容

• • 虽然大版本号相同，minor 版本可能有重大变更
• • 每次升级都需要详细检查变更日志

系统化的排查流程

• • 从日志开始
• • 检查配置文件
• • 理解组件工作机制

配置管理的必要性

• • 使用版本控制管理配置
• • 定期审计配置
• • 自动化检测废弃参数

参考资源

官方文档

• • Kubernetes 官网[4]
• • kubeadm 升级指南[5]
• • Dockershim 迁移指南[6]
• • Kubernetes 1.35.0 Release Notes[1]
• • Kubernetes v1.35 Sneak Peek[2]

社区资源

• • Kubernetes 博客[7]
• • Kubernetes Slack[8]
• • Kubernetes 论坛[9]

工具推荐

• • Pluto[10] - Kubernetes 废弃 API 检查工具
• • kube-bench[11] - CIS 基准检查

以上就是希里安升级集群中遇到的问题分享，那么你在 Kubernetes 升级过程中遇到过什么坑？欢迎在评论区分享你的经验！

如果这篇文章对你有帮助，别忘了 点赞、在看、转发 三连哦～

关注希里安，获取更多 Kubernetes 运维实战经验！

引用链接

[1] Kubernetes 1.35.0 Release Notes: https://github.com/kubernetes/kubernetes/releases/tag/v1.35.0 [2] Kubernetes v1.35 Sneak Peek: https://kubernetes.io/blog/2025/11/26/kubernetes-v1-35-sneak-peek/ [3] Kubernetes Releases: https://kubernetes.io/docs/setup/release/ [4] Kubernetes 官网: https://kubernetes.io/ [5] kubeadm 升级指南: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/ [6] Dockershim 迁移指南: https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/ [7] Kubernetes 博客: https://kubernetes.io/blog/ [8] Kubernetes Slack: https://slack.k8s.io/ [9] Kubernetes 论坛: https://discuss.kubernetes.io/ [10] Pluto: https://github.com/FairwindsOps/pluto [11] kube-bench: https://github.com/aquasecurity/kube-bench