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