滚动发布不是瞬间替换全部实例，而是新旧版本并存、逐批切换并逐步终止旧实例的过程。发布期间需要额外容量承载新副本，系统还要处理新旧数据格式、流量路由收敛和在途请求。若只检查期望副本数，可能在扩容时出现调度等待，或在终止旧实例时中断长请求。📈
根据滚动策略估算同时存在的新旧副本上限，并乘以每个实例的CPU和内存请求。再叠加节点系统保留量、其他工作负载和发布期间的扩缩容需求。若新实例启动较慢，旧实例会继续存活更长时间，峰值并存窗口随之扩大。镜像拉取、缓存预热、数据库连接建立也会形成短时资源尖峰。
发布前观察节点可分配容量、Pending副本、CPU和内存水位、镜像拉取时间及启动耗时。若新副本无法调度，滚动可能停在部分完成状态；若节点余量足够但新旧并存令依赖连接数超过上限，仍会出现服务故障。容量评估应覆盖应用本身和关键依赖的连接与吞吐能力。🧮
滚动期间旧实例可能处理新版本写入的数据，新实例也可能收到旧版本产生的消息。数据库变更宜先增加兼容字段或结构，部署支持新旧形式的应用，再迁移数据，待旧版本彻底退出后才删除旧结构。消息消费者应能识别并处理发布期间仍在队列中的旧格式消息。
API契约、配置键、缓存格式和序列化协议都可能造成版本交叉问题。兼容性测试应覆盖新应用读旧数据、旧应用读新应用写入的数据，以及发布过程中混合消费者对消息的处理。镜像启动成功并不证明新旧版本能够安全共存。🧩
终止实例时，应用应先停止接收新任务或新请求，再等待服务发现和负载均衡系统将实例摘除，之后完成在途请求、刷新缓冲并关闭依赖连接。若先退出进程再等待摘除传播，新请求仍可能被路由到即将关闭的实例。HTTP长请求、流式响应、WebSocket和后台消费者需要不同的排空方式。
排空时间应依据实际最长请求、客户端重试策略和业务任务完成窗口确定。应用可在收到终止信号后进入draining状态，健康或就绪端点随之变化，并拒绝新任务。平台终止宽限期必须长于应用完成收尾所需时间，同时覆盖控制面传播和调度延迟。🔌
发布过程中关注新旧副本数量、就绪比例、Pending时间、请求错误率、延迟分位数、连接数、重试量、CPU/内存水位和依赖池饱和度。将这些指标与发布批次时间关联。若错误率连续超过门槛、就绪副本不足或依赖连接达到安全上限，应暂停扩量并判断是版本缺陷、容量不足还是排空行为异常。
可使用只读集群查询观察工作负载和Pod状态，例如kubectl get pods与kubectl describe pod POD；这些状态不能替代服务端点和应用请求指标。需要结合事件、端点变化和业务错误率确认流量确实从旧实例转移到新实例。📊
容易误判：进程收到SIGTERM只说明通知到达。若应用忽略信号、未摘除流量或超出终止宽限期，平台仍可能强制结束进程。🔔
