容器生命周期本身不直接实现平滑滚动升级，而是为其提供基础状态支撑；需联动健康检查（readinessProbe/livenessProbe）、副本调度（replicas≥2、start-first）、优雅终止（preStop、terminationGracePeriodSeconds）及网络层切换（Ingress、Service）才能真正零停机。
容器生命周期本身不直接“实现”平滑滚动升级，而是为它提供基础状态支撑——只有准确识别并控制每个阶段（如 created → running → ready → terminating → stopped），才能让滚动升级真正“平滑”。关键在于：把生命周期各阶段与健康检查、流量切换、副本调度联动起来，避免在非就绪或正在退出时转发请求。
健康检查驱动就绪与存活判断
容器启动后不是立刻可用，必须等应用真正监听端口、加载配置、连接数据库后才算“就绪”。Kubernetes 和 Docker Compose 都依赖探针来感知这一状态：
- readinessProbe 决定是否将流量接入该实例；未通过前，Service 或负载均衡器不会把请求发给它
- livenessProbe 判断容器是否“活着”，失败则重启，防止假死进程长期占用资源
- 典型配置中，
initialDelaySeconds要大于应用冷启动耗时，periodSeconds建议设为 5–10 秒，太短易误判，太长影响响应速度
滚动替换依赖副本数与更新顺序
单副本容器无法滚动——新实例启动期间，旧实例若已停止，服务必然中断。必须满足两个前提：
- replicas ≥ 2：至少保留一个运行中的旧实例，确保流量不丢失
- update_config.order: start-first：先拉起新容器，等其通过 readinessProbe 后，再停旧容器；默认的 stop-first 会先停再启，必然中断
- 搭配
parallelism: 1和delay: 10s可控节奏，避免批量更新压垮依赖服务
优雅终止保障请求不丢
容器收到终止信号（SIGTERM）后，不能立即退出，需完成两件事：
- 通知注册中心（如 Nacos、Consul）下线自身或置权重为 0，让流量不再打进来
- 等待已有请求处理完毕（如 Spring Boot 的
server.shutdown.grace-period、Netty 的 graceful shutdown） - Docker 中可通过
preStop钩子执行清理脚本，Kubernetes 中配合terminationGracePeriodSeconds（建议设为 30 秒以上）
网络层配合实现无缝切换
即使容器状态管理得当，若 DNS 缓存未刷新、反向代理未及时剔除旧节点，用户仍可能访问到已终止实例：
- Docker 内置 DNS 默认缓存 30 秒，建议在应用内使用 DNS 感知重试机制，而非依赖 DNS 立即生效
- Kubernetes Service 使用 iptables 或 IPVS 转发，Endpoint 更新由 kube-proxy 实时同步，延迟通常在秒级
- 生产环境推荐前置一层 Ingress Controller（如 Nginx、Traefik）或服务网格（Istio），支持主动健康探测 + 动态权重调整
