关键在于边跑边换，依赖就绪探针确保新pod就绪后才接入流量，配合maxsurge、maxunavailable控制替换节奏，并通过deployment自动回滚保障可退性。

要实现高可用架构中服务版本的无损滚动更新，关键不是“一次性全换”，而是“边跑边换”——在用户无感知的前提下，让新旧实例交替运行、平稳交接。

下翻滚动更新效果

下翻滚动更新效果

下载

健康检查是滚动更新的守门员
没有健康检查，滚动更新就等于盲操作。容器启动不等于服务就绪。必须配置明确的就绪探针（readiness probe）或 healthcheck，确保流量只打到真正能响应请求的实例上。比如：

• HTTP 类服务：test: ["CMD", "curl", "-f", "http://localhost:80/health"]
• 健康检查间隔建议设为 5–10s，超时不超过 3–5s，重试次数 3 次足够
• Kubernetes 中需配合 readinessProbe，Docker Compose 则用 healthcheck 字段

控制节奏，避免雪崩式替换
一次全量重启会压垮依赖或耗尽连接池。应通过参数限制更新步长：

• parallelism: 1（Compose）或 maxSurge: 1（K8s）：每次只启一个新实例
• delay: 10s 或 update-delay 10s：给新实例留出初始化和预热时间
• maxUnavailable: 0（K8s）或 order: start-first（Compose）：确保旧实例不先下线，始终有可用副本承接流量

回滚机制必须前置设计，不能等出事再补
滚动更新失败时，自动回退比人工干预快十倍。配置要点包括：

• 明确失败动作：failure_action: rollback（Compose Swarm 模式）、--update-failure-action rollback（Swarm CLI）
• Kubernetes 中 Deployment 默认支持回滚，执行 kubectl rollout undo deployment/my-app 即可
• 镜像标签建议用语义化版本（如 v1.2.3），避免使用 latest，确保可追溯、可重现

服务发现与流量切换要无缝衔接
即使容器已就绪，若注册中心未同步或负载均衡器没刷新端点，请求仍会 502。需确认：

• Service / Ingress / Traefik 等组件能自动感知 Pod 状态变化
• 新实例通过 readiness probe 后，才被加入 endpoints（K8s）或 upstream（Nginx/Traefik）
• 若用自建注册中心（如 Consul），确保 client SDK 支持健康实例自动剔除与恢复

本质上，无损滚动更新不是技术堆砌，而是对“就绪”“可用”“可退”三个状态的精准协同。