基于 Kubernetes 构建多集群的流水线

Posted 2021-10-06 过往记忆

基于Kubefed的多集群管理实践

多集群场景

主要分以下几个方面：

1）高可用低延时：应用部署到不同的集群去做高可用

2）容灾备份：特别是针对于数据库这类的应用 在a集群对外提供服务的同时给b集群做一次备份 这样在发生故障的时候 可以无缝的迁移到另一个集群去

3）业务隔离：尽管kubernetes提供了ns级别的隔离，你可以设置每个ns各自的使用的cpu 内存 甚至可以使用network policy配置不同ns的连通性 有一个更加彻底的物理隔离的环境依然是被需要的，避免业务之间的互相影响

4）避免厂商锁定：混合云场景下，企业希望可以选择多个公有云厂商和私有云方案，避免受限于单一云厂商，降低一定成本。

第三个是应用的异地多活，避免一个region的断电造成业务的不可用情况，实现不把鸡蛋放在同一个篮子。第四个是为了区分开发测试环境，把这些环境部署到不同的集群。最后一个是提高集群的拓展性，突破单一集群的节点上限。

多集群现有的解决方案

其实最简单的方式就是使用多个kubeconfig来分别管理不同的集群，包括其他一些其他产品也是这么做的，但是kubesphere还是想以一种更加cloud native的方式去管理多个集群。于是kubesphere先调研了一些已有的解决方案。

总体来说分为两个方向，第一个是偏向控制层的资源分发，比如k8s社区的federation v1 v2, 现在v1已经被弃用了，一会儿会详细介绍这两个项目。以及argocd/fluxcd ，这类场景是在流水线中实现应用的分发。第二个是致力于实现多集群之间的pod网络网络联通性。

Federation V1

上图是federationv1的架构图，可以看到有额外的apiserver(基于kube-apiserver开发) controller manger ，下面是被管控的集群。

上图是一个replicaset的示例，与普通的rs区别就是多了一些annotation ，里面主要引入了单独的apiserver， 带来了额外的维护成本。我们都知道k8s里一个资源是通过group/version/kind确定的， 但是v1里面gvk绑定导致对不同版本的集群api兼容性很差。

只支持特定的一些资源的联邦

Annotation 让整个resource过于臃肿设计之初未考虑rbac 无法提供跨集群的权限控制

Kubefed(Crd + Controller)

Kubefed 核心是一个基于crd + controller 的设计 ，用户在管理集群创建一个custom resource 定义，这个资源需要被分发到哪些集群以后会有对应的controller 做这个工作。

上图是它的架构图，可以看到 一个crd资源主要由三部分组成 template placement override 通过结合type configuration， 可以支持多个版本的资源，提高了集群之间的版本兼容性，同时在设计之初也考虑到了多集群的服务发现调度等。

上图为联邦资源的示例，例如deployment 在kubefed对应federateddeployment spec里面的template就是原来的deployment对应的yaml ；placement则表示这个deployment需要被下放到哪些集群 ；override可以通过不同的集群设定不同的配置， 例如 deployment的镜像tag 副本数等等。

Kubernetes with Kubefed

这里我们定义了两个概念：host集群指的是装了kubefed的集群，这是所有操作访问的入口，属于control plane；member集群指的是被管控集群 二者通过kubefed实现了联邦。

KubeSphere多集群架构

上图是KubeSphere整个多集群的架构，通过kubefed实现联邦化以后 ，所有的管理操作界面都集中在了左边的host集群上，在多租户的权限这块 也是改造成了crd ，通过Kubefed联邦化把租户相关的crd下放到member集群 。这里可能就会有用人会质疑了，为何不直接在host集群统一做认证授权以后再操作member集群， 这里其实当时在设计的时候也考虑过这种做法 ，并且我们发现rancher也是这么做的 ，但是考虑到host集群作为一个中心化的管理层有挂掉的可能 ，因此把租户这类资源下放到member集群以后 ，依然可以在发生宕机的时候登陆member集群进行业务发布， 提高了平台的灾备能力。

因此对于一个用户这样的资源来说，可以看到在图中host集群和member集群都存在。在一个API请求来到以后，会统一在host集群进行认证 ，通过以后再转发到member集群进行授权 ，对于host集群对于member集群网络不可达的私有场景下 kubefed是没办法做到联邦的，因此我们基于chilsel开源了tower 做了一个隧道。

统一多集群/单集群管理视角

在kubesphere里面一个租户就是一个workspace ，一个租户可以为其分配指定的某些集群 ，也可以限制其cpu和内存的配额 ，一个租户既可以像从前那样创建一个单集群的ns ，也可以在多集群下创建一个联邦的ns。不管是单集群场景还是多集群场景，我们统一了其管理视角 对于用户来说都是一个入口 解决了管理上的难题。

Tower 提供私有云场景下的集群代理能力

前面有提到对于host集群到member集群网络不可达的情况下，目前kubefed还没有办法做到联邦，也就是没办法从host集群推送deployment到member集群。因此 kubesphere基于chisel开源了tower 实现了私有云场景下集群联邦管理 ，tower分为server和agent，用户只需要在私有集群创建一个agent， agent通过server的地址建立一个隧道， server端再为这个隧道代理请求到member集群的apiserver ，再为其分配一个kubeconfig ，就可以实现集群联邦。

多集群下的流水线设计与实现

KubeSphere & Devops

这里先简单介绍一下KubeSphere 与Devops的关系 ：Devops自身是KubeSphere可以选择安装的一个组件 ，其中里面集成了Jenkins 以及内置的模板和插件，你可以通过图形化的方式创建一个流水线，并且租户之间也做了隔离。

单集群流水线

我们先来看看单集群下一个传统的流水线流程：首先研发push代码到仓库以后 ，Jenkins会通过webhook出发一次构建 以及push镜像的过程， 最终再通过一些cd插件或者kubectl 把代码库的yaml部署到k8s里去 ，这里我们默认k8s里的一些yaml是与代码放在一起的。

多集群下的Devops改造

前提我们提到 Kubefed里面核心的多集群联邦是通过crd和controller来实现的，而在2.1版本以及之前 KubeSphere则是前端通过后端转发直接调用了Jenkins的API。这种命令式的API肯定是不适合云原生的场景的 ，因此3.0 Devops模块重点改造成了声明式的API ，前端只需要告诉后台它想要什么 ，至于如何实现则完全交给controller去做。

在图片里可以看到 主要crd有三种：分别是devpsproject这个对应k8s的ns  ，凭证这个主要死类似于dockerhub的token以及kubeconfig这类敏感信息 ，然后是pipeline ，前端创建custom resource以后， 这个时候K8s的controller会watch到pipeline 这个资源的创建, 然后对接Jenkins 触发对应的ci/cd。

Devops技术架构

多集群场景下 devops与federation类似，你可以选择性的在host集群或者member集群启用devops，然后在host集群创建一个federatedpipeline 分发到各个环境 独立进行ci/cd互不干扰，也可以在host集群ci ，然后通过cd 把应用部署到各个集群上去。

下面我将介绍两个实际情况中客户遇到的场景：

场景1: 单个流水线部署应用到Dev/Staging/Production环境

第一个是在单个pipeline里面部署应用到开发staging 生产环境，图片里是这个流水线的流程，第一个则是checkout 获取代码 ，然后跑单测，你也可以选择性的集成sonarqube进行代码分析 ，然后对镜像build/push ，然后一开始会把应用部署到测试集群进行测试，验证没问题以后再部署到staging环境， 最后则是生产环境。

这里展示了具体的流水线定义，其中的每一步都可以通过图形化的方式进行编辑 ，这大大降低了用户的Jenkins file的学习成本 ，也让整个平台更加易用。

增加流水线审批环节

前面我们提到部署到测试环境以后是需要验证的 ，不能直接再部署到其他环境 ，因此这里平台增加了审批功能 ，只有管理员点击同意以后 ，才能进行下一步的部署。

场景2: 单个流水线一键部署应用到多个集群

场景2比较适用于应用的多集群部署，前面几步都跟之前比较类似，最大的区别就是最后一步直接通过apply yaml到host集群，这里为了直观我截取了Jenkins file的一部分内容 ，这个yaml本质上是一个federated deployment这样的crd，通过host集群的kubefed 直接下放到member集群，这样就减少了对member集群的权限的依赖。

Roadmap

• 对接原生的Kubernetes API(Karmada)：目前来说Kubefed API还是太多了，每一个资源都需要一个API，尽管我们已经做了一定的屏蔽，但对于二次开发来说还是有一定难度，所以我们还是比较倾向去兼容k8s原生API，因为去年还没有Karmada项目，因此我们只能用KubeFed项目。如何从Kubefed迁移到Karmada是我们比较关心的，也希望后续能够与Karmada社区加强合作。
  

• 多集群服务发现

• 多集群之间的调度