Multi-Cluster Ingress

什么是Multi-Cluster Ingress?

在了解MCI(Multi-Cluster Ingress) 以前，咱们先看看什么是Single Cluster Ingress。

Ingress是现有的各类负载均衡器的Kubernetes抽象。例如，有本地负载平衡器，Amazon ELB / ALB，Google Cloud Platform负载平衡器，Digital Ocean负载平衡器，此列表不胜枚举。用户只需编写一个Ingress规范，而后由IngressController负责配置负载均衡器。配置后，将为用户提供一个IP地址，能够在其中访问其服务。

MCI与SCI相同的原理；可是，结果负载均衡器配置为将traffc路由到多个Kubernetes集群上的服务。此负载均衡器的建立仍由单个ingress规范驱动，而且仍会为客户端使用生成单个IP地址。

MCI，也能够叫作Global Ingress。

为何咱们须要Multi-Cluster Ingress?

须要MCI的理由不少，可是最重要的是如下几点：

• 高可用。首先若是咱们把一个核心应用部署在一个单独的集群中，一旦该k8s集群故障，那么就很是可能致使核心应用的不可用。咱们的基础架构不能彻底依赖公有云的服务，即便可能你使用的是公有云的托管k8s集群。咱们的架构要有足够的弹性应对单集群故障。
• 可伸缩性。目前单K8s集群支持的最大的节点数5000+，固然阿里经过fork代码，通过一系列的优化，作到单集群支持10000+节点。可是，这样的坏处也一样明显，须要内部维护分支。那么经过MCI，就能够很好的分而治之。
• 避免锁定。愈来愈多的企业采用多云的战略，MCI帮助咱们在更高的维度，解决多云融合。咱们须要作的可能只是在多云之间经过专线保证网络的稳定和高可用。

MCI如何实现？

实现的方案有不少种，咱们简单介绍几种方案。

GCP MCI实现方案

Ingress for Anthos 是在外部 HTTP(S) 负载平衡的架构基础上构建的。HTTP(S) 负载平衡是一个全球分布式负载平衡器，全球 100 多个 Google 接入点 (PoP) 都部署了其代理。这些代理位于 Google 网络的边缘，靠近客户端。负载平衡器 VIP 以任播 IP 地址的形式通告。来自客户端的请求会被冷土豆式路由到 Google PoP，这意味着互联网流量会流向最近的 PoP，并尽快到达 Google 骨干网络。

经过在边缘终止 HTTP 和 HTTPS 链接，Google 负载平衡器可在流量进入数据中心或区域以前肯定后端可用性，从而肯定路由流量的位置。这样可以让流量采用最高效的路径从客户端传入后端，同时还能兼顾后端的运行情况和容量。

Ingress for Anthos 是一款ingress流量控制器，它使用网络端点组(NEG) 对外部 HTTP(S) 负载平衡器进行编程。建立MultiClusterIngress资源时，GKE 会部署 Compute Engine 负载平衡器资源，并在各个集群中将相应的 Pod 配置为后端。NEG 用于动态跟踪 Pod 端点，以便 Google 负载平衡器拥有一组正常运行的适当后端。

在 GKE 的各集群中部署应用时，Ingress for Anthos 可确保负载平衡器与集群中发生的如下事件同步：

• 使用适当的匹配标签建立 Deployment。
• Pod 的进程终止且运行情况检查失败。
• 从后端池中移除集群。

Ingress for Anthos 会更新负载平衡器，使其保持一致。

Yggdrasil

Yggdrasil是一个开源工具，用于容许咱们的服务在AWS中运行的多个Kubernetes集群之间实现负载均衡。它充当Envoy控制平面，从Kubernetes Ingress资源生成配置。 Yggdrasil与Ingress控制器无关，容许它使用现有资源。

MCI要求能够很是快速地建立，更新和删除Ingress，所以咱们须要可以应对这种动态环境的产品，而Envoy因为其动态配置功能，熔断，运行情况检查等而彷佛是理想的选择。

从一个小型的Envoy群集开始，该群集针对每一个Ingress进行了静态配置，但愿在多个群集之间实现负载平衡。 Envoy将在与Ingress中定义的主机相同的主机上进行侦听，并将每一个Ingress负载均衡器配置为给定主机的地址。

总结

若是是自研一套MCI，应该首选Envoy做为代理，正如上面说到的，Envoy动态配置，包含了限流等丰富的功能，已经成为Service Mesh 数据层事实上的标准。随着Envoy支持经过wasm的方式编写插件，将来咱们将会更加方便的扩展Envoy的功能。

此外Envoy支持Zone aware 的负载均衡，这样，能够必定程度上，减小跨zone流量费用。

另外Envoy集群的部署应该选择k8s容器化部署，理由以下：

• 更加云原生，方便与其余云原生产品结合。
• 管理和升级很是方便。
• 整个容器网络flat，起码是个大趋势，其实目前全部公有云已经拉平容器网络。此时能够充分利用容器网络，直接转发，无需iptables。
• 能够部署成边缘节点（daemonset部署），这样不只可用性加强，并且会随着节点的增长而增长Envoy的实例数目。

最后，咱们能够充分利用Envoy的特性，支持流量接入和必定的南北向流量服务治理。好比熔断，限流，灰度，重试等等。

也许你不只仅须要一个流量接入，更须要一个网关