部署与容器

问题

容器是一个正在运行的东西：它具有身份、生命周期，并最终会消亡。您真正 想描述的不是一个容器，而是其背后的意图——使用此镜像，保持此数量的副本， 在此处可达，以此方式配置——并让其他东西在单个容器来去时保持这一意图 得以实现。

两者之间的差距是大多数编排错误所在之处。编辑错误的内容，您就更改了一个 将在一小时内被替换的正在运行的容器。编辑正确的内容时不小心，您就替换了 本意只是重新标记的容器。

平台如何解决此问题

一个部署是描述。一个容器是其一个运行副本。您编辑描述；平台决定这对副本意味着什么。

这一决策是计算得出的，而非判断。影响容器的所有因素都被哈希化，哈希值的变更意味着容器会被替换而非调整。容器外部任何因素——围绕容器的编排、记录保存——的变更都会生效，而不会影响正在运行的部分。参考表在每个字段的可变性列中承载着这一答案，并且它是通过运行哈希函数来衡量的，而非通过一句话来断言：请参阅 部署清单。

描述也是意图的全部。平台不会读取正在运行的容器并采纳其发现的内容。如果容器发生漂移，描述胜出。

发送描述的一部分

一次更新可能只涉及部署的一部分，而非其全部，并且该规则有两个容易混淆的部分。

您省略的字段会保留其存储的值。 这就是为什么更改镜像只需一个字段的请求：无需先读取其他内容，也不会影响其他部分。

您发送的字段会直接替换存储的字段。 集合不会被合并。发送一个环境变量的映射并不会将该变量添加到存储的映射中——它会成为整个映射，其中的其他内容都会消失。卷、网络和标签也是如此。

因此，要更改集合中的单个条目，意味着需要读取存储的集合，在本地进行修改，然后将整个集合发送回去。这是设计使然——发送一个字段意味着“这就是它现在的值”——但这也是部分请求可能意外移除无人有意移除的配置的唯一情况，这就是为什么在此处说明，而不是留待发现。

secrets是唯一刻意的例外：它被合并，而非替换。 发送secrets的 PUT 操作是读取-修改-写入——您发送的引用会被应用，而您请求体中未提及的任何已存储引用都会被保留，而不是被丢弃。原因在于数据丢失风险，而非偏好：此处的其他每个集合都可以安全地覆盖，因为其整个值在同一个请求中可见，但调用者重新发送一个引用以添加凭据时，如果不这样做，就会悄悄丢弃其他引用，工作负载将在没有它们的情况下启动，而不是大声失败。因为保留一个您未明确要求的引用是一种更改，所以它会作为警告被披露，说明保留了什么——参见拒绝和更改]。因此，从secrets中省略一个引用永远不会移除它；要实际移除一个，请发送"secrets": []以清空数组，然后 PUT 您想要保留的引用。

Not this

本页不列举字段、字段类型或默认值。这些信息从模式中生成，并位于部署清单参考； 在此处重新列出会导致产生第二个可能与第一个不一致的副本。

它也没有涵盖运行至完成而非持续运行的工作——参见 计划工作——或更改如何推出，那是滚动更新的内容。

何处查看

• 部署的每个字段：部署清单。
• 被拒绝的变更会告诉你什么：拒绝和修改。