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

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

作者｜赵明山（立衡）

前言

OpenKruise 是阿里云开源的云原生应用自动化管理套件，也是当前托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 项目。它来自阿里巴巴多年来容器化、云原生的技术沉淀，是阿里内部生产环境大规模应用的基于 Kubernetes 之上的标准扩展组件，也是紧贴上游社区标准、适应互联网规模化场景的技术理念与最佳实践。 OpenKruise 在 2021.9.6 发布了最新的 v0.10.0 版本新增了弹性拓扑管理和应用安全防护等能力，本文将为大家揭晓 OpenKruise 是如何实现应用的可用性防护能力。

背景

应用 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）

应用场景

无状态应用：比如想至少有 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：Channel in Kubernetes Slack

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。