共计 2497 个字符，预计需要花费 7 分钟才能阅读完成。
随着 Kubernetes 在企业中利用的越来越宽泛和遍及，越来越多的公司在生产环境中运维多个集群。本文次要讲述一些对于多集群 Kubernetes 的思考，包含为什么抉择多集群，多集群的益处以及多集群的落地计划。
VMware2020 年 Kubernetes 应用报告中指出，在采纳 kubernetes 组织中 20% 的组织运行 40+ 数目的集群。
一：为什么企业须要多集群？
- 单集群 Kubernetes 承载能力无限
首先看看官网文档中对于单集群承载能力的形容：
在 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 的管制面以及网关都须要对接内部的注册核心。具体架构如下：
