共计 3690 个字符,预计需要花费 10 分钟才能阅读完成。
作者 | 王思宇(酒祝)
起源 | 阿里巴巴云原生公众号
背景
OpenKruise 我的项目地址:https://github.com/openkruise/kruise
OpenKruise 是什么?它是阿里云开源的云原生利用自动化治理引擎,也是以后托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 我的项目。它来自阿里巴巴多年来容器化、云原生的技术积淀,是阿里外部生产环境大规模利用的基于 Kubernetes 之上的规范扩大组件,一套紧贴上游社区规范、适应互联网规模化场景的技术理念与最佳实际。
值得一提的是,阿里外部应用的 OpenKruise 齐全来自于社区版本、代码简直完全一致。此外,OpenKruise 还被提供到了阿里云容器服务(ACK)的利用目录中,任意云上客户都能够一键装置和应用 OpenKruise。目前在 ACK 上应用 OpenKruise 的客户次要包含斗鱼 TV、申通等,而开源社区中携程、Lyft、有赞等公司也都是 OpenKruise 的用户和贡献者(参考:用户列表)。
版本回顾
从 2019 年 6 月开源伊始,OpenKruise 聚焦于云原生利用部署 / 公布治理相干畛域,扩大利用工作负载(workloads)。从最后的 Advanced StatefulSet、BroadcastJob,到“终极”的无状态利用负载 CloneSet、利用 sidecar 容器治理“利器”SidecarSet、多可用区治理负载 UnitedDeployment 等。
- CloneSet:提供了更加高效、确定可控的利用治理和部署能力,反对优雅原地降级、指定删除、公布程序可配置、并行 / 灰度公布等丰盛的策略,能够满足更多样化的利用场景。
- Advanced StatefulSet:基于原生 StatefulSet 之上的加强版本,默认行为与原生完全一致,在此之外提供了原地降级、并行公布(最大不可用)、公布暂停等性能。
- SidecarSet:对 sidecar 容器做对立治理,在满足 selector 条件的 Pod 中注入指定的 sidecar 容器。
- UnitedDeployment:通过多个 subset workload 将利用部署到多个可用区。
- BroadcastJob: 配置一个 job,在集群中所有满足条件的 Node 上都跑一个 Pod 工作。
- Advanced DaemonSet:基于原生 DaemonSet 之上的加强版本,默认行为与原生统一,在此之外提供了灰度分批、按 Node label 抉择、暂停、热降级等公布策略。
- AdvancedCronJob:一个扩大的 CronJob 控制器,目前 template 模板反对配置应用 Job 或 BroadcastJob。
以后 OpenKruise 丰盛的 workloads 简直笼罩了绝大多数通用的利用部署场景,这也是目前社区用户对 OpenKruise 的认知。但 OpenKruise 并不仅仅局限于此,以面向云原生场景的利用自动化为指标,必然不止是“部署”那么简略(当然它并不简略)。
布局一览
在 2021 上半年,OpenKruise 新版本会先围绕利用危险防控、Operator 运行时扩大、daemon 旁路扩大等方面开展,而在此之后,还有加强版本的 HPA、无代码控制器尚在排期中。
1. 危险防控
面向终态的自动化是一把“双刃剑”,它既为利用带来了申明式的部署能力,同时也潜在地会将一些误操作行为被终态化放大。在产生操作故障时正本数维持、版本一致性、级联删除等机制反而很可能导致爆炸半径扩充,例如:
- 谬误地删除一个(多个)CRD,所有对应的 CR 都被清理掉。
- 谬误地删除一个(多个)workload,其下所有 Pod 都被级联删除。
- 公布时在 workload 中配置错了策略,超过预期数量(甚至全副)的 Pod 被同时降级。
- 批量给 Node 打了一个谬误的 taint,导致下面所有 Pod 被驱赶。
- 因为各种各样起因引发的 Pod 批量被删除 ……
在理论的生产集群中存在了各种各样的高危操作,OpenKruise 打算通过一系列可选的危险防控机制来为利用最终的可用性做兜底:
- 定义 “禁止级联删除” 标签:带这个标签的 CRD、Workload 被删除时,Kruise 会校验如果尚存在 CR 或运行中的 Pod 则回绝删除。
- 定义 Pod 删除流控策略:用户能够定义一个集群中 Pod 删除的限流值,比方 1 分钟、10 分钟、1 小时、1 天等工夫窗口内最多容许删除多少个 Pod,一旦超出阈值则更多的 Pod 删除申请会被回绝(能够放大限流值解决)。
- 新增 PodUnavailableBudget(PUB)自定义资源:原生 PDB 只能限度 Pod 驱赶,无奈限度删除等操作,局限性十分大。而 PUB 将会采取对立机制,对 Pod 删除 / 驱赶 / 原地降级 等所有会导致 Pod 变为不可用状态的操作做校验,一旦某个利用的不可用数量超过(或可用数量低于)策略阈值,PUB 会回绝这个利用下更多的 Pod 操作。
- 反对 为 workload 主动生成 PUB/PDB:一般来说用户只会配置本身利用的 workload,不论应用的是原生 Deployment 还是 OpenKruise 的 CloneSet/Advanced StatefulSet,其实只是针对利用部署 / 公布的定义。咱们心愿 PUB/PDB 能逐步成为与每个 workload 配对的爱护策略,通过主动匹配生成,尽量在用户无感(或极小改变)的状况下失去欠缺的利用运行时爱护。
2. kruise-daemon
过来 OpenKruise 只是作为一个核心 kruise-controller-manager 组件运行、提供 controller/webhook 服务,因而其实对于单机侧的操作无奈染指。接下来,咱们会引入 kruise-daemon 作为单机侧组件,反对在 Kubelet 之外的旁路实现扩大:
- 新增 镜像预热:通过定义 NodeImage 和 ImagePullJob 实现每台 Node 层面须要执行预热的列表和预热状态上报,以及 ImagePullJob 来指定集群中按什么范畴来做规模化预热。
- 通过镜像预热实现 公布减速:在 CloneSet、Advanced StatefulSet 等 workload 做原地降级时,Pod 不会产生重建和飘移,依然在原先节点上做容器重建降级。因而当用户做灰度(partition)原地降级时,OpenKruise 能够提前在未降级 Pod 所在节点做新版本镜像预热,这样在后续 Pod 做降级的过程中就省去了拉镜像所破费的工夫,能够无效晋升整体利用公布的速度和效率。
- 反对 指定容器重启:目前在对 Pod 中某个容器原地降级时,Kubelet 会执行容器重建操作,咱们看到不少用户也依赖于这个能力做重启。但原地降级是必须批改 image 镜像的,是否有方法不批改镜像实现重启呢?后续 kruise-daemon 会反对此类操作,不过对于 Pod 容器启动、进行程序等需要还是无奈代替 Kubelet 实现的。
- 提供 单机调度优化:通过在调整利用 Pod 的 cgroup 零碎来实现单机侧的资源最大化利用和利用 SLO 保障。这是一个探索性的方向,目前尚不确定是否会于 2021 在社区提供稳定版实现。
3. ControllerMesh
Kubernetes 能击败 Mesos/Swarm 等对标产品、成为容器集群调度治理引擎的事实标准,其弱小而又灵便的扩大能力功不可没。Operator 既是一种非凡的利用,也是不少有状态利用的自动化管理者。而过来社区整体 Operator 趋势还停留在数量横蛮增长、周边运行时机制却无太大提高,这就导致各类 Controller/Operator 的数量和复杂性也逐步减少,变得越来越难以了解和治理。
单主问题带来的控制器单点运行,无奈负载平衡、无奈程度扩大;版本升级一次性切换、无奈灰度,A/B 测试、金丝雀等模式都无奈实现。另外控制器潜在的爆炸半径大,也没有系统性的防护、速率限度、熔断机制。其余可观测性方面的监控、追踪、度量等也都不足对立的形式。
咱们心愿设计一个计划,能提供对整个控制器运行立体的行为洞察和操作控制的能力,以及一个残缺的满足 Controller/Operator 利用各种部署治理与运行时需要的解决方案。这套计划将实现 Operator 分片运行,从而带来程度扩大、灰度降级等能力,除此之外还将会提供故障注入、更灵便的租户隔离、平安防护、可观测性等系统性的平台能力。
总结
目前版本的 OpenKruise 曾经提供了丰盛的 workloads 与部署公布策略,简直笼罩了绝大多数通用的利用场景。值此 2021“牛转乾坤”之际,OpenKruise 打出了“More than workloads”口号,在新的一年里 OpenKruise 将走呈现有的利用负载畛域,笼罩更多云原生场景、开掘更深层面的利用自动化需要。咱们欢送每一位云原生爱好者独特参加 OpenKruise 的建设,独特打造业界顶尖的云原生利用自动化引擎!
- Github:https://github.com/openkruise/kruise
- Official:https://openkruise.io/
- 钉钉交换群:钉钉搜寻群号 23330762