【问题标题】:Are Kubernetes API calls secret update and configmap update atomic calls?Kubernetes API 调用是否是秘密更新和 configmap 更新原子调用?
【发布时间】:2020-02-20 01:49:08
【问题描述】:

client.Secrets(namespace).Update(secret) 是原子调用吗?如果此调用以某种方式失败,存储在 Kubernetes API 服务器中的原始密钥是否会损坏?

https://github.com/kubernetes/client-go/blob/d1b30110f1abd3b2fb21c5c2daad4345ede8a9fc/kubernetes/typed/core/v1/secret.go#L41

同样,core.ConfigMaps(namespace).Update(configmap) 是原子调用吗?如果此调用失败,现有的 configmap 是否会损坏?

【问题讨论】:

    标签: kubernetes kubernetes-apiserver kubernetes-go-client


    【解决方案1】:

    client-go UPDATE是一个HTTP PUT,所以它会替换对象,是一个原子操作。但是,在执行此操作时需要考虑一些情况,例如如果有多个客户端在同一个对象上运行...您应该查看这个链接的客户端示例以及其他解决方案:

    https://github.com/kubernetes/client-go/blob/master/examples/create-update-delete-deployment/main.go#L109-L123

    【讨论】:

      【解决方案2】:

      根据 Kubernetes documentation 在关于 Server Side Apply 的部分,您可以找到以下内容:

      通过“field management”机制跟踪对象字段的更改。当字段的值更改时,所有权从其当前经理转移到进行更改的经理。尝试应用对象时,具有不同值且由另一个经理拥有的字段将导致 conflict。这样做是为了表明该操作可能会撤消另一个协作者的更改。可以强制冲突,在这种情况下,值将被覆盖,所有权将被转移。


      还有一些关于merge strategy.的信息

      合并策略

      使用 Server Side Apply 实现的合并策略提供了通常更稳定的对象生命周期。服务器端应用尝试根据管理字段的事实来合并字段,而不是仅根据值来否决。这种方式旨在通过减少意外干扰,使多个参与者更新同一对象变得更容易和更稳定。

      当用户向服务器端应用端点发送“完全指定的意图”对象时,如果在两个地方都指定了值,服务器会将其与支持应用配置中的值的活动对象合并。如果应用的配置中存在的项目集不是同一用户上次应用的项目的超集,则删除不由任何其他应用程序管理的每个缺失项目。有关在合并时如何使用对象架构做出决策的更多信息,请参阅sigs.k8s.io/structured-merge-diff

      希望这会有所帮助。


      编辑: 是的,apply and update 使用此功能。

      申请更新

      此功能考虑的两种操作类型是ApplyPATCH 内容类型为 application/apply-patch+yaml)和 Update(所有其他修改对象的操作)。两个都 操作更新managedFields,但行为有点 不同。

      例如,只有应用操作在更新时发生冲突时失败 才不是。此外,还需要应用操作来标识自己 通过提供fieldManager 查询参数,而查询 参数对于更新操作是可选的。最后,当使用 应用操作,你不能在对象中有managedFields 正在申请中。

      【讨论】:

      • 谢谢,皮奥特。这是否意味着 secret update 和 configmap update 使用合并策略?如果合并失败,新的字段值会被移除,所有权不会转移?
      猜你喜欢
      • 1970-01-01
      • 2019-02-10
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-12-20
      • 1970-01-01
      • 2018-08-29
      • 2020-09-30
      相关资源
      最近更新 更多