OpenKruise ：Kubernetes背后的托底

最新推荐文章于 2024-11-12 20:46:17 发布

工业甲酰苯胺

最新推荐文章于 2024-11-12 20:46:17 发布

阅读量937

点赞数 25

文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/dsgdauigfs/article/details/135817055

版权

OpenKruise是一个补充Kubernetes在应用部署、升级、防护和运维方面不足的工具，提供增强的Workloads、应用旁路管理、高可用性防护和高级运维功能，如原地升级、镜像预热和定制化调度策略。文章介绍了其核心能力、安装部署步骤和升级注意事项。

摘要由CSDN通过智能技术生成

一、诞生背景

Kubernetes 自身提供的应用部署管理功能，无法满足大规模应用场景的需求，例如应用发布时的原地升级策略，流式扩容，缩容顺序控制等等。所以OpenKruise的出现弥补了 Kubernetes 在应用部署、升级、防护、运维等领域的不足。

二、 OpenKruise介绍

核心能力介绍，帮助快速入门openkruise。

2.1 架构预览

OpenKruise 的功能都是通过 Kubernetes API 来提供的。

Kruise-manager ：运行着 controller 和 webhook的中心组件，它通过 Deployment 部署在 kruise-system 命名空间中，同样它们之间采用 leader-election 的方式选主，同一时间只有一个提供服务，达到高可用的目的。除了 controller 之外，kruise-controller-manager-xxx 中还包含了针对 Kruise CRD 以及 Pod 资源的 admission webhook。Kruise-manager 会创建webhook configurations 来配置哪些资源需要感知处理、以及提供一个 Service 来给 kube-apiserver 调用。

kruise-daemon：这是从 Kruise v0.8.0 版本开始提供的一个新的 daemon 组件。它通过 DaemonSet 部署到每个 Node 节点上，提供镜像预热、容器重启等功能。

三、核心能力

OpenKruise 是一个基于 Kubernetes 的扩展套件，主要聚焦于云原生应用的自动化，比如部署、发布、运维以及可用性防护。OpenKruise 提供的绝大部分能力都是基于 CRD 扩展来定义，它们不存在于任何外部依赖，可以运行在任意纯净的 Kubernetes 集群中。核心能力包括：

增强版本的Workloads: 比如 CloneSet、Advanced StatefulSet、Advanced DaemonSet、BroadcastJob 等。它们不仅支持类似于 Kubernetes 原生 Workloads 的基础功能，还提供了如原地升级、可配置的扩缩容/发布策略、并发操作等。

应用的旁路管理： OpenKruise 提供了多种通过旁路管理应用 sidecar 容器、多区域部署的方式，“旁路” 意味着你可以不需要修改应用的 Workloads 来实现它们。赋予单一 workload 的多区域和弹性部署的能力。

高可用性防护：目前它可以保护你的 Kubernetes 资源不受级联删除机制的干扰，包括 CRD、Namespace、以及几乎全部的 Workloads 类型资源。

高级的应用运维能力：OpenKruise 也提供了很多高级的运维能力来帮助你更好地管理应用。你可以通过 ImagePullJob 来在任意范围的节点上预先拉取某些镜像，或者指定某个 Pod 中的一个或多个容器被原地重启。

以下将对常用场景功能进行介绍。

3.1 丰富的调度策略

WorkloadSpread能够将workload的Pod按一定规则分布到不同类型的Node节点上，赋予单一workload多区域部署和弹性部署的能力。

常见的一些规则包括：

水平打散（比如按host、az等维度的平均打散）。

按指定比例打散（比如按比例部署Pod到几个指定的 az 中）。

带优先级的分区管理，比如：优先部署到ecs，资源不足时部署到eci；优先部署固定数量个pod到ecs，其余到eci；定制化分区管理，比如：控制workload部署不同数量的Pod到不同的cpu架构上；确保不同的cpu架构上的Pod配有不同的资源配额。

每一个WorkloadSpread定义多个区域（定义为subset），每个subset对应一个maxReplicas数量。WorkloadSpread利用Webhook注入subset定义的域信息，同时控制Pod的扩缩容顺序。

3.2 缩容顺序控制

pod 的删除场景可通过PodDeletionCost进行控制：较小 pod-deletion cost < 较大 pod-deletion cost

controller.kubernetes.io/pod-deletion-cost 是从 Kubernetes 1.21 版本后加入的 annotation，Deployment/ReplicaSet 在缩容时会参考这个 cost 数值来排序。

用户可以把这个 annotation 配置到 pod 上，值的范围在 [-2147483647, 2147483647]。它表示这个 pod 相较于同个 CloneSet 下其他 pod 的 “删除代价”，代价越小的 pod 删除优先级相对越高。没有设置这个 annotation 的 pod 默认 deletion cost 是 0。

CloneSet 已经支持该特性。其他 native workload 需 kubernetes version >= 1.21。且 1.21 版本需要显式开启 PodDeletionCost feature-gate，自 1.22 起默认开启。

在openkruise中，我们可以配置WorkloadSpread，借助 APIServer PodDeletionCost 特性，WorkloadSpread 利用 webhook 向Pod注入域规则，从而控制缩容顺序。

3.3 指定Pod缩容

当一个 CloneSet 被缩容时，支持用户指定一些 Pod 来删除。这对于 StatefulSet 或者 Deployment 来说是无法实现的，因为 StatefulSet 要根据序号来删除 Pod，而 Deployment/ReplicaSet 目前只能根据控制器里定义的排序来删除。

CloneSet 允许用户在缩小 replicas 数量的同时，指定想要删除的 Pod 名字。参考下面这个例子：

apiVersion: apps.kruise.io/v1alpha1

kind: CloneSet

spec:

# ...

replicas: 4

scaleStrategy:

podsToDelete:

- sample-9m4hp

当控制器收到上面这个 CloneSet 更新之后，会确保 replicas 数量为 4。如果 podsToDelete 列表里写了一些 Pod 名字，控制器会优先删除这些 Pod。对于已经被删除的 Pod，控制器会自动从 podsToDelete 列表中清理掉。

如果你只把 Pod 名字加到 podsToDelete，但没有修改 replicas 数量，那么控制器会先把指定的 Pod 删掉，然后再扩一个新的 Pod。

3.4、原地升级

原地升级是 OpenKruise 提供的核心功能之一。目前支持原地升级的 Workload：

CloneSet
Advanced StatefulSet
Advanced DaemonSet
SidecarSet

当我们要升级一个存量 Pod 中的镜像时，这是重建升级和原地升级的区别：

重建升级时我们要删除旧 Pod、创建新 Pod：

Pod 名字和 uid 发生变化，因为它们是完全不同的两个 Pod 对象（比如 Deployment 升级）

Pod 名字可能不变、但 uid 变化，因为它们是不同的 Pod 对象，只是复用了同一个名字（比如 StatefulSet 升级）

Pod 所在 Node 名字发生变化，因为新 Pod 很大可能性是不会调度到之前所在的 Node 节点的

Pod IP 发生变化，因为新 Pod 很大可能性是不会被分配到之前的 IP 地址的

但是对于原地升级，我们仍然复用同一个 Pod 对象，只是修改它里面的字段。因此：

可以避免如调度、分配 IP、分配、挂载盘等额外的操作和代价

更快的镜像拉取，因为开源复用已有旧镜像的大部分 layer 层，只需要拉取新镜像变化的一些 layer

当一个容器在原地升级时，Pod 中的其他容器不会受到影响，仍然维持运行

3.5 镜像预热

NodeImage 和 ImagePullJob 是从 Kruise v0.8.0 版本开始提供的 CRD。

Kruise 会自动为每个 Node 创建一个 NodeImage，它包含了哪些镜像需要在这个 Node 上做预热。

用户能创建 ImagePullJob 对象，来指定一个镜像要在哪些 Node 上做预热。

注意，NodeImage 是一个偏底层的 API，一般只在你要明确在某一个节点上做一次预热的时候才使用，否则你都应该使用 ImagePullJob 来指定某个镜像在一批节点上做预热。

四、安装部署&升级

从 v1.0.0 (alpha/beta) 开始，OpenKruise 要求在 Kubernetes >= 1.16 以上版本的集群中安装和使用。

安装: 推荐使用helm方式进行安装

# 首先添加helm仓库

$ helm repo add openkruise https://openkruise.github.io/charts/

$ helm repo update

# 安装指定版本，1.5.0为当前最新的stable版本

$ helm install kruise openkruise/kruise --version 1.5.0

如果不想使用默认的参数进行安装，可以手动下载chart包进行定制化安装，例如修改 resources 限制或者配置 feature-gates，chart包下载地址参考：Usage | charts。

升级：通过helm方式升级

# Firstly add openkruise charts repository if you haven't do this.

$ helm repo add openkruise https://openkruise.github.io/charts/

# [Optional]

$ helm repo update

# Upgrade to the latest version.

$ helm upgrade kruise openkruise/kruise --version 1.5.0 [--force]