本文发表已超过一年。旧文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。

Kubernetes 1.18 功能服务器端应用 Beta 2

什么是服务端应用?

服务端应用是将“kubectl apply”迁移到 apiserver 的一项重要工作。它由 Apply 工作组于 2018 年启动。

使用 kubectl 以声明方式应用资源暴露了以下挑战

  • 需要使用 kubectl go 代码,或者必须 shell 到 kubectl。

  • kubectl 使用的补丁格式策略合并补丁是自然增长的,在保持与各种 api-server 版本兼容性的同时进行修复具有挑战性。

  • 某些功能很难直接在客户端实现,例如联合。

服务端应用是一种新的合并算法,以及 Kubernetes api-server 上运行的字段所有权跟踪。服务端应用启用了冲突检测等新功能,因此系统知道何时两个参与者试图编辑同一个字段。

它是如何工作的,什么是 managedFields?

服务端应用通过跟踪系统中哪个参与者更改了对象的每个字段来工作。它通过比较对对象的所有更新,并记录所有已更改的字段以及操作的时间来实现。所有这些信息都存储在对象的元数据中的 managedFields 中。由于对象可以有很多字段,因此此字段可能非常大。

当有人应用时,我们可以使用 managedFields 中存储的信息来报告相关冲突,并帮助合并算法执行正确的操作。

在 1.18 之前它不是已经是 Beta 版了吗?

是的,服务端应用自 1.16 以来一直是 Beta 版,但它没有跟踪与未应用对象关联的字段的所有者。这意味着大多数对象都没有存储 managedFields 元数据,并且无法解决这些对象的冲突。在 Kubernetes 1.18 中,所有新对象都将附加 managedFields,并提供有关冲突的准确信息。

如何使用它?

最常见的用法是通过 kubectl:kubectl apply --server-side。这可能会显示与其他参与者的冲突,包括客户端应用。发生这种情况时,可以使用 --force-conflicts 标志强制冲突,该标志将获取已更改字段的所有权。

当前的限制

我们现在有两个重要的限制,尤其是对于子资源。首先是,如果您使用状态应用,则状态将被忽略。我们仍然会尝试获取字段,这可能会导致无效的冲突。另一个是我们不会更新某些子资源(包括 scale)上的 managedFields,因此您可能看不到有关水平 Pod 自动缩放器更改副本数量的信息。

下一步是什么?

我们正在努力改进使用 kubectl 的服务端应用体验,并尝试使其成为默认设置。作为其中的一部分,我们希望改善从客户端到服务端的迁移。

我可以帮忙吗?

当然!工作组应用可在 slack #wg-apply 上通过 邮件列表获得,我们还在太平洋时间每周二上午 9:30 在 Zoom 上开会。我们有很多令人兴奋的功能需要构建,并且可以使用各种帮助。

我们还要借此机会感谢所有为实现这个新的 beta 版做出贡献的贡献者的辛勤工作

  • Daniel Smith
  • Jenny Buckley
  • Joe Betz
  • Julian Modesto
  • Kevin Wiesmüller
  • Maria Ntalla