如何为多个 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