16.2.5 集群升级、备份与恢复策略

集群升级、备份与恢复策略#

升级策略与原则#

  • 版本规划：遵循控制平面与节点不超过±1小版本；提前核对废弃特性与API变更。
  • 升级路径：小版本逐级升级，避免跨多版本跳跃；同步确认CNI/CSI/Ingress兼容性。
  • 风险评估：盘点关键负载、SLA、HPA与PDB配置，确认可承受的中断窗口。
  • 变更窗口：低峰执行，确保回滚方案与应急联系人到位。

原理草图（升级/回滚路径）

文章图片

升级流程（kubeadm示例）#

前置检查与准备（示例包含命令说明）

# 1) 检查节点与版本信息
kubectl get node -o wide
# 预期：所有节点 Ready，版本与目标版本差距不超过1小版本

# 2) 查看当前kubeadm版本与升级可用路径
kubeadm version
kubeadm upgrade plan
# 预期：输出可升级的目标版本与组件版本信息

# 3) 检查etcd健康（控制平面节点执行）
export ETCDCTL_API=3
etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
  --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
  endpoint health
# 预期：healthy

升级控制平面

# 1) 选择目标版本（示例 v1.27.4）
kubeadm upgrade apply v1.27.4

# 2) 更新kubelet与kubectl（以Ubuntu为例）
apt-get update
apt-get install -y kubelet=1.27.4-00 kubectl=1.27.4-00
systemctl daemon-reload
systemctl restart kubelet

# 3) 验证控制平面组件版本
kubectl -n kube-system get pod -o wide

滚动升级工作节点

# 1) 逐台维护：禁止调度并驱逐Pod
kubectl cordon node-1
kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data

# 2) 更新kubelet/kubeadm并执行节点升级
apt-get install -y kubelet=1.27.4-00 kubeadm=1.27.4-00
kubeadm upgrade node

# 3) 重启kubelet并恢复调度
systemctl restart kubelet
kubectl uncordon node-1

插件与附加组件升级

# 以CoreDNS为例，拉取新版本镜像并更新Deployment
kubectl -n kube-system set image deployment/coredns \
  coredns=registry.k8s.io/coredns/coredns:v1.10.1

# 检查Pod滚动状态
kubectl -n kube-system rollout status deployment/coredns

排错要点

# 1) kubelet无法启动
journalctl -u kubelet -n 100 --no-pager

# 2) API Server不可用
kubectl get --raw=/healthz
# 若失败，检查 /etc/kubernetes/manifests/ 中静态Pod配置

# 3) 组件镜像拉取失败
crictl images
crictl pull registry.k8s.io/kube-apiserver:v1.27.4

回滚与容灾准备#

  • 回滚条件：升级后控制平面异常、API不可用、关键业务不可恢复。
  • 回滚手段：
  • 回退控制平面镜像与静态Pod配置
  • 恢复etcd快照
  • 节点版本回退并重新加入集群

回滚示例（控制平面静态Pod）

# 1) 修改 /etc/kubernetes/manifests/kube-apiserver.yaml
# 将 image: registry.k8s.io/kube-apiserver:v1.27.4 回退到 v1.26.x
sed -i 's/v1.27.4/v1.26.8/g' /etc/kubernetes/manifests/kube-apiserver.yaml

# 2) kubelet会自动重启静态Pod
kubectl -n kube-system get pod -l component=kube-apiserver

备份策略#

  • 备份对象：etcd快照、控制平面配置、关键资源、PV数据快照。
  • 备份频率：etcd每日全量+变更前快照；资源清单每日导出。

etcd快照备份（含路径与预期）

# 备份目录
mkdir -p /backup/etcd

# 执行快照
export ETCDCTL_API=3
etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
  --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
  snapshot save /backup/etcd/etcd-$(date +%F).db

# 校验快照
etcdctl snapshot status /backup/etcd/etcd-$(date +%F).db

资源清单备份

# 导出全量资源（可用于恢复）
kubectl get all -A -o yaml > /backup/cluster-resources-$(date +%F).yaml
kubectl get crd -o yaml > /backup/crd-$(date +%F).yaml

恢复策略#

etcd恢复（示例步骤）

# 1) 停止控制平面组件（静态Pod由kubelet管理）
systemctl stop kubelet

# 2) 恢复快照到新数据目录
export ETCDCTL_API=3
etcdctl snapshot restore /backup/etcd/etcd-2024-01-01.db \
  --data-dir /var/lib/etcd-from-backup

# 3) 修改 /etc/kubernetes/manifests/etcd.yaml
# 将 --data-dir=/var/lib/etcd 改为 /var/lib/etcd-from-backup

# 4) 启动kubelet
systemctl start kubelet

资源恢复顺序

# 先恢复CRD，再恢复业务资源
kubectl apply -f /backup/crd-2024-01-01.yaml
kubectl apply -f /backup/cluster-resources-2024-01-01.yaml

最佳实践#

  • 使用PDB保障升级期间最小可用实例数。
  • 控制平面节点保持奇数个并启用etcd多节点高可用。
  • 统一日志与审计，确保回溯能力。
  • 严格遵循版本兼容矩阵与灰度升级策略。

练习与自测#

  1. 升级演练：在测试集群执行kubeadm upgrade plan并完成一次小版本升级。
  2. 故障演练：模拟CoreDNS升级失败，使用rollout undo回退。
  3. 备份与恢复：完成一次etcd快照备份并在测试环境恢复。
  4. 命令理解：解释cordon、drain、uncordon三者差异与使用场景。