s:select默认值_默认值很难：Kubernetes部署版

s:select默认值

A colleague of mine in the GKE team here at Google just ran into a very strange problem. She was updating an existing deployment with a new image that was under development, so she used the :latest tag on the image, and left the imagePullPolicy unset. After all, the Kubernetes documentation states that:

我在Google GKE小组中的一位同事遇到了一个非常奇怪的问题。 她正在使用正在开发的新映像更新现有部署，因此她在映像上使用了:latest标签，并且imagePullPolicy设置imagePullPolicy 。 毕竟， Kubernetes文档指出 ：

If you would like to always force a pull, you can… omit the imagePullPolicy and use :latest as the tag for the image to use.

如果您想始终强制拉动，则可以…省略imagePullPolicy并使用:latest作为要使用的图像的标签。

No problem, right? And yet, the image on her nodes stubbornly refused to be updated. Why was this?

没问题吧？ 然而，她节点上的图像却顽固地拒绝更新。 怎么会这样

After a few hours of confusion, she found her answer. Remember how I said that she was updating her deployment, and not creating it? Well, it turns out that the original version of her deployment did not use the :latest tag — it used a real, genuine, should-not-be-pulled-if-present image. And so, when she created the deployment without an imagePullPolicy, Kubernetes helpfully set the policy to IfNotPresent — and then persisted this new default.

经过几个小时的困惑，她找到了答案 。 还记得我怎么说她正在更新部署而不是创建部署吗？ 好吧，事实证明，她的部署的原始版本没有使用:latest标记-它使用了真实的，真实的，不应该被呈现的图像。 因此，当她创建没有imagePullPolicy的部署时，Kubernetes会很有帮助地将策略设置为IfNotPresent然后IfNotPresent此新的默认设置。

I should mention at this point that I’ve been a member of the GKE team for almost two years, and she’s on the team for about half that time. While we’re not expert GKE operators, we’ve been developing and deploying workloads pretty consistently for about a year as we develop a fairly sophisticated feature. We are by no means novices. And we still got tripped up.

在这一点上，我应该提到的是，我已经加入GKE团队近两年了，而她在该团队中任职的时间约为一半。 尽管我们不是GKE的专业操作员 ，但由于我们开发了相当复杂的功能 ，因此我们已经持续一致地开发和部署工作负载大约一年了。 我们绝不是新手。 而且我们仍然绊倒了。

The root of this problem is the concept of persistent, dependent defaults. That is, when one field (imagePullPolicy) was unset, its value was determined based on another field (the tag on the image field). But when the second field was changed, the first field was not. Oops.

这个问题的根源是持久的，依赖的默认值的概念。 也就是说，当未设置一个字段( imagePullPolicy )时，其值是根据另一字段( image字段上的标记)确定的。 但是当第二个字段更改时，第一个字段没有更改。 哎呀。

One possible, immediate solution to this problem is simply to change the imagePullPolicy to Always. As a completely different doc helpfully points out:

解决此问题的一种可能的直接解决方案是，只需将imagePullPolicy更改为Always 。 完全不同的文档可以帮助指出：

Note: The caching semantics of the underlying image provider make even imagePullPolicy: Always efficient. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.

注意：基础图像提供程序的缓存语义甚至使imagePullPolicy: Always有效。 例如，使用Docker，如果映像已经存在，则拉取尝试很快，因为所有映像层都已缓存，无需下载映像。

While this is true, it ensures your container registry is guaranteed to be on the critical path when you start a pod. During development, this is almost certainly fine, but it’s something to watch out for if your pods restart frequently.

虽然这是事实，它可以确保当你开始你的POD集装箱注册表是保证在关键路径上。 在开发过程中，这几乎可以肯定是不错的，但是如果您的Pod频繁重启，则需要提防这一点。

It would also be nice to add a warning (new in 1.19) to catch this kind of case, but this is easier said than done. As explained to me by a senior contributor (after I whined a bit about our misfortune):

添加警告( 1.19中的新功能 )来捕获这种情况也很好，但是说起来容易做起来难。 正如一位资深撰稿人向我解释的(在我对自己的不幸发了一点抱怨之后)：

This is actually an unfortunate interaction between client-side apply and default values derived from other fields. The combination of the two would make it hard-to-impossible to detect the issue at the level you are describing.

这实际上是客户端应用和从其他字段派生的默认值之间的不幸交互。 两者的结合将使您难以在所描述的级别上检测到该问题。

kubectl apply (when updating an existing object) submits patches, not complete objects, based on a diff between the manifest you are applying and the last content you applied (stored as an annotation on the object). If you add --v=8 you can see only the image field is being sent in the patch request body.

kubectl apply (更新现有对象时)基于要应用的清单和所应用的最后内容(存储为对象上的注释)之间的差异而提交补丁，而不是完整的对象。 如果添加--v=8 ，则可以在修补程序请求正文中看到仅发送图像字段。

Patches are applied to the existing object to compute the “new object” in a generic patch-handling layer before the REST handler or admission see the new object, so by the time the REST handler or validation or admission see the old/new objects, it is not possible to tell whether the imagePullPolicy was user-set or defaulted, and whether the imagePullPolicy in the new object was set by an incoming patch or inherited from the existing object.

在REST处理程序或准入看到新对象之前，将补丁应用于现有对象，以在通用补丁处理层中计算“新对象”，因此在REST处理程序或验证或准入看到旧对象/新对象之前，无法判断imagePullPolicy是用户设置的还是默认的，以及新对象中的imagePullPolicy是由传入的补丁程序设置还是从现有对象继承而来。

As an aside, derived defaults like this are extremely problematic for exactly this reason. If the user changes the input field on an update, they can be left with a default based on the old value. This is why selectors and labels stopped being defaulted from the pod template labels in apps/v1 Deployments, etc.

顺便说一句，正是由于这个原因，这样的派生默认值极有问题。 如果用户在更新中更改输入字段，则可以根据旧值为他们保留默认值。 这就是为什么选择器和标签不再从apps / v1部署等中的pod模板标签中默认的原因。

So if you’re an API designer, think very carefully about those dependent defaults. In the meantime, I’m off to write a docs PR.

所以，如果你是一个API设计师，认为很小心那些依赖默认值。 同时，我要写一份文档PR。

Thanks to Yiqi Gao for debugging the problem and Jordan Liggitt for providing lots of interesting background on it. Photo by Miguel Á. Padriñán from Pexels.

感谢 Yiyi Gao 调试了问题，并 感谢 Jordan Liggitt 提供了许多有趣的背景知识。 摄影：MiguelÁ。 来自Pexels的Padriñán。

翻译自: https://itnext.io/defaults-are-hard-kubernetes-deployment-edition-3b11095792f2

s:select默认值