关于kubernetes:关于多集群Kubernetes的一些思考

随着Kubernetes在企业中利用的越来越宽泛和遍及，越来越多的公司在生产环境中运维多个集群。本文次要讲述一些对于多集群Kubernetes的思考，包含为什么抉择多集群，多集群的益处以及多集群的落地计划。

VMware2020年Kubernetes应用报告中指出，在采纳kubernetes组织中20%的组织运行40+数目的集群。

首先看看官网文档中对于单集群承载能力的形容：

在v1.12，Kubernetes反对最多具备5000个节点的集群。更具体地说，咱们反对满足以下所有条件的配置：
1：不超过5000个节点
2：Pod总数不超过150000
3：总共不超过300000个容器
4：每个节点不超过100个Pod

尽管当初Kubernetes曾经倒退到v1.20，然而对于单集群承载能力始终没有变动。可见进步单集群负载能力并不是社区的倒退方向。

如果咱们的业务规模超过了5000台，那么企业不得不思考多个集群。

2：混合云或是多云架构决定了须要多个集群

到目前，其实多云或是混合云的架构很广泛了。

比方企业是一个全球化的公司，提供Global服务。

或像新浪微博一样，自建数据中心 + 阿里云，阿里云用于服务弹性流量。

另外私有云并没有设想中的海量资源。比方私有云的头部客户搞大促须要很大数量机器的时候，都是须要提前和私有云申请，而后私有云提前准备的。

为了防止被单家供应商锁定，或是出于老本等思考，企业抉择了多云架构，也决定了咱们须要多个集群。

3：不把鸡蛋放到一个篮子里

即便后面两条都未满足，那么咱们是否要把所有的工作负载部署到一个集群哪？

如果集群管制面呈现故障，那么所有的服务都会受到影响。

兴许大家认为Kubernetes的管制面自身就是高可用的（三个api-server），不会有整个管制层不可用的可能。

其实则不然，咱们在生产环境中，曾经解决很屡次相似故障了。如果一个利用（个别指须要调用api-server接口）在大量地调用api-server，会导致api-server接连挂掉，最终不可用。直到找到故障利用，并把故障利用删除。

所以在生产环境中，一是须要严格控制拜访api-server的权限，二是须要做好测试，三是能够思考业务利用和基础设施离开部署。

其实单集群和多集群的抉择和”抉择一台超算 or 多台一般机器“的问题相似。起初分布式计算的倒退阐明大家抉择了多个一般机器。

多集群在以下三个方面，有着更好地体现：

实际上，能够通过两种模型来构建多集群应用程序架构

正本：将应用程序复制到多个可用性区域或数据中心，每个集群都运行应用程序的残缺正本。咱们能够依附Smart DNS（在GCP，有Global 负载均衡器的概念）将流量路由到间隔用户最近的集群，以实现最小的网络提早。如果咱们一个集群产生故障，咱们能够将流量路由到其余衰弱集群，实现故障转移。
按服务划分：依照业务相干水平，将利用部署在不同的集群。这种模型，提供了十分好的隔离性，然而服务划分却比较复杂。

实际上，社区始终在摸索多集群Kubernetes的最佳实际，目前来看次要有以下两种。

1: 以Kubernetes为核心

着力于反对和扩大用于多集群用例的外围Kubernetes原语，从而为多个集群提供集中式治理立体。Kubernetes集群联邦我的项目采纳了这种办法。

了解集群联邦的最好办法是可视化跨多个Kubernetes集群的元集群。设想一下一个逻辑管制立体，该逻辑管制立体编排多个Kubernetes主节点，相似于每个主节点如何管制其本身集群中的节点。

其实集群联邦实质上做了两件事件：

跨集群散发资源：通过形象 Templates ，Placement，Overrides三个概念，能够实现将资源（比方Deployment）部署到不通的集群，并且实现多集群扩缩。
多集群服务发现：反对多集群Service 和 Ingress。

截止到目前，联邦我的项目尚处于alpha状态，当咱们抉择落地的时候，须要一定量的开发工作。

2：以网络为核心

“以网络为核心”的办法专一于在集群之间创立网络连接，以便集群内的应用程序能够互相通信。

Istio的多集群反对，Linkerd服务镜像和Consul的Mesh网关是通过Service mesh 解决方案来实现网络连通。

而另外一种是Cilium对于多集群网络的计划。Cilium自身是一种CNI网络，该计划少了服务治理的性能。

Cilium Cluster Mesh解决方案通过隧道或间接路由，解决跨多个Kubernetes集群的Pod IP路由，而无需任何网关或代理。当然咱们须要布局好每个集群的POD CIDR。

每个Kubernetes集群都保护本人的etcd集群，其中蕴含该集群的状态。来自多个集群的状态永远不会混入etcd中。
每个集群通过一组etcd代理公开其本人的etcd。在其余集群中运行的Cilium代理连贯到etcd代理以监督更改，并将多集群相干状态复制到本人的集群中。应用etcd代理可确保etcd察看程序的可伸缩性。拜访受TLS证书爱护。
从一个集群到另一个集群的拜访始终是只读的。这样能够确保故障域放弃不变，即一个集群中的故障永远不会流传到其余集群中。
通过简略的Kubernetes secret资源进行配置，该资源蕴含近程etcd代理的寻址信息以及集群名称和拜访etcd代理所需的证书。

下面咱们讲到了两种落地多集群Kubernetes的计划，其实并不是非A即B。

比方，当咱们在落地大集群的过程中，很多公司只是用Kubernetes解决部署的问题。服务发现抉择consul，zk等注册核心，配置文件治理应用配置核心，负载平衡也没有应用kubernetes中Service。

此时联合两种计划是最佳实际。

集群联邦解决部署和公布的问题。Service mesh解决多集群流量拜访的问题。不过此时，工作负载集群中的Pod，Service mesh的管制面以及网关都须要对接内部的注册核心。具体架构如下：