client.Secrets(namespace).Update(secret) 是原子调用吗?如果此调用以某种方式失败,存储在 Kubernetes API 服务器中的原始机密是否会损坏?
同样, core.ConfigMaps(namespace).Update(configmap) 是原子调用吗?如果此调用失败,现有的 configmap 是否会损坏?
client.Secrets(namespace).Update(secret) 是原子调用吗?如果此调用以某种方式失败,存储在 Kubernetes API 服务器中的原始机密是否会损坏?
同样, core.ConfigMaps(namespace).Update(configmap) 是原子调用吗?如果此调用失败,现有的 configmap 是否会损坏?
client-go UPDATE是一个 HTTP PUT,所以它会替换对象,并且是一个原子操作。但是,在执行此操作时需要考虑一些情况,例如,如果有多个客户端在同一个对象上运行……您应该查看这个链接的客户端运行示例以及其他解决方案:
根据关于服务器端应用部分的 Kubernetes文档,您可以找到以下内容:
通过“<a href="https://kubernetes.io/docs/reference/using-api/api-concepts/#field-management" rel="nofollow noreferrer">字段管理“跟踪对象字段的更改机制。当字段的值更改时,所有权从其当前经理转移到进行更改的经理。尝试应用对象时,具有不同值且由另一个经理拥有的字段将导致冲突。这样做是为了表明该操作可能会撤消另一个协作者的更改。可以强制冲突,在这种情况下,值将被覆盖,所有权将被转移。
还有一些关于合并策略的信息。
合并策略
使用 Server Side Apply 实现的合并策略提供了通常更稳定的对象生命周期。服务器端应用尝试根据管理字段的事实来合并字段,而不是仅根据值来否决。这种方式旨在通过减少意外干扰,使多个参与者更新同一对象变得更容易和更稳定。
当用户向服务器端应用端点发送“完全指定的意图”对象时,如果在两个地方都指定了该值,则服务器会将其与支持应用配置中的值的活动对象合并。如果应用的配置中存在的项目集不是同一用户上次应用的项目的超集,则删除不由任何其他应用程序管理的每个缺失项目。有关在合并时如何使用对象的模式做出决策的更多信息,请参阅sigs.k8s.io/structured-merge-diff。
希望这可以帮助。
编辑: 是的,应用和更新使用此功能。
应用和更新
此功能考虑的两种操作类型是
Apply
(PATCH
具有内容类型application/apply-patch+yaml
)和Update
(所有其他修改对象的操作)。这两个操作都更新了managedFields
,但行为略有不同。例如,只有应用操作在冲突时失败,而更新不会。此外,应用操作需要通过提供
fieldManager
查询参数来标识自己,而查询参数对于更新操作是可选的。最后,当使用应用操作时,您不能managedFields
在正在应用的对象中拥有。