centos k8s迁移指南 - 问答

CentOS 上 Kubernetes 迁移指南

一迁移方式与适用场景

原地升级：在同一套节点上用 kubeadm 逐步升级 Kubernetes 版本，适用于希望保留现有节点与拓扑、降低一次性变更风险的场景。升级需按“控制面 → 工作节点”的顺序，且一般不允许跨多个大版本直接升级，需要逐小版本递进。
重建迁移：在新环境（物理机/虚拟机/云上）新建目标集群，通过 Velero 备份与恢复集群资源与持久卷快照，实现跨机房、跨云或跨版本的迁移，业务切换更可控。
节点迁移：在集群内部将工作负载从旧节点平滑迁移到新节点，常用于硬件更换、扩容缩容或内核/系统升级，配合 cordon/drain/uncordon 完成蓝绿替换。

二原地升级步骤 kubeadm

准备与版本规划
- 备份关键数据与清单：如 /etc/kubernetes、证书、关键 etcd 快照（如使用外部 etcd 则按实际备份策略执行）。
- 规划版本路径：遵循“每次仅升级到下一个小版本”的原则，不能跨段升级（例如 1.19.x → 1.21.y 不合法，需先到 1.20.y 再到 1.21.y）。
控制面节点升级
- 将节点置为维护状态：kubectl drain --ignore-daemonsets。
- 升级 kubeadm 并验证升级计划：例如 yum install -y kubeadm-1.28.2-0；执行 kubeadm upgrade plan 查看可升级版本。
- 执行升级：kubeadm upgrade apply v1.28.2。
- 升级 kubelet/kubectl 并重启：yum install -y kubelet-1.28.2-0 kubectl-1.28.2-0；systemctl daemon-reload && systemctl restart kubelet。
- 恢复调度：kubectl uncordon 。
工作节点升级
- 逐节点执行：先 cordon/drain，再升级 kubelet/kubectl 并重启，最后 uncordon。
- 验证：kubectl get nodes 与 kubectl get pods -A 检查状态与可用性。
注意事项
- 升级顺序严格为“控制面 → 工作节点”，每次只升到下一个小版本，避免跨段升级。
- 升级窗口内合理设置 Pod 中断预算（PDB），避免核心服务不可用。

三重建迁移步骤 Velero

前置准备
- 在源集群安装 Velero（建议使用对象存储如 MinIO/S3 作为备份后端），准备访问凭证文件（如 credentials-velero）。
- 在目标集群创建同版本的 Kubernetes 集群，确保网络插件、存储类等关键配置与源集群一致或兼容。
备份与恢复
- 备份：创建全量或指定命名空间的备份，例如 velero backup create my-backup；可按需包含持久卷快照。
- 恢复：在目标集群安装 Velero 后执行 velero restore create --from-backup my-backup 恢复资源与卷数据。
- 观察与回滚：关注恢复进度与事件，必要时基于备份快速回滚。
适用场景与要点
- 适合跨云/跨机房/跨版本的迁移，业务切换更平滑，可灰度与分批恢复。
- 有状态应用需确保存储类与底层存储兼容；备份/恢复期间注意 IO 负载 与节点资源压力。

四节点迁移步骤集群内蓝绿替换

逐节点替换
- 将旧节点置为维护：kubectl cordon 。
- 驱逐工作负载：kubectl drain --ignore-daemonsets --force。
- 下线旧节点：如需从集群移除，执行 kubectl delete node （可选）。
- 在新节点上安装与源集群一致的 kubelet/kubeadm 配置，加入集群（如使用 kubeadm，执行 kubeadm join …）。
- 打上角色标签（如需要）：kubectl label node node-role.kubernetes.io/worker=worker。
- 恢复调度：kubectl uncordon ，检查 kubectl get nodes 与 kubectl get pods -A。
适用场景与要点
- 适合硬件更换、内核/系统升级、节点规格调整等场景，对业务影响可控。
- 保持 Kubernetes/Docker/容器运行时 版本一致，避免版本漂移导致调度或兼容性问题。

五迁移前后检查清单

0 赞

0 踩