Kubernetes应用管理器OpenKruise之CloneSet

Posted 2023-05-04

参考技术A OpenKruise 是 Kubernetes 的一个标准扩展，它可以配合原生 Kubernetes 使用，并为管理应用容器、sidecar、镜像分发等方面提供更加强大和高效的能力。

以上在官方文档都有介绍，本文主要着重实战，先讲CloneSet，其他控制器后面会陆续更新。。。

这里使用helm来安装Kruise
1、现在kruise Chart

2、修改values.yaml,默认不用修改也行
3、执行部署

4、检查kruise部署状态

下面我们开始来使用这些管理器

CloneSet 控制器提供了高效管理无状态应用的能力，它可以对标原生的 Deployment，但 CloneSet 提供了很多增强功能。
1、我们先创建一个简单的CloneSet，yaml如下

2、部署

CloneSet 允许用户配置 PVC 模板 volumeClaimTemplates，用来给每个 Pod 生成独享的 PVC，这是 Deployment 所不支持的。 如果用户没有指定这个模板，CloneSet 会创建不带 PVC 的 Pod。

3、现在来创建一个带有 PVC 模板的例子

部署

从部署结果可以看到，每个pod都创建了一个PVC，这个是原生的Deployment不能实现的。

4、指定 Pod 缩容
当一个 CloneSet 被缩容时，有时候用户需要指定一些 Pod 来删除。这对于 StatefulSet 或者 Deployment 来说是无法实现的，因为 StatefulSet 要根据序号来删除 Pod，而 Deployment/ReplicaSet 目前只能根据控制器里定义的排序来删除。
CloneSet 允许用户在缩小 replicas 数量的同时，指定想要删除的 Pod 名字。

现在我们来修改上面例子的部署文件，指定删除 nginx-2-t55h8 这个Pod

然后更新yaml文件

现在看输入结果，已经没有 nginx-2-t55h8 这个Pod了
这个功能很实用，比如某台机器故障了，或者负载太高，你想删除指定的pod。

5、升级功能

现在我们来尝试原地升级Pod功能，把nginx镜像由nginx:alpine 升级为 nginx:latest
首先修改yaml文件，这里只粘贴出文件的修改的部分

执行升级

从输出可以看到， Container nginx definition changed, will be restarted ，Pod并没有删除在重建，而是在原来的基础上直接更新了镜像文件，并重启了服务。
原地升级减少了删除重建环节，节省了升级时间和资源调度频率。。。

6、Partition 分批灰度
Partition 的语义是 保留旧版本 Pod 的数量或百分比，默认为 0。这里的 partition 不表示任何 order 序号。

现在我将上面的例子的 image 更新为 nginx:1.19.6-alpine 并且设置 partition=3

查看结果

从输出信息我们可以看到， Update Revision已经更新为nginx-2-7b44cb9c8 ，而Pod中只有两个Pod升级了。
由于我们设置了 partition=3，控制器只升级了 2 个 Pod。
Partition 分批灰度功能完善了原生的Pod升级方式，使得升级能够进行更灵活，能够进行灰度上线。超赞。。。

7、最后再演示下发布暂停
用户可以通过设置 paused 为 true 暂停发布，不过控制器还是会做 replicas 数量管理：

以上就是整个发布暂停的演示，这个功能好处就是；我们在升级的过程中可以随时中断升级。

除此之外，CloneSet还有很多特性，例如：MaxUnavailable 最大不可用数量、MaxSurge 最大弹性数量、升级顺序、打散策略、生命周期钩子等，鉴于文章篇幅，这些特性不再演示了，有需要的可以查看官方文档。

OpenKruise 如何实现应用的可用性防护？

简介：OpenKruise 在 2021.9.6 发布了最新的 v0.10.0 版本新增了弹性拓扑管理和应用安全防护等能力，本文将为大家揭晓 OpenKruise 是如何实现应用的可用性防护能力。

前言

OpenKruise 是阿里云开源的云原生应用自动化管理套件，也是当前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀，是阿里内部生产环境大规模应用的基于 Kubernetes 之上的标准扩展组件，也是紧贴上游社区标准、适应互联网规模化场景的技术理念与最佳实践。

OpenKruise 在 2021.9.6 发布了最新的 v0.10.0 版本新增了弹性拓扑管理和应用安全防护等能力，本文将为大家揭晓 OpenKruise 是如何实现应用的可用性防护能力。

背景

在文章开始部分，我想先聊聊到底什么是“应用的可用性防护”。例如，在 Kubernetes 上面部署的 ETCD 服务，时刻要保证可用的实例数不小于 N（受限于 raft 协议的选举机制）。很多同学都会想到 Deployment 中可以设置 maxUnavailable，那不就行了吗？再说了，还会有 RS Controller 在做副本控制呢？仔细想想，Deployment 的 MaxUnavailable 是在应用滚动发布的过程中保证最小的 Pod 数量，而 RS Controller 控制器则是尽快让应用实际的福本数等于预期的副本数，并不能保证应用每时每刻的最小可用副本数。

针对上述场景，Kubernetes 原生提供的 PodDisruptionBudget（PDB）通过限制同时中断 Pod 的数量，来保证应用的高可用性。但是，当前 PDB 的能力并不全面，它只能防护 Pod Eviction 场景（例如：kubectl drain node 驱逐 node 上面的 Pod）。在如下“并发 Pod 更新/驱逐/删除”场景中，即便有 PDB 防护依然将会导致业务中断、服务降级：

• 应用 owner 通过 Deployment 正在进行版本升级，与此同时集群管理员由于机器资源利用率过低正在进行 node 缩容
• 中间件团队利用 SidecarSet 正在原地升级集群中的sidecar版本（例如：ServiceMesh envoy），同时 HPA 正在对同一批应用进行缩容
• 应用 owner 和中间件团队利用 CloneSet、SidecarSet 原地升级的能力，正在对同一批 Pod 进行升级

PodUnavailableBudget 提升应用的高可用性

Kubernetes 原生 PDB 为什么只能防护 Pod Eviction 的场景呢？首先，让我们来看看它的实现原理：PDB 通过 selector 选择了一批防护的 Pod 列表，minAvailable 则表明最小可用的 Pod 数量，pdb-controller 根据前面两个值以及线上 Pod 的 ready 状态，计算出当前时刻最多允许中断的 Pod 数量 PodDisruptionAllowd。k8s pod evictionRestful API 接口则会根据 pdb PodDisruptionAllowd 来决定接口成功还是返回 400 报错。到了这里终于真相大白了，pdb 通过 evictionRestful API 接口来实现 pod 的防护能力，所以它只能适用于 Pod Eviction 场景。

OpenKruise PodUnavailableBudget（PUB）安全防护的整体思路与 PDB 其实也大致相同，不过在关键的防护路径上面做了一些调整。Voluntary Disruption（诸如：集群管理员驱逐 Node、并发升级 Pod）主动导致 Pod 不可用的场景其实可以归纳为以下三类：

• Modification Pod.Spec 定义（CloneSet、SidecarSet 原地升级 container）
• Delete Pod（Deployment 等控制器滚动升级 Pod、直接 Delete Pod）
• Eviction API（kubectl drain node 驱逐 Pod）

OpenKruise 基于 Kubernetes Adminssion Webhook 机制添加针对 Pod Update/Delete/Eviction 的 webhook 逻辑，根据 pub 的 PodUnavailableAllowed 来实现更加全面的应用 Pod 安全防护机制，逻辑架构如下：

应用场景

• 无状态应用：比如想至少有 60% 的副本 Available

  • 解决办法：创建 PUB Object，指定 minAvailable 为 60%，或者 maxUnavailable 为 40%

apiVersion: apps.kruise.io/v1alpha1
kind: PodUnavailableBudget
metadata:
  name: web-server-pub
  namespace: web
spec:
  targetRef:
    apiVersion: apps.kruise.io/v1alpha1
    kind: CloneSet
    name: web-server
  minAvailable: 60%

• 有状态应用：最少可用的实例数不能少于某个数 N（比如受限于 raft 协议类应用的选举机制）

  • 解决办法：设置 maxUnavailable=1 或者 minAvailable=N，分别允许每次只删除一个实例或每次删除 workload.replicas - minAvailable 个实例

apiVersion: apps.kruise.io/v1alpha1
kind: PodUnavailableBudget
metadata:
  name: etcd-pub
  namespace: etcd
spec:
  targetRef:
    apiVersion: apps.kruise.io/v1alpha1
    kind: StatefulSet
    name: etcd
  maxUnavailable: 1

• 单实例应用：终止这个实例之前必须提前通知客户并取得同意

  • 解决办法：创建 PUB Object，并设置 maxUnavailable 为 0，这样 OpenKruise 就会阻止这个实例的删除，然后去通知并征求用户同意后，再把这个 PUB 删除从而解除这个阻止，然后再去 recreate

apiVersion: apps.kruise.io/v1alpha1
kind: PodUnavailableBudget
metadata:
  name: gameserver-pub
  namespace: game
spec:
  targetRef:
    apiVersion: apps.kruise.io/v1alpha1
    kind: StatefulSet
    name: gameserver
  maxUnavailable: 0

总结

Kubernetes 给用户带来极致弹性调度的同时也给应用的高可用性带来了一定的考验，PUB 是在 Voluntary Disruption 场景下的一种尝试，同时配合 OpenKruise 提供的防级联删除的能力相信能在一定程度上提升线上应用的稳定性。而针对更加棘手 InVoluntary Disruption（诸如：集群 Node 网络脑裂、vk 节点异常）导致 Pod 不可用等降低应用可用性的场景，OpenKruise 未来也会有更多的探索。与此同时，我们也欢迎更多的同学参与到 OpenKruise 社区来，共同建设一个场景更加丰富、完善的 K8s 应用管理、交付扩展能力，能够面向更加规模化、复杂化、极致性能的场景。

Github：https://github.com/openkruise/kruise
Official：https://openkruise.io/
Slack: Channel in Kubernetes Slack
钉钉交流群：扫描下方二维码或搜索群号【23330762】均可添加~

戳链接（https://github.com/openkruise/kruise），查看 OpenKruise 项目 github 主页！！

原文链接：https://developer.aliyun.com/article/793096?

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。