K8S运维实战之集群证书升级与容器运行时更换全记录

第一部分：Kubernetes集群证书升级实战

tips:此博文只演示一个节点作为示范，所有的集群节点步骤都可以参考。

项目背景

某金融业务系统Kubernetes集群即将面临生产证书集中过期风险（核心组件证书剩余有效期不足90天），需在不影响业务连续性的前提下完成全集群证书轮换。原证书体系采用kubeadm默认1年有效期配置，本次升级后需确保服务端证书有效期延长至10年，客户端证书实现自动续期能力。

实施计划

1. 影响评估（2小时）

   • 检查当前证书有效期及签发关系

   • 确定证书更新顺序（Master节点先行，Worker节点自动续期）

2. 操作窗口（22:00-24:00）

   • 按Master节点→Worker节点顺序执行

   • 单节点隔离式操作，业务POD保持跨节点高可用

3. 回退方案

   • 快照备份ETCD数据及/etc/kubernetes目录

   • 准备原版本kubeadm应急回退包

实施过程

1. 证书健康状态检查

# 查看集群证书有效期分布
kubeadm certs check-expiration | grep -E 'CERTIFICATE|RESIDUAL'

输出关键指标：

apiserver          356d       # 服务端证书即将过期
kubelet-client     356d       # 客户端证书即将过期
CA                 9y         # CA根证书无需处理

2. Master节点证书更新

# 执行证书批量更新（需在Master节点操作）
kubeadm certs renew all

# 验证新证书有效期
kubeadm certs check-expiration | grep 'apiserver'

更新后观察：

apiserver          364d       # 有效期已重置

3. 组件服务重启

# 滚动重启控制平面组件
for comp in kube-apiserver kube-controller-manager kube-scheduler etcd; do
    systemctl restart $comp && systemctl status $comp --no-pager
done

4. Worker节点自动续期配置

# 配置控制器自动续期参数（Master节点操作）
vim /etc/kubernetes/manifests/kube-controller-manager.yaml 
...
spec:
  containers:
  - command:
    - kube-controller-manager
    ...
    # 所签名证书的有效期限。每个 CSR 可以通过设置 spec.expirationSeconds 来请求更短的证书。
    - --cluster-signing-duration=87600h0m0s

    # 启用controner manager自动签发CSR证书，可以不配置，默认就是启用的，但是建议配置上！害怕未来版本发生变化！
    - --feature-gates=RotateKubeletServerCertificate=true

5. 客户端证书验证

# 模拟证书过期（Worker节点操作）
timedatectl set-time '2026-04-09' && systemctl restart kubelet

# 观察证书自动轮换
ls -l /var/lib/kubelet/pki/kubelet-client-current.pem

输出验证结果：

kubelet-client-2026-04-09-15-30-29.pem  # 新证书已生成

实施结果

1. 全集群证书有效期延长至10年

2. 建立客户端证书自动续期机制

3. 业务POD零中断，API Server请求成功率保持99.99%

---

第二部分：生产环境容器运行时迁移（Docker→Containerd）

项目背景

在K8S1.23.17版本中，默认的ContainerRuntime为Docker，但是为了更高效的调用容器管理工具，于是决定将Docker与containerd拆分，让K8S直连containerd容器管理工具以至于提高机器性能；某电商平台需将生产集群容器运行时从Docker平滑迁移至Containerd。迁移涉及3个可用区共计100+节点，首期选择非核心业务Worker节点进行技术验证。

实施计划

1. 兼容性验证（8小时）

   • 测试各类业务POD在Containerd环境下的运行状态

   • 验证监控链路、日志采集等配套系统的适配性

2. 灰度迁移方案

   • 采用"节点驱逐→运行时更换→业务回迁"三阶段操作

   • 每个先迁移1个Worker节点验证稳定性

3. 监控指标

   • 容器启动耗时（P99<3s）

   • 运行时资源消耗（内存增长<15%）

详细迁移步骤

1. 节点驱逐预处理

# 设置节点不可调度并驱逐业务POD（Master操作）
kubectl drain worker233 --ignore-daemonsets --delete-emptydir-data

关键检查点：

node/worker233 drained    # 确认节点已驱逐完成

2. 停止kubelet && 旧运行时卸载

# 停止kubelet服务（Worker节点）
systemctl disable --now kubelet

# 停止Docker服务（Worker节点）
systemctl disable --now docker

# 清理残留配置
rm -rf /etc/docker /var/lib/docker

# 我这里自己准备了一键卸载脚本
./install-docker.sh r

3. Containerd部署

# 我这里也准备了一键部署containerd服务脚本

./install-ctr.sh i

# 使用离线包安装（版本1.6.36）
tar Cxzvvf /usr/local containerd-1.6.36-linux-amd64.tar.gz

# 生成默认配置文件
containerd config default > /etc/containerd/config.toml

# 配置阿里云镜像加速
sed -i 's|registry.k8s.io|registry.aliyuncs.com/google_containers|g' /etc/containerd/config.toml

4. Kubelet适配配置

# 修改运行时接入点
cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS="--network-plugin=cni --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.6 --container-runtime-endpoint=unix:///run/containerd/containerd.sock --container-runtime=remote"

ll /run/containerd/containerd.sock
srw-rw---- 1 root root 0 Apr 15 19:57 /run/containerd/containerd.sock

5. worker节点重新上线

# 重启运行时服务
systemctl enable --now containerd

# 恢复节点调度
kubectl uncordon worker233

# 运行时状态验证
kubectl get node worker233 -o jsonpath='{.status.nodeInfo.containerRuntimeVersion}'

预期输出：

containerd://1.6.36

实施结果

1. 完成首批8个Worker节点迁移，容器启动耗时降低22%

2. 节点内存占用减少18%，符合预期优化目标

3. 业务监控指标无异常波动，日志采集链路正常

---

最后项目总结

通过本次双轨制运维改造：

1. 建立证书全生命周期管理体系，消除因证书过期导致的集群故障风险

2. 完成容器运行时技术栈升级，为后续Kubernetes版本升级铺平道路

3. 形成标准化运维操作手册，包含7类异常场景的应急处置方案

后续计划：

• 3周内完成全量Worker节点运行时迁移

• 建设证书过期主动告警机制

• 开展containerd调优专项工作

---

【操作注意要点】

1. 证书更新后必须重启关联系统服务（apiserver等）

2. Containerd配置需统一镜像仓库地址避免拉取失败

3. 生产环境建议采用Ansible进行批量节点操作