作者:vivo 互联网服务器团队-Zhang Rong
Karmada作为开源的云原生多云容器编排项目,吸引了众多企业共同参与项目开发,并运行于生产环境中。同时多云也逐步成为数据中心建设的基础架构,多区域容灾与多活、大规模多集群管理、跨云弹性与迁移等场景推动云原生多云相关技术的快速发展。
一、 背景
随着vivo业务不断迁移到k8s上,集群规模和集群的数量快速增长,运维难度也急剧增加。为了构建多集群技术,我们也自研了多集群管理,但无法解决我们遇到的更多的问题。后来开始对社区相关项目做了细致的调研和测试,我们最终选择了Karmada。
主要原因如下:
- 具备对多套K8s集群的统一管理能力,业务通过服务维度去管理资源,降低容器平台的管理难度。
- 跨集群的弹性伸缩和调度能力,实现跨集群的资源合理利用,从而提升资源利用率并节约成本。
- Karmada完全使用了K8s原生的API,改造成本低。
- 容灾,Karmada控制平面与member集群解藕,集群异常时支持资源重新分配。
- 可扩展性,如可以添加自研的调度插件和添加自研Openkruise解释器插件等。
在我们探索怎么使用Karmada的同时,我们也遇到了Karmada自身运维的问题。
社区部署工具较多,需要用户自己选择。当前用户部署方式如下:
-
Karmadactl
-
Karmada charts
-
二进制部署
-
hack目录下脚本
对于上面的几种工具,在Karmada的社区开展了问卷调研,并生成了统计报告。
主要总结如下:
-
社区部署工具较多,需要用户自己选择。
-
部署脚本也存在缺陷,需要用户自己解决,github上关于这方面的提问较多。
-
黑屏化操作,没有提供k8s api操作,用户难以产品化,我们主要期望对接我们的容器平台,实现可视化安装。
-
缺少CI测试和部署工具的发布计划。
-
etcd集群缺少生产环境的关键功能点,如etcd的高可用、定期备份和恢复。
-
需要安装很多依赖插件,涉及到Karmada控制平面、Karmada的host集群和member集群。
-
缺少一键部署和配置繁琐等痛点。
针对以上问题,本文将分享Karmada-Operator的vivo实践,包括Operator的方案选择、API、架构设计和CI构建等。
二、Karmada-Operator的落地实践
2.1 Operator SDK介绍
Operator Framework 是一个开源工具包,用于以有效、自动化且可扩展的方式管理 Kubernetes 原生应用程序,即 Operator。Operator 利用 Kubernetes 的可扩展性来展现云服务的自动化优势,如置备、扩展以及备份和恢复,同时能够在 Kubernetes 可运行的任何地方运行。
Operator 有助于简化对 Kubernetes 上的复杂、有状态的应用程序的管理。然而,现在编写 Operator 并不容易,会面临一些挑战,如使用低级别 API、编写样板文件以及缺乏模块化功能(这会导致重复工作)。
Operator SDK 是一个框架,通过提供以下内容来降低 Operator 的编写难度:
-
高级 API 和抽象,用于更直观地编写操作逻辑
-
支架和代码生成工具,用于快速引导新项目
-
扩展项,覆盖常见的 Operator 用例
如上图所示,operator sdk可以基于helm、ansilbe和go构建operator,我们需根据当前的情况选择我们合适的operator框架。
2.2 方案选择
-
方案一:golang 开发Operator