Categories
程式開發

如何為多個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