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

创作场景

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