OpenKruise 是由阿里云于 2019 年 6 月开源的云原生应用自动化引擎,本质是基于 Kubernetes 标准扩展出来一个的应用负载项目,它可以配合原生 Kubernetes 使用,并为管理应用容器、sidecar、镜像分发等方面提供更加强大和高效的能力,从而在不同维度上通过自动化的方式解决 Kubernetes 之上应用的规模化运维和规模化建站问题,包括部署、升级、弹性扩缩容、Qos 调节、健康检查、迁移修复等等。
OpenKruise 官网:https://openkruise.io/
GitHub 项目地址:https://github.com/openkruise/kruise
OpenKruise: 阿里巴巴 双11 全链路应用的云原生部署基座
1. 内部运行的 OpenKruise 版本代码超 95% 来自社区仓库
所有通用能力,我们都会直接基于开源仓库开发和提交,然后再同步到内部环境。
社区成员为 OpenKruise 贡献的每一行代码,都将运行在阿里内部环境中。
2. 在 Kubernetes 上自动化应用程序工作负载管理
3. 双11 核心应用全面基于 OpenKruise 部署
CloneSet:(无状态应用)这是规模最大的部分,绝大部分泛电商业务都是通过 CloneSet 来部署发布。 Advanced StatefulSet:(有状态应用)目前主要是用于中间件在云原生环境的部署。 SidecarSet:(sidecar 生命周期管理)可以将定义好的 sidecar 容器动态注入到新建的 Pod 中,云上的运维容器、 mesh 容器都是通过这种机制加入到业务 Pod 中。 Advanced DaemonSet:将宿主机级别的守护进程部署到所有节点上,包括各种用于给业务容器配置网络、存储的基础组件。
如果只是控制器挂了,则应用扩缩容、发布操作全量失败。 而如果控制器逻辑存在重大 bug,比如数量或版本号计算错误,甚至可能引起业务容器大规模误删或是升级为错误的版本。
4. 主要能力
应用发布时,所有容器都要飘移重建:对于我们来说几乎无法接受,在发布高峰期如果阿里巴巴的大规模应用都在大规模重建,这是不管对于业务自身还是其他调度器、中间件、网络/存储组件都是一种灾难性的压力。 无状态应用负载(Deployment)无法灰度升级容器。 有状态应用负载(StatefulSet)无法并行升级容器。 还有很多,这里不一一列举......
发布效率大大提升。根据不完全统计数据,在大部分业务场景下原地升级至少比完全重建升级提升了 80% 以上的发布速度:不仅省去了调度、分配网络、分配远程盘的耗时,连拉取新版本镜像的时候都得益于 node 上已有旧镜像、只需要拉取较少的增量 layer。 发布前后 IP 不变、升级过程 Pod 网络不断,并且 Pod 中除了正在升级容器之外的其他容器都一直保持正常运行。 Volume 不变,完全复用原容器的挂载设备。 确保了集群确定性,使全链路压测通过后的集群拓扑为大促提供保障。
OpenKruise 已正式进入 CNCF Sandbox
Maintainer 5 位成员来自阿里巴巴、腾讯、Lyft
44 位贡献者
国内:阿里云、蚂蚁集团、携程、腾讯、拼多多...
国外:微软、Lyft、Spectro Cloud、Dsicord...
1900+ GitHub Stars
300+ Forks
后续,OpenKruise 的重点包括但不限于以下几个目标:
继续将阿里巴巴内部沉淀的通用云原生应用自动化能力输出,走可持续的三位一体发展战略。
深度挖掘细分领域的应用负载需求,比如我们正在探索针对 FaaS 场景的池化能力。
与其他相关领域的开源产品做更紧密的结合,如 OAM/KubeVela 等,打造更完整的云原生应用体系。