Kubernetes+Federation打造跨多云管理服务

Kubernetes日渐普及，在公有云、私有云等多个环境中部署kubernetes集群已是常规做法，而随着环境的复杂多样和集群数量增长，如何高效地管理这些集群成为新的问题。于是跨多云管理服务应运而生。

华为云高级工程师Fisher在Cloud Native Days China 2019杭州站发表了名为《Kubernetes+Federation打造跨多云管理服务》的议题，介绍了基于Federation的多云管理现状及未来计划。本文整理自Fisher现场分享实录。

大家好，我是华为云的Fisher。今天和大家分享基于Kubernetes+Federation打造跨多云服务。跨多云概念在2018年比较火，相信大家或多或少都听说过，今天主要介绍如何打造跨多云管理，包括公有云和私有云。

首先介绍场景——PAAS混合云典型场景。它的需求第一是高可用，业务负载从集群故障中快速恢复；第二是资源容量溢出，单个集群的扩容速度或者是机房的机器扩容速度跟不上应用扩容速度，利用多云可进行快速扩容；第三是避免厂商绑定，服务只是在一家云厂商里，假如厂商宕机服务就会中断，而在多云上更加保险；第四就是资源池划分，用于私有云和公有云，数据根据敏感程度分布到线上或者线下。

这4个需求，也是跨多云管理服务主要解决的问题。

如上图场景，就是我刚刚所说的私有云和公有云联动的状态。运维人员统一应用交付。对于APP用户来说，是一个平面，可以进行统一访问控制。

V1版本

接下来和大家一起看看Federation项目以及Multicluster SIG的发展历程。

Kubernetes Federation发展历程中，15—17年是前期的V1版本。如下图所示，上面是管理面，下面是被管理的集群。Federated APIServer 兼容Kubernetes的API，通过Federated Controller驱动，将对象同步到各集群。

上图为V1中RepicaSet的配置，把联邦的所有配置信息都写到annotations里，整个创建流程与Kubernetes类似。配置信息先到Federated APIServer，再通过Federated Schduler调度，最后通过Federated Controller把应用创建到各子集群。Federated Schduler会根据各集群的配置比重与集群中资源的使用情况进行综合调度。

这个版本的问题是：

• 联邦层重新实现K8S API ——导致对象携带许多Federation专属的Annotation；

• 缺少独立的API对象版本控制——K8S Deployment GA，但是Federation v1中的Deployment仍是Beta；

• 原封不动映射K8S API——联邦层对象在调度、生命周期管理等方面可做的增强点很受限；

V2版本

Federation V2版本，吸取V1的教训做了很多改进。架构上采用了流行的CRD+Controller模型，其可以运行在任意Kubernetes集群中。把Federation专用的Annotation剥离出来作为独立的API对象，通过CRD来定义，将K8S对象封装到Federation API对象里，这样不会影响Federation层API的演进。

V2版本整体架构如上图，有4种类型的CRD：CLuster，Type，Schedule，DNS。

Cluster configuration

首先看集群注册，通过Kubefed2 join向联邦添加集群，Controller读取集群的Context信息，转化为Cluster Registry项目定义的Kubernetes Cluster API并保存。Cluster Registry项目对Cluster API对象标准化和增强，将作为后续多集群发展的基础模块，管理了member集群的API Endpoint及认证信息等。

Type configuration

再介绍一下Type Configuration，其定义了Federation可以处理哪些资源对象(在v1版本中靠独立APIServer来过滤)，例如使Federation处理Deployment，就创建一个Deployment Type Configuration，其中包含三个比较重要的点：

① Template：Federated API 中封装的K8S对象

② Plocement：配置对象实例分布到哪些集群

③ Overider：指定集群中的特定字段定制化，用于解决不同的云厂商之间的配置差异。

Schedule

调度的关键是配置了集群的比重，比重决定了调度时实例的分布。主要分为按权重分配和按资源利用情况分配。

MultiClusterDNS

上图是服务发现—Multicluster DNS。服务发现主要基于Federation的设计规则，即认为多个集群之间的网络不一定是通的，因此现在主要是把服务发现的规则配置在华为的DNS服务器上，多个集群通过DNS实现服务发现。

未来计划

后续我们打算结合Istio实现K8S多云上多集群的流量治理。第一种方案如下图，这要求底层是互通的，只需部署一个Istio控制面，就可以watch所有集群的Service。目前这个方案的限制还比较多，因为不同集群的Service网段不能冲突，现阶段方案还在规划中。

Istio还有如下图所示的另外一种方案：每个集群都部署一个Istio控制面板，把其他集群的服务配置成本集群的外部服务，跨集群群服务类似Istio访问外部服务，显然配置是比较繁琐的，当前也在规划中。

相关服务请访问：https://support.huaweicloud.com/cce/index.html?utm_content=cce_helpcenter_2019