扫码阅读
手机扫码阅读

神助攻网红项目一线牵:顶级云原生项目 KubeVela 插件仓库支持 GitLab 了!

299 2023-09-07

肖晟鹏

专业踩坑的 bug工程师


啥是 KubeVela 啊??

两个月前的某一个普通的周一,Leader 突然找到我,说最近有一个开源的项目,叫 KubeVela,有点儿意思,不妨去玩玩看。

当时的我那叫一个一脸懵逼,我对 OAM 的了解可称得上是 0 认知啊! 啥是 KubeVela 啊??


没办法,Leader 要求搞,那就搞呗,老调研(踩坑)人了。

好家伙,这不调研不知道,一调研吓一跳!KubeVela 可不是一个小项目。

下面就是我当时的调研报告

Part 1 : 什么是 KubeVela

KubeVela 是一个基于 Go 语言开发的云原生平台级开源项目,在去年 11 月中旬正式发布。

/ KubeVela Logo

这套系统诞生自 2019 年年底阿里云联合微软共同推出的 Open Application Model(简称OAM)模型

在不断演进和迭代中,KubeVela 融合了大量来自开源社区(尤其是微软、字节跳动、第四范式、腾讯和满帮集团的社区参与者们)的反馈与贡献。

最终在 2020 年 云原生技术“最高盛宴” KubeCon 北美峰会上,CNCF 应用交付领域小组(CNCF SIG App Delivery) , Open Application Model (OAM) 社区,以及来自阿里云、微软云的 OAM 项目维护者们在演讲中共同宣布了 KubeVela 开源项目的正式发布。

KubeVela 项目在官宣后得到了整个云原生生态的持续关注。

仅仅在发布后的第四天,KubeVela 就登上了 Go 语言的开源趋势榜榜首。

Part 2 : 什么是 CNCF

CNCF,全称 Cloud Native Computing Foundation(云原生计算基金会)。

该组织有着这样一个口号:

坚持和整合开源技术来编排容器作为微服务架构的一部分 ,其作为致力于云原生应用推广和普及的一支重要力量,不论您是云原生应用的开发者、管理者还是研究人员都有必要了解。

CNCF 作为一个厂商中立的基金会, 致力于 Github 上的快速成长的开源技术的推广,如:

Kubernetes、Prometheus、Envoy 等。

CNCF 还帮助开发人员更快更好的构建出色的产品。

/ CNCF 的全景图

... ...

... ...

... ...

巴拉巴拉调研了一大堆,

Leader 看着我给的调研报告,

皱着眉头说:"硝酸铜(网名)啊,你这写的不行啊,它到底解决了啥问题啊?"


KubeVela 到底解决了啥问题?

问题其实很明显,只要是刚接触 Kubernetes 的用户就能够体会到: Kubernetes “太复杂了”!

复杂的 Kubernetes

我明明 只是想部署一个简单的应用,结果 却要需要去学习 Kubernetes 中的核心概念与体系。

如:

Pod、Sidecar、Service、资源管理、调度算法和 CRD 等等。

上手难度太大了。

Kubernetes 为啥对小白如此不友好呢?

这是因为 Kubernetes 中的核心概念与体系 主要是面向平台团队而非最终用户设计的

缺乏面向用户的设计 不仅

  • 带来了陡峭的学习曲线

  • 影响了用户的使用体验

  • 拖慢了研发效能

甚至

在很多情况下还会引发错误操作乃至生产故障(毕竟不可能每个业务开发人员都是 Kubernetes 专家)

这一点我可是深受体会。

就在不久前,我刚为客户搭好了一套 Kubernetes 环境,高可用多集群,3个集群,都是3个 Master节点,3个 Work 节点的配置,并且做了污点。

但是之后客户就面临一个很尴尬的问题:不会用。

然后我的噩梦就开始了,一打开微信就是客户的提问:

  • Pod 怎么启动不起来了?

  • Volume 怎么没有挂载上?

  • Helm安装的应用怎么启动不起来?

  • 服务如何调度?

  • Kubernetes 资源清单怎么写?

其实每次都是因为客户的团队中缺乏 Kubernetes 的知识。

所以出了问题往往不知道如何定位,写配置时写错或者不知道怎么写。

毕竟不是所有的团队中都有 Kubernetes 专家。

小白友好的 KubeVela

在 Kubernetes 如此难上手的情况下, 这时候就需要:

  • 一个简单、易用、又高可扩展的云原生应用管理工具。

  • 一个可以让开发者以极低的上手成本在 Kubernetes 上定义与部署应用的上层平台。

而这就是 KubeVela

使用与不使用 KubeVela,我们在这里来 一个直观点的比较:

#1

不使用 KubeVela

比如我们这里要部署一个 nginx,在 Kubernetes 中先定义资源清单:

apiVersion: apps/v1kind: Deploymentmetadata: name: my-nginxspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80---apiVersion: v1kind: Servicemetadata: name: service-nginx labels: app: nginxspec: type: ClusterIP selector: app: nginx ports: - port: 80 targetPort: 80---apiVersion: networking.k8s.io/v1kind: Ingressmetadata: name: ingress-nginxspec: rules: - host: dcone.digitalchina.com http: paths: - path: / backend: serviceName: service-nginx servicePort: 80

然后使用 kubectl 工具,通过 kubectl apply -f xxx.yaml 部署。

并且应用拉起之后,如果要管理这个应用,比如删除这个应用, 需要使用 kubectl 工具去一个一个删除 Deployment,Service 和 Ingress。

#2

使用 KubeVela

如果使用 KubeVela,使用 CLI 命令行部署,先定义一个应用部署定义,比如:

apiVersion: core.oam.dev/v1beta1kind: Applicationmetadata: name: nginx-appspec: components: - name: nginx-server type: webservice properties: image: nginx:latest port: 80 traits: - type: ingress-1-20 properties: domain: dcone.digitalchina.com http: "/": 80    

然后通过 CLI 命令 vela up -f xxx.yaml 即可拉起 nginx 应用。

并且应用中的各个组件是管理到一起的,使用 vela ls 可以看到:

比如我这里想要删除一个拥有多个组件的应用,例如上图中的 web-demo 应用, 只需要执行 vela delete web-demo 即可删除所有的该应用相关的 Kubernetes 资源。

不仅如此, KubeVela 还支持 Terraform,通过部署文件对云上资源进行编排,比如拉起阿里云上的 ECS 资源等。

对用户屏蔽了底,对于最终用户来说, KubeVela 的上手难度更小,更加直观。

发现空白

玩了几天 KubeVela 之后,我们团队发现 一个有意思的情况:

KubeVela 是支持 addon (插件)的,addon 能给 KubeVela 环境带来模块定义,应用等资源。

但是当前版本(1.2.0)插件太少,难以满足用户需求。

所以我们通过官方文档说明,编 写了自己的 addon

当时我们是将 addon 保存在公司的 Gitlab 仓库里面的,但是当我们想引入 addon 的时候,打开页面傻眼了:

插件仓库竟然只支持 Github 和 Aliyun OSS!

/ 插件仓库只支持 Github 和 Aliyun OSS

(Ps: 截图的时候 KubeVela 已经出 1.3.0 版本了,增加了 Helm 和 Gitee 的支持)

无法将保存在私有代码仓库 Gitlab 中的插件安装到 KubeVela 中,只能通过 CLI 命令行工具将代码 clone 下来 enable addon。

用户体验不好,并且最终用户不一定会使用 CLI 命令行,页面操作会更加直观。

诶,这个时候我们灵光一闪!

既然没有,那么 我们是不是能够自己把这个功能开发出来?

然后提交一个 pr 给 KubeVela,这样我们团队也参与了顶级云原生开源社区 CNCF 的 Sandbox 项目,开源精神嘛!

抓住机会


说干就干!


不过干之前,我们还询问了 KubeVela 官方是否有计划增加 addon 支持 Gitlab 的功能。


因为我们在拉取代码后发现提交记录太频繁了,今天的代码里还没有登录,明天再看已经有 RBAC 了。。。。

这张图中可以看到我们的 pr 已经被合并了,Feat(lang): add addons gitlab support (#3543))

还好他们说没有计划,但是鼓励小伙伴贡献代码,addon 支持 gitee 的代码就是招行小伙伴提供的。

明白了,我们就是神码小伙伴了,放开手弄吧!

经过一周时间的开发,我们团队成功的提交了一个 pr,并且 KubeVela 那边也采纳了该 pr,将其合并了!!!

在此附上 pr 链接:

https://github.com/oamdev/kubevela/pull/3543

关于这个功能是如何开发的,

KubeVela 源码应该如何入手,

pr 应该如何提交,

请继续关注我们的文章,

后面我们会陆续更新之后的故事~

想要了解更多,点击 查看原文