K8s物理机如何实现不停机迁移？

Kubernetes物理机在线迁移：原理、方案与实战指南

在物理机环境中运行Kubernetes集群时，硬件维护、升级或故障场景下，物理节点的在线迁移成为保障业务连续性的关键技术，与虚拟机不同，物理机迁移涉及更底层的硬件操作,需结合Kubernetes特性实现无缝过渡。

为何物理机迁移更具挑战？

• 无虚拟化层支撑：缺乏Hypervisor的实时迁移能力
• 硬件强耦合：直通设备（GPU/RDMA）需特殊处理
• 状态保持难题：持久化存储与网络会话的连续性

核心迁移方案及原理

方案1：Pod驱逐+节点维护（标准方案）

# 1. 标记节点不可调度 kubectl cordon <node-name> # 2. 优雅驱逐Pod（默认30秒宽限期） kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data # 3. 物理机维护完成后解除封锁 kubectl uncordon <node-name>

适用场景：计划内维护

优势：原生支持、操作简单

局限：业务有短暂中断（取决于Pod重启时间）

方案2：多集群联邦+流量切换

graph LR A[物理机集群A] --> C[Global Load Balancer] B[物理机集群B] --> C C --> D[终端用户]

实现步骤：

1. 通过Karmada/Clusternet构建联邦集群
2. 使用Istio或Nginx Ingress全局负载
3. 逐步将流量从旧集群切换到新集群
4. 验证后下线原物理节点

适用场景：跨机房迁移、大规模升级

数据同步：结合Velero进行PV迁移

方案3：容器热迁移（实验性）

操作示例：

关键保障措施

1. 存储连续性

   • 使用RWX（ReadWriteMany）存储卷（如CephFS/NFS）
   • CSI驱动配合存储阵列复制技术

2. 网络零中断

   • BGP ECMP+IP保持技术（如kube-router）
   • 会话保持：Service配置sessionAffinity

   • 特殊硬件处理

     

     # GPU设备直通迁移示例 kind: Pod spec: containers: - name: gpu-app resources: limits: nvidia.com/gpu: 2 nodeSelector: accelerator: nvidia-tesla-v100

     迁移时需确保目标机相同型号GPU

   迁移风险控制清单

   • 前置检查：etcd健康状态/kubelet日志/资源预留
   • 分批迁移：单次不超过10%节点
   • 回滚方案：快照关键组件（etcd/API Server）
   • 监控指标：重点关注
     • Pod启动延迟（kube_pod_start_time）
     • 服务错误率（istio_requests_total）

   最佳实践建议

   1. 混合部署策略：关键业务分散在多个物理机架
   2. 迁移验证黄金指标：
      • 请求成功率 ≥ 99.95%
      • 配置重载时间 < 5s
   3. 自动化工具链：
      • 集群状态备份：Velero
      • 流程编排：Argo Workflows

   引用说明：

   Kubernetes官方维护文档《Upgrading kubeadm clusters》v1.27

   Google SRE手册《零停机迁移实践》2022版

   CNCF白皮书《Multi-Cluster Management at Scale》

   Linux基金会CRIU技术报告（项目地址：https://criu.org）

   通过结合Kubernetes原生能力和分布式系统设计，物理机迁移可控制在秒级中断内完成，建议每次迁移前在预演环境验证流程，并建立完整的可观测性覆盖，这是实现真正”在线”迁移的核心保障。

   【本文持续更新于2025年K8s运维知识库 | 技术验证：Kubernetes v1.26+】