OpenKruise:解放 DaemonSet 运维之路

简介: # 前言 OpenKruise 是阿里云开源的大规模应用自动化管理引擎,在功能上对标了 Kubernetes 原生的 Deployment/StatefulSet 等控制器,但 OpenKruise 提供了更多的增强功能如 优雅原地升级、发布优先级/打散策略、多可用区workload抽象管理、统一 sidecar

前言

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: RollingUpdate
    rollingUpdate:
      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: RollingUpdate
    rollingUpdate:
      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: RollingUpdate
    rollingUpdate:
      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: RollingUpdate
    rollingUpdate:
      maxUnavailable: 5
      partition: 100
      selector:
        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 Standard
      maxSurge: 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 的升级过程更加安全、可控、自动化。

Advanced DaemonSet 发布能力.png

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

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
人工智能 数据安全/隐私保护
AIGC作品的版权归谁
【2月更文挑战第13天】AIGC作品的版权归谁
341 1
AIGC作品的版权归谁
|
消息中间件 Kubernetes NoSQL
Debian11系统boost库安装
Debian11系统boost库安装
|
12月前
|
Kubernetes 监控 测试技术
k8s学习--OpenKruise详细解释以及原地升级及全链路灰度发布方案
k8s学习--OpenKruise详细解释以及原地升级及全链路灰度发布方案
421 0
|
9月前
|
JavaScript Java 测试技术
基于Java+SpringBoot+Vue实现的车辆充电桩系统设计与实现(系统源码+文档+部署讲解等)
面向大学生毕业选题、开题、任务书、程序设计开发、论文辅导提供一站式服务。主要服务:程序设计开发、代码修改、成品部署、支持定制、论文辅导,助力毕设!
|
11月前
|
人工智能 自然语言处理 网络协议
ps beta ai显示高峰需求进不去怎么办? psai高峰期需求用不了解决办法
PSBetaAI2023加入了AI的功能,在使用过程中,有时会遇到一个令人烦恼的问题,那就是PhotoshopBetaAI提示我们正在面临高峰需求,请稍候再试,针对这个问题,本文为大家整理了几个可行的解决方法,可以根据自己的实际情况来尝试解决
271 12
|
11月前
|
Java API Maven
如何使用 Java 字节码工具检查类文件的完整性
本文介绍如何利用Java字节码工具来检测类文件的完整性和有效性,确保类文件未被篡改或损坏,适用于开发和维护阶段的代码质量控制。
387 5
|
12月前
|
移动开发 Java Windows
Java 匹配\r 和 \n 的正则表达式如何编写
【10月更文挑战第19天】Java 匹配\r 和 \n 的正则表达式如何编写
704 3
|
12月前
|
算法
动态规划算法学习四:最大上升子序列问题(LIS:Longest Increasing Subsequence)
这篇文章介绍了动态规划算法中解决最大上升子序列问题(LIS)的方法,包括问题的描述、动态规划的步骤、状态表示、递推方程、计算最优值以及优化方法,如非动态规划的二分法。
210 0
动态规划算法学习四:最大上升子序列问题(LIS:Longest Increasing Subsequence)
|
JavaScript Linux Android开发
mac环境下搭建frida环境并连接网易mumu模拟器
这篇文章介绍了如何在mac环境下搭建Frida环境,并详细说明了如何连接网易MuMu模拟器进行动态分析。
795 1
|
云安全 缓存 网络协议
如何防护DDoS攻击,筑牢网络安全防线
随着信息技术的飞速发展,网络已成为现代社会不可或缺的一部分,极大地便利了个人社交和商业活动。然而,网络空间在创造无限机遇的同时,也潜藏着诸多威胁,其中分布式拒绝服务攻击(DDoS,Distributed Denial of Service)以其高破坏力和难以防范的特点,成为网络安全领域的一大挑战。本文将从DDoS攻击的原理出发,详细探讨如何有效防护DDoS攻击,以筑牢网络安全防线。