各位社区的小伙伴,大家好。我是红亚科技的 CTO 卢兴民,今天给大家分享一下我们公司的团队在使用 KubeSphere 进行多集群管理,还有应用发布上的实践工作。
先介绍一下我们应用的架构。我们独立出来的这一部分服务,主要是用来为青椒课堂的学生和老师提供虚拟化的操作环境,是一个虚拟化资源调度服务。它包含了 API server、proxy、jobrunner,还有 image registry mirror。它本身有调度容器和虚拟机的能力,而调度虚拟机是直接跟 IAAS 层(比如阿里云)去做的对接。
最初我们的副本只在北京有一个集群,所以也就没有必要考虑用一个更方便的形式去部署多个集群。当时就是一个可视化的 PAAS 平台,人工操作即可。但是随着我们用户的数量变多,服务遍布全国,我们就必须做如图所示的这种多可用区的架构。
青椒课堂 region 服务部署在 KubeSphere 上,应用特点如下:
我们做多集群的管理,想达成的目标如下:
所以我们选择了 KubeSphere,满足我们所有的需求。而且在上线 QKE 3.0 之后,我们几乎可以通过点几下鼠标,在分钟级的时间内创建出来生产级别的 KubeSphere 集群、Host 集群。
这个是我们目前的使用状况。目前我们在 KubeSphere 上接入了三套阿里云 ACK 集群,进行统一纳管。目前还有一些机器没有迁移过来,我们在逐步的进行迁移工作。
我们原有的应用是在一个可视化 PAAS 平台,所以我们没有使用 kubernetes 原生的这种包管理工具。
那么我们在做应用打包的时候为什么会选择 helm 呢?主要是基于以下几点。
在应用部署上我们尝试了几个方案,最终选择了 Spinnaker 作为我们的应用发布的方案,主要是基于以下几点。
如上图所示,这是我们做好了制品绑定之后达到的效果。通过修改发布流程的启动参数,每一个组件在部署的时候都可以去选择它所对需要部署的镜像版本,以及用到的 helm 版本和所要发布的集群。
上图是我们整个应用定义的过程,首先是确定应用部署所使用的 helm 包,选取部署过程中需要使用的镜像。
右上方的第二张图的 Bake 阶段可以用来做不同集群之间的配置、差异化的管理。比如说我们在生产环境加载 values-prod.yaml 配置文件,但是每一个集群之间会有一定的差异化配置,都可以在 Bake 阶段使用 values 覆盖去进行配置。
Bake 阶段相当于是 helm 包生成一组部署到 kubernetes 集群里面的 yaml 文件,然后在 deploy 阶段进行制品绑定之后,就可以将 image 字段自动进行一个替换,部署你想要的镜像版本。
头图:Unsplash
作者:卢兴民
原文:https://mp.weixin.qq.com/s/CoufSH5LTQbob4scTtL05A
原文:KubeSphere 多集群管理大招:使用 QKE 管理多个 ACK 集群
来源:KubeSphere 云原生 - 微信公众号 [ID:gh_f5606464ef2f]
转载:著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
领取专属 10元无门槛券
私享最新 技术干货