容器迁移本质是镜像分发、配置同步与状态分离的组合动作；关键在于新节点秒级复现服务，需预置镜像至本地Registry或预热，轻量镜像应控制在10MB以内。
容器本身不能直接“迁移”——它没有状态、不带运行时上下文，所谓多节点间快速迁移，本质是镜像分发 + 配置同步 + 状态分离的组合动作。关键不在“搬容器”，而在“让新节点秒级复现相同服务”。
镜像预置与按需拉取
迁移快慢的第一道门槛是镜像是否就位。生产环境必须避免运行时拉取大镜像（网络抖动、超时、失败率高）。
- 提前将常用镜像推送到各节点本地 Registry（如 Harbor、Nexus），或使用镜像预热脚本在节点启动后自动 pull
- 对 Agent 类轻量服务，用
scratch或alpine基础镜像，体积压到 10MB 以内，拉取耗时通常 - 启用 Docker 的
--platform显式指定架构（如linux/amd64），避免跨平台重下载
配置与状态彻底外置
容器必须是无状态的，否则迁移就会卡在“怎么搬内存、搬进程、搬临时文件”上。
- 所有配置通过环境变量、ConfigMap（K8s）或外部配置中心（如 Nacos、Consul）注入，不打包进镜像
- 会话、缓存、计数器等运行时状态，全部写入 Redis、etcd 或共享数据库，容器只读写接口
- 日志不落容器内，统一用
docker logs --driver=fluentd或 stdout/stderr 流式采集，避免迁移前还要打包日志卷
编排层接管调度与故障转移
单靠 docker run 无法实现“快速迁移”，必须依赖编排系统自动触发重建。
- 在 Kubernetes 中，用 Deployment + ReplicaSet 管理，节点宕机后控制器 5–10 秒内就在健康节点拉起新 Pod
- Docker Swarm 模式下，服务（service）自带全局模式（
mode=global）和重启策略（restart-condition=on-failure），故障后自动漂移 - 所有挂载点使用命名卷（named volume）并配合外部存储驱动（如 NFS、Longhorn），确保新容器挂载的是同一份持久化数据
网络与服务发现无缝衔接
迁移后服务地址不能变，客户端才感知不到中断。
- 用 Service（K8s）或 Overlay 网络（Swarm）提供固定 VIP 或 DNS 名，后端 Pod/IP 变化完全透明
- 健康检查必须真实有效（如 HTTP
/health端点），避免新容器还没 ready 就被流量打垮 - 若用 Ingress，确保其 backend 更新延迟 ≤2 秒；可配合 readinessProbe 设置
initialDelaySeconds: 3和periodSeconds: 2
