滚动更新

问题

一次性替换所有容器是直接且低成本的：部署会短暂中断，且所有人都知道这一点。一次替换一个容器是大多数人想要的——但这仅在三个条件都成立时才安全，且每个条件都容易被假设。

新副本必须可观测地就绪，否则流量会转移到未提供服务的实例。两个版本必须能够并行运行，否则“优雅”的滚动更新会损坏共享状态。并且被移交的内容必须是两个副本可以共享的：节点上的读写卷或已发布的端口就不行。

平台如何解决

默认策略是一次性替换所有资源，因为这是唯一没有前提条件的策略。**

任何更温和的方式都必须声明其前置条件并根据这些条件进行检查。 渐进式滚动更新会被拒绝，除非部署携带了实际运行的健康检查，除非它不持有读写卷或已发布的节点端口，并且除非您已在描述中声明两个版本可能短暂共存。该声明永远不会被推断：平台无法知道您的应用程序是否容忍这种情况，而错误的猜测是数据问题而非可用性问题。

健康检查的前提条件是为何一个无操作探针如此重要。对其的检查是存在性检查——因此，在完全拒绝无操作探针之前，部署可以在完全没有探针的情况下满足就绪要求。参见健康检查与进程回收。

滚动更新在时间上是有限的，并且有明确的失败操作。 一个副本可能需要多长时间才能变得健康，它必须在进入下一步之前保持健康多长时间，整个滚动更新可能持续多长时间，以及当它未能完成时会发生什么，这些都是您设置的字段——默认值在部署参考中。

加权滚动更新是一种路由更改。 将一部分流量发送到新版本需要部署本身被路由，因为权重是在路由边缘应用的。

Not this

本页不列出策略、字段名、默认值或确切的前提条件。这些内容在生成的参考文档中，以及您违反时收到的拒绝消息中。

本页也不涵盖回滚平台本身的升级，这属于运维手册而非部署的属性。

何处查看

• 更新块，逐字段说明：部署清单。
• 滚动更新被拒绝的原因，按代码分类：拒绝与修改。