核心工作负载API GA

守护程序集,Deployment,ReplicaSet和StatefulSet是GA

编者注:我们很高兴宣布,捕鱼大亨网络版 1.9中的Core Workloads API是GA!肯尼斯·欧文斯(Kenneth Owens)的这篇博客文章回顾了Core Workloads是如何从GA起源到GA的,揭示了1.9中的变化,并讨论了您可以期待的未来。

在一开始的时候 …

曾经有 豆荚,紧密耦合的容器共享资源需求,网络,存储和生命周期。 Pod很有用,但是事实证明,用户希望无缝地,可复制地自动创建同一Pod的许多相同副本,因此我们创建了 复制控制器.

复制是前进的一步,但是用户真正需要的是对其复制的Pod进行更高级别的编排。他们想要滚动更新,回滚和翻转。因此,OpenShift团队创建了 部署配置。 部署配置s也很有用,OpenShift用户很高兴。为了允许所有OSS 捕鱼大亨网络版共享兴高采烈并利用 基于集合的标签选择器, 复制集部署方式 已添加到extensions / v1beta1组版本中,为所有捕鱼大亨网络版用户提供了滚动更新,回滚和滚动。

That mostly solved the problem of orchestrating containerized 12 factor apps on 捕鱼大亨网络版, so the community turned its attention to a different problem. Replicating a Pod <n> times isn’t the right hammer for every nail in your cluster. Sometimes, you need to run a Pod on every Node, or on a subset of Nodes (for example, shared side cars like log shippers 和 metrics collectors, 捕鱼大亨网络版 add-ons, 和 Distributed File Systems). The state of the art was 豆荚 combined with NodeSelectors, or static 豆荚, but this is unwieldy. After having grown used to the ease of automation provided by 部署方式s, users demanded the same features for this category of application, so 守护程序集 也被添加到扩展名/ v1beta1。

一段时间以来,用户一直很满意,直到他们决定捕鱼大亨网络版需要能够组织超过12个因素的应用程序和集群基础结构。无论您的体系结构是N层,面向服务还是面向微服务,您的12要素应用程序都依赖有状态工作负载(例如RDBMS,分布式键值存储和消息传递队列)为最终用户和其他应用程序提供服务。这些有状态的工作负载可能具有可用性和持久性要求,只有通过分布式系统才能实现这些要求,并且用户已准备好使用捕鱼大亨网络版来协调整个堆栈。

尽管部署非常适合无状态工作负载,但它们不能为编排分布式系统提供正确的保证。这些应用程序可能需要稳定的网络身份,有序的,顺序的部署,更新和删除以及稳定,持久的存储。 宠物套装 已添加到apps / v1beta1组版本中,以解决此类应用程序。不幸, 我们对它的命名没有考虑,并且由于我们一直致力于成为一个包容性社区,因此我们将其重命名为 有状态集.

最后,我们完成了。

...还是我们?

捕鱼大亨网络版 1.8和apps / v1beta2

Pod,复制控制器,ReplicaSet,Deployment,DaemonSet和StatefulSet被统称为核心工作负载API。我们最终可以统筹所有事情,但是API表面分布在三个组中,存在许多不一致之处,并使用户对每种核心工作负载类型的稳定性感到疑惑。是时候停止添加新功能,而专注于一致性和稳定性了。

Pod和复制控制器处于GA稳定状态,即使您可以在Pod中运行工作负载,它也是属于核心的核心原语。由于建议使用部署来管理无状态应用程序,因此移动复制控制器将毫无用处。在捕鱼大亨网络版 1.8中,我们将所有其他核心工作负载API类型(Deployment,DaemonSet,ReplicaSet和StatefulSet)移至apps / v1beta2组版本。这样做的好处是可以在API的整个表面上提供更好的聚合,并允许我们打破向后兼容性以解决不一致问题。我们的计划是在我们对其完整性感到满意的情况下,将这种新表面推广到通用航空,批发以及原样推广。下面介绍了此版本中的修改,这些修改也在apps / v1中实现。

选择器默认设置已弃用

在早期版本的应用和扩展程序组中,未指定核心工作负载API类型的标签选择器默认为根据该类型模板的标签生成的标签选择器。

这与战略合并补丁和kubectl适用完全不兼容。此外,我们发现,从同一对象的另一个字段的值中默认一个字段的值通常是一种反模式,对于用于编排工作负载的API对象来说,这尤其危险。

不变选择器

选择器变异虽然允许某些用例(如可升级的部署金丝雀),但我们的工作负载控制器无法妥善处理,而且我们始终 强烈警告用户不要使用它。为了提供一致,可用和稳定的API,对于工作负载API中的所有类型,选择器都是不可变的。

我们认为,有更好的方法来支持可升级的金丝雀和精心调制的Pod重贴标签等功能,但是,如果受限的选择器变异对我们的用户来说是必不可少的功能,那么我们将来可以放宽不变性,而不会破坏向后兼容性。

可推广的金丝雀,精心设计的Pod重新标记以及受限的选择器可变性等功能的开发是由用户的需求信号驱动的。如果当前正在修改核心工作负载API对象的选择器,请通过GitHub问题或参与SIG应用程序向我们介绍您的用例。

默认滚动更新

在apps / v1beta2之前,有些类型将其更新策略默认为RollingUpdate以外的其他策略(例如,app / v1beta1 / 有状态集默认使用OnDelete)。我们希望确信RollingUpdate在使其成为默认更新策略之前能够很好地工作,并且在不违反向后兼容性的承诺的前提下,我们无法更改已发布版本中的默认行为。在apps / v1beta2中,默认情况下,我们为所有核心工作负载类型启用了RollingUpdate。

弃用CreatedBy注释

“ kubernetes.io/created-by”是垃圾收集之前几天的遗留物。用户应使用其ownerReferences中对象的ControllerRef来确定对象所有权。我们在1.8中弃用了此功能,并在1.9中将​​其删除。

规模子资源

规模子资源已添加到apps / v1beta2中的所有适用种类(DaemonSet基于其节点选择器进行规模化)。

捕鱼大亨网络版 1.9和apps / v1

按照计划,在捕鱼大亨网络版 1.9中,我们在apps / v1组版本中将整个核心工作负载API界面升级为GA。我们进行了一些更改,以使API保持一致,但是apps / v1与apps / v1beta2大致相同。现实情况是,一段时间以来,大多数用户已经将核心工作负载API的beta版视为GA。由于感觉缺乏稳定性而仍在使用复制控制器s并避开DaemonSet,Deployment和StatefulSet的任何人都应计划将其工作负载(在适用时)迁移到apps / v1。升级过程中进行的细微更改如下所述。

垃圾收集默认为删除

在apps / v1之前,DaemonSet,Deployment,ReplicaSet或StatefulSet中Pod的默认垃圾回收策略是孤立Pods。也就是说,如果您删除了其中一种,则除非明确指定级联删除,否则它们所拥有的Pod不会自动删除。如果您使用kubectl,您可能不会注意到这一点,因为在删除之前,这些类型会缩放为零。在apps / v1中,默认情况下,当删除所有者时,所有核心工作负载API对象现在都将被删除。对于大多数用户而言,此更改是透明的。
状态条件

在apps / v1之前,仅Deployment和ReplicaSet在其Status对象中具有条件。为了保持一致性,所有对象或没有对象都应具有条件。经过一番辩论后,我们认为条件是有用的,并在StatefulSetStatus和DaemonSetStatus中添加了条件。 有状态集和DaemonSet控制器目前不填充它们,但是将来我们可能会通过此机制选择与客户端的通信条件。

缩放子资源已迁移到自动缩放/ v1

我们最初将scale子资源添加到apps组。这是与自动缩放集成的错误方向,并且在某些时候,我们希望使用自定义指标来自动缩放StatefulSet。因此,apps / v1组版本使用autoscaling / v1 scale子资源。

迁移和弃用

您现在可能最想问的问题是:“我到apps / v1的迁移路径是什么?我应该计划多长时间进行迁移?”从捕鱼大亨网络版 1.9起,apps / v1之前的所有组版本均已弃用,并且应针对apps / v1开发所有新代码,但是,如上所述,我们的许多用户将扩展名/ v1beta1视为GA。我们意识到了这一点,并在我们的支持时间表中 弃用政策 仅此而已,最低要求。

在将来的版本中,在完全删除任何组版本之前,我们将默认在API Server中禁用它们。此时,您仍然可以使用组版本,但是必须显式启用它。我们还将提供实用程序,以将API对象的存储版本升级到apps / v1。请记住,核心工作负载类型的所有版本都是双向可转换的。如果要立即手动更新核心工作负载API对象,则可以使用 kubectl转换 在组版本之间转换清单。

下一步是什么?

核心工作负载API表面是稳定的,但它仍然是软件,并且软件永远不会完成。我们经常在稳定的API中添加功能以支持新的用例,并且我们也可能会在核心工作负载API中添加功能。 GA稳定性意味着我们确实添加的任何新功能都将与现有API表面严格向后兼容。从现在开始,我们所做的任何事情都不会破坏我们的向后兼容性保证。如果您希望参与API的这一部分的发展,请随时参与 的GitHub 或参加 SIG应用.

-肯尼思·欧文斯(Kenneth Owens),Google软件工程师