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的特性，支持流量接入和必定的南北向流量服務治理。好比熔斷，限流，灰度，重試等等。

也許你不只僅須要一個流量接入，更須要一個網關