如何为多个 Kubernetes 集群设置全局负载均衡器

Jetstack 的工程团队介绍了如何跨多个谷歌 Kubernetes 引擎（Google Kubernetes Engine，简称GKE）集群设置全局负载均衡器，同时使用谷歌的非标准容器原生负载平衡和Google Cloud Armor 来进行 DDoS 保护。

Jetstack 的一个客户具有现成的配置环境，该环境由多个Kubernetes集群组成，并基于 DNS 路由至不同的负载均衡器 IP。他们希望整合 Google Cloud Armor 的 DDos 保护功能，并使用容器原生负载平衡来“改善流量的可见性和网络性能”。该团队经历了多个迁移阶段以引入这些功能并采用了一种自定义方式将单个 GLB 和多个 Kubernetes 集群后端绑定在一起。

在 Kubernetes 规范中，服务级别有三种不同的“负载平衡”方式，即 ClusterIP、NodePort 和 LoadBalancer，其中不包括 Ingress。Jetstack 的客户利用“LoadBalancing”服务类型，该服务类型会转换成基于底层云平台的特定 LB 实现。在 GKE 中，这由网络 LB（NLB）实现。然而，为了接受来自互联网的流量，Kubernetes 集群通常有个 Ingress，它由 GKE 中的全局 LB（global LB，简称GLB）实现。在客户之前的配置里面，AWS Route53中有基于地理位置的 IP 地址路由。根据 DNS 的查询来源，Route53 可以返回不同的IP地址。

尽管 Google Cloud Armor 配置支持3-7层网络规则，但是，谷歌的 NLB 不支持 Google Cloud Armor DDoS 保护服务。因此，切换到一个 L7 LB（全局负载均衡器，即 GLB）是必要的。在 GKE 中创建一个 Ingress 资源就可以自动创建它。作为负载均衡器，L7 GLB 给路由 URL 和 TLS 终止带来了灵活性，并把流量服务端口限制为80、8080和443。后者导致了应用程序的一些变化，该应用程序之前使用多个其他端口。在该阶段结束时还有多个 L7 负载均衡器，DNS 指向了它们的 IP 地址。

GKE 有个叫做“容器原生负载平衡”的功能，该功能允许 pod 直接接收来自负载均衡器的流量。这并不是 Kubernetes 规范的一部分，而是 GKE 中的优化，因而不能用于其他供应商托管的 Kubernetes 产品。如果没有该功能的话，从 LB 到 pod 的流量需要在 GKE 网络中绕行。其中涉及的额外网络跳跃（hop）会增加延迟。容器原生负载均衡需要创建网络端点群组（Network Endpoint Groups，简称NEG），这是一个谷歌的特定功能，它包含服务于流量的后端 pod 的 IP 地址。在迁移的第二阶段包含了这些任务。

在第三个阶段，主要的变化是使用单个 GLB IP 地址，而不是使用 DNS 返回不同负载均衡器的特定于区域的 IP 地址。Kubernetes 没有在单个 Ingress 背后包含多个集群的机制。谷歌有个测试版的工具，试图来做这件事，但是，还它还处于早期阶段。重要的是，让多个 Kubernetes 集群拥有一个 GLB（或另一个 Ingress LB）不同于多个Kubernetes集群协同工作。前者是关于使用单个端点，全局流量通过它被路由到独立的 Kubernetes 集群。而后者是关于对多个 Kubernetes 集群使用单个控制平面。在其他云中实现前者也不简单。Jetstack 团队借助 Terraform 的Google provider实现了自动化，他们分别创建了 NEG 资源和 GLB，并使用注解把它们绑定在一起。还有另一个工具致力于简化这项工作。其他公司用其它方法解决了这个问题，例如，使用一个Envoy控制平面和使用集群注册表（Cluster Registry）。

原文链接：

How Jetstack Set Up a Global Load Balancer for Multiple Kubernetes Clusters