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的特性，支持流量接入和一定的南北向流量服务治理。比如熔断，限流，灰度，重试等等。

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