作者 | 王思宇（酒祝）

前言

OpenKruise 是阿里云开源的大规模应用自动化管理引擎，在功能上对标了 Kubernetes 原生的 Deployment/StatefulSet 等控制器，但 OpenKruise 提供了更多的增强功能，如：优雅原地升级、发布优先级/打散策略、多可用区 workload 抽象管理、统一 sidecar 容器注入管理等，都是经历了阿里巴巴超大规模应用场景打磨出的核心能力。这些 feature 帮助我们应对更加多样化的部署环境和需求、为集群维护者和应用开发者带来更加灵活的部署发布组合策略。

目前在阿里巴巴内部云原生环境中，应用全部统一使用 OpenKruise 的能力做 Pod 部署、发布管理，而不少业界公司和阿里云上的客户由于 K8s 原生 Deployment 等负载不能完全满足需求，也转而采用 OpenKruise 作为应用部署载体。我们希望 OpenKruise 让每一位 Kubernetes 开发者和阿里云上的用户都能便捷地使用上阿里巴巴内部云原生应用所统一使用的部署发布能力！

背景

如何在 Kubernetes 集群中部署节点组件呢？相信大家对 DaemonSet 并不陌生，它能够帮助我们将定义好的 Pod 部署到所有符合条件的 Node 上，这大大减轻了过去我们维护节点上各类守护进程的痛苦。

在阿里巴巴内部的云原生环境中，存在不少网络、存储、GPU、监控等等相关的节点组件都是通过 DaemonSet 部署管理的。但是随着近两年 Kubernetes 集群规模越来越大，所有核心业务逐渐全量上云原生之后，我们越发感受到原生 DaemonSet 很难满足大规模、高可用的复杂场景需求。

大家可以理解为原生的 DaemonSet 确实解决了 0 -> 1 的问题，避免了直接管理 Node 上各类软件包和守护进程的难题，能做到用一致化的 Pod 来部署节点组件。但是在部署之后呢？我们面临的是 1 -> N 的不断迭代升级的问题了，而在升级能力方面，原生 DaemonSet 做的实在有些敷衍了事的感觉。

apiVersion: apps/v1
kind: DaemonSet
spec:updateStrategy:type: RollingUpdaterollingUpdate:maxUnavailable: 2# ...

apiVersion: apps/v1
kind: DaemonSet
spec:updateStrategy:type: OnDelete# ...

以上是原生 DaemonSet 支持的两种升级方式。相信多数人使用 DaemonSet 基本都是默认的 RollingUpdate 滚动升级，这本身是没问题的，问题就在于滚动升级时只支持了 maxUnavailable 一个策略，这就让我们很难接受了。目前阿里巴巴内的 Kubernetes 不少已经做到单集群上万节点，这些节点可能有不同的机型、拓扑、核心程度、内核版本等等，而 DaemonSet 升级也覆盖到这上万节点上的 daemon Pod、涉及所有节点上的应用 Pod。

面对如此复杂和规模化的环境，原生 DaemonSet 没有灰度、没有分批、没有暂停、没有优先级，仅仅用一个 maxUnavailable 策略显然是无法满足的。要知道 daemon Pod 即使配置了 readinessProbe 往往也只能检查容器内进程是否启动运行，而对于进程的运行情况很难考量。

因此，即使 DaemonSet 发布了一个代码有 bug 的版本，只要进程能正常启动则 maxUnavailable 策略就无法保护，DaemonSet 会一直发布下去；如果升级开始了一段时间后才发现问题，那此时很可能故障范围就已经覆盖到整个集群了。

为了避免这个问题，我们曾经一度改为使用 OnDelete 策略、在发布平台上控制发布顺序和分批，但终态上我们还是希望将 workload 的能力下沉归还到 workload，形成闭环，避免将完整的能力分散到多个模块。因此随着 OpenKruise 的成熟和在阿里内外的铺开，我们总结了内部对 DaemonSet 的通用化发布需求、将其沉淀到 OpenKruise 中，称之为 Advanced DaemonSet。

目前阿里巴巴和蚂蚁集团内部的大部分 DaemonSet 都已经统一到 Advanced DaemonSet 部署管理，并且随着 OpenKruise v0.6.0 版本的推出之后，外部一些公司如位于以色列的 Bringg 都已经开始对接使用。

能力解析

Advanced DaemonSet 中主要增加的 API 字段如下：

const (
+    // StandardRollingUpdateType replace the old daemons by new ones using rolling update i.e replace them on each node one after the other.
+    // this is the default type for RollingUpdate.
+    StandardRollingUpdateType RollingUpdateType = "Standard"+    // SurgingRollingUpdateType replaces the old daemons by new ones using rolling update i.e replace them on each node one
+    // after the other, creating the new pod and then killing the old one.
+    SurgingRollingUpdateType RollingUpdateType = "Surging"
)// Spec to control the desired behavior of daemon set rolling update.
type RollingUpdateDaemonSet struct {+    // Type is to specify which kind of rollingUpdate.
+    Type RollingUpdateType `json:"rollingUpdateType,omitempty" protobuf:"bytes,1,opt,name=rollingUpdateType"`// ...MaxUnavailable *intstr.IntOrString `json:"maxUnavailable,omitempty" protobuf:"bytes,2,opt,name=maxUnavailable"`+    // A label query over nodes that are managed by the daemon set RollingUpdate.
+    // Must match in order to be controlled.
+    // It must match the node's labels.
+    Selector *metav1.LabelSelector `json:"selector,omitempty" protobuf:"bytes,3,opt,name=selector"`+    // The number of DaemonSet pods remained to be old version.
+    // Default value is 0.
+    // Maximum value is status.DesiredNumberScheduled, which means no pod will be updated.
+    // +optional
+    Partition *int32 `json:"partition,omitempty" protobuf:"varint,4,opt,name=partition"`+    // Indicates that the daemon set is paused and will not be processed by the
+    // daemon set controller.
+    // +optional
+    Paused *bool `json:"paused,omitempty" protobuf:"varint,5,opt,name=paused"`+    // Only when type=SurgingRollingUpdateType, it works.
+    // The maximum number of DaemonSet pods that can be scheduled above the desired number of pods
+    // during the update. Value can be an absolute number (ex: 5) or a percentage of the total number
+    // of DaemonSet pods at the start of the update (ex: 10%). The absolute number is calculated from
+    // the percentage by rounding up. This cannot be 0. The default value is 1. Example: when this is
+    // set to 30%, at most 30% of the total number of nodes that should be running the daemon pod
+    // (i.e. status.desiredNumberScheduled) can have 2 pods running at any given time. The update
+    // starts by starting replacements for at most 30% of those DaemonSet pods. Once the new pods are
+    // available it then stops the existing pods before proceeding onto other DaemonSet pods, thus
+    // ensuring that at most 130% of the desired final number of DaemonSet  pods are running at all
+    // times during the update.
+    // +optional
+    MaxSurge *intstr.IntOrString `json:"maxSurge,omitempty" protobuf:"bytes,7,opt,name=maxSurge"`
}type DaemonSetSpec struct {// ...+    // BurstReplicas is a rate limiter for booting pods on a lot of pods.
+    // The default value is 250
+    BurstReplicas *intstr.IntOrString `json:"burstReplicas,omitempty" protobuf:"bytes,5,opt,name=burstReplicas"`
}

按节点灰度

在一个大规模 Kubernetes 集群中往往存在很多种差异化的节点类型，比如机型、拓扑、核心程度、内核版本等，因此在 DaemonSet 发布的时候我们支持根据 Node 的标签来匹配发布哪些 Node 上的 Pod。

apiVersion: apps.kruise.io/v1alpha1
kind: DaemonSet
spec:# ...updateStrategy:type: RollingUpdaterollingUpdate:selector:matchLabels:nodeType: canary

比如上述配置了滚动升级下的 selector 策略，则 DaemonSet 只会在符合 selector 条件的 Node 上把 Pod 做滚动升级。如果 selector 改变，则 DaemonSet 会按照新的 selector 做升级，对已经是最新版本的 Pod 不会做变动。

因此，用户可以通过多次修改 selector，来实现不同类型 Node 的前后发布顺序。这个优先顺序可以是特定一批用于灰度的非核心节点，也可以是一些逻辑资源池等。

按数量灰度

如果说你不关心节点类型，Advanced DaemonSet 同样提供了按数量灰度的能力：

apiVersion: apps.kruise.io/v1alpha1
kind: DaemonSet
spec:# ...updateStrategy:type: RollingUpdaterollingUpdate:partition: 100

这里的 partition 和 OpenKruise 中其他 CloneSet、Advanced StatefulSet 类似，都表示了维持旧版本的数量，也就是说 Kruise 控制器会选择 status.DesiredNumberScheduled - partition 数量的 Pod 滚动升级为新版本。

比如当前集群中 DaemonSet 部署的节点数量是 120 个，当滚动升级时如果设置了 partition 为 100，则 DaemonSet 只会选择 20 个 Pod 滚动到新版本。只有当用户再次下调 partition，DaemonSet 才会继续按要求数量来继续升级。

多维度灰度

上述两种灰度策略相信都不难理解，那么如果同时配置了按节点和按数量两种灰度策略，会怎么样呢？

apiVersion: apps.kruise.io/v1alpha1
kind: DaemonSet
spec:# ...updateStrategy:type: RollingUpdaterollingUpdate:maxUnavailable: 5partition: 100selector:matchLabels:nodeType: canary

想搞清楚这个问题，其实看懂 Advanced DaemonSet 的发布策略计算逻辑就很好理解了，有兴趣的同学可以跳去看一下：https://github.com/openkruise/kruise/blob/master/pkg/controller/daemonset/update.go#L459

参考上面这个 YAML，如果用户同时配置了 partition 和 selector，那么控制器在发布的时候会先按照 selector 匹配符合条件的 Node，再按照 partition 计算其中能够发布的数量。当然，如果你还配置了原生 DaemonSet 就支持的 maxUnavailable，那么最后还会按照 unavailable 的数量再次限制实际能滚动升级的数量。

简单来说，最终真正执行滚动升级的 Pod，一定是要同时满足所有配置的灰度策略。

热升级

标准的 DaemonSet 滚动升级过程，是通过先删除旧 Pod、再创建新 Pod 的方式来做的。在绝大部分场景下这样的方式都是可以满足的，然而如果这个 daemon Pod 的作用还需要对外提供服务，那么滚动的时候可能对应 Node 上的服务就不可用了。

为了提供高可用能力，我们对 DaemonSet 也提供了 surging 发布策略。（回顾一下原生 Deployment 或者 OpenKruise 的 CloneSet，在这些面向无状态服务的 workload 中如果配置了 maxSurging，则发布时会先多扩出来 maxSurging 数量的 Pod，再逐渐删掉旧版本的 Pod。）

apiVersion: apps.kruise.io/v1alpha1
kind: DaemonSet
spec:# ...updateStrategy:rollingUpdate:type: Surging  # defaults to StandardmaxSurge: 30%

首先，在滚动升级中配置 type: Surging，这个类型默认是 Standard – 也就是先删再扩，而一旦设置为 Surging 则变为先扩再缩。也就是在滚动升级时，DaemonSet 会先在要发布的 Node 上新建一个 Pod，等这个新版本 Pod 变为 ready 之后再把旧版本 Pod 删除掉。

另外在流式的策略上，maxUnavailable 是用于 Standard 类型的，对应了在滚动升级时最多在多少个 Node 上删除 Pod。而 maxSurge 策略是用于 Surging 类型的，对应了在滚动升级时最多在多少个 Node 上多扩出一个 Pod。

发布暂停

此外，Advanced DaemonSet 还支持了 paused 一键暂停发布。这个比较好理解，就不细表述了。

apiVersion: apps.kruise.io/v1alpha1
kind: DaemonSet
spec:# ...updateStrategy:rollingUpdate:paused: true

总结

总的来看，OpenKruise 在原生 DaemonSet 基础上增加了一系列面向生产场景的发布策略，让 DaemonSet 的升级过程更加安全、可控、自动化。

后续 OpenKruise 还会持续在应用部署/发布能力上做出更深的优化，我们也欢迎每一位云原生爱好者来共同参与 OpenKruise 的建设。与其他一些开源项目不同，OpenKruise 并不是阿里内部代码的复刻；恰恰相反，OpenKruise Github 仓库是阿里内部代码库的 upstream。因此，每一行你贡献的代码，都将运行在阿里内部的所有 Kubernetes 集群中、都将共同支撑了阿里巴巴全球顶尖规模的云原生应用场景！

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的公众号。”

OpenKruise：解放 DaemonSet 运维之路相关推荐

有赞MySQL自动化运维之路—ZanDB
有赞MySQL自动化运维之路-ZanDB 一.前言在互联网时代,业务规模常常出现爆发式的增长.快速的实例交付,数据库优化以及备份管理等任务都对DBA产生了更高的要求,单纯的凭借记忆力去管理那几十套D ...
python脚本监控网站状态 - 赵海华_运维之路 - 51CTO技术博客
python脚本监控网站状态 - 赵海华_运维之路 - 51CTO技术博客 python脚本监控网站状态 2013-01-09 09:21:02 标签:监控 python 原创作品,允许转载,转载时请 ...
开启Python自动化运维之路
关于Python的入门,推荐Dive into Python及廖雪峰的Python教程. 第一个程序学一门语言,按惯例都要先来一个Hello World! 代码高亮效果代码如下: print(&q ...
微信月活9亿的高效运维之路
前言在GOPS2017北京站上,来自微信的吴磊演讲<微信月活9亿的高效运维之路>,分享了关于弹性伸缩,扩容和缩容等方面的内容,现整理分享出来,希望对有需要的人有所帮助. 微信业务量增长的 ...
python自动化运维之路~DAY1
python自动化运维之路~DAY1 作者:尹正杰版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.文件大小单位单位换算我们一起看一下下面的图: 没错,都是数字,而且这些数字都是二进制的数字 ...
Linux 运维之路001
后续 Linxu运维之路–002 Linux学习笔记 Linux是什么讲点故事伟大的GNU计划 Linux 的诞生 Linux的核心版本 Linux distribution PRM 原理: PR ...
干货：魅族基础架构运维之路
本文来自魅族云平台系统架构师梁鹏在听云应用性能管理大讲堂-<魅族基础架构运维之路>分享总结很高兴能在这里跟大家做一个分享和交流.我叫梁鹏,来自魅族云平台,主要是负责魅族系统运维.平台建设 ...
python自动化运维之路~DAY6
python自动化运维之路~DAY6 作者:尹正杰版权声明:原创作品,谢绝转载!否则将追究法律责任. 如果你想开发一款游戏,会存在角色的混搭的情况,这个时候"面向对象过程"就出 ...
数据中心智能化运维之路
在新技术层出不穷的今天,数据中心运维工作总是得不到足够的重视.数据中心在不出任何问题的情况下,对运维的工作是持默认态度的,但如果出了一系列问题,付出的工作可能毁于一旦,工作的绩效有点要拼人品的味道.其 ...

OpenKruise：解放 DaemonSet 运维之路

前言

背景