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：容器热迁移（实验性）

操作示例：

# 使用KubeVirt迁移工作负载
virtctl migrate <vm-pod-name> --namespace=<ns>

关键保障措施

1. 存储连续性

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

2. 网络零中断

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

3. 特殊硬件处理

   # 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+】