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

朱雀 2022-09-14 15:28 137阅读 0赞

**简介：** 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 防护依然将会导致业务中断、服务降级：

![1.png][]

*  应用 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 安全防护机制，逻辑架构如下：

![2.png][]

# 应用场景 #

*  无状态应用：比如想至少有 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 应用管理、交付扩展能力，能够面向更加规模化、复杂化、极致性能的场景。

[原文链接][Link 1]  
本文为阿里云原创内容，未经允许不得转载。

[1.png]: /images/20220828/7d13a147c47947ffb9568d57635823fc.png
[2.png]: /images/20220828/40ef4af1d58745778f50edff12f2bd2c.png
[Link 1]: http://click.aliyun.com/m/1000299540/