是否選擇多集羣 —— 使用服務網格的集羣間通信
主要觀點
Kubernetes 已經成爲企業中容器編排的事實標準。這是有充分理由的 —— 它提供了一系列功能，使管理容器化應用變得更加容易。Kubernetes 也帶來了一些新的挑戰，一個主要的挑戰就是需要部署和管理多個 Kubernetes 集羣，以便有效地管理大規模分佈式系統。
環境越多，（集羣）問題越多
即使是一個簡單的綠地應用概念，最終也需要多個部署環境。如果你正在遷移一個現有的應用，你一定會遇到更多的挑戰，比如不同的安全域，不同的組織 / 計費，以及對一個雲供應商的機器學習工具包的親和力。
解決這個問題最常見的方法是創建多個 Kubernetes 集羣，每個集羣都致力於在其特定環境中運行你的應用組件。在高安全領域，你將廣泛使用基於角色的訪問控制（RBAC），並具有審計功能。測試環境應該重現很多生產行爲，但要爲便於調試和檢查而定製。對於你的開發環境…… 好吧，也許你像我一樣，你就打開 Docker 偏好設置，然後勾選 Kubernetes 框。易用性和短暫性是常態。
你很可能最終會有多個 Kubernetes 集羣，每個集羣都會託管微服務。集羣中這些微服務之間的通信可以通過服務網格來加強。在集羣內部，Istio 提供了通用的通信模式來提高彈性、安全性和可觀察性。那麼集羣之間和跨集羣呢？
運行多個 Kubernetes 集羣並不一定可怕，但運行多個集羣確實需要你考慮它們如何通信和交互，以便輕鬆交付運行在上面的優秀應用。像 Istio 這樣的服務網格可以讓多集羣通信變得毫無痛苦。Istio 擁有多集羣支持，在 1.1 中增加了新功能，並計劃在未來增加更多的功能。團隊也應該考慮採用服務網格來簡化跨多個集羣的通信。
常見的使用案例
運行多集羣服務網格最常見的是這些用戶需求。
• 由於我的組織規模，我有多個集羣，我想在一個地方查看和管理它們。我的集羣一般不做集羣間的流量，或者當它們做的時候，是通過定義好的 API。• 我有多個集羣以實現高可用性，它們是彼此的克隆，如果一個集羣發生故障，另一個集羣可以接管，這一點非常重要。• 我有多個集羣，它們組合成一個更高級別的應用。其中一個集羣中的微服務需要與另一個集羣中的微服務進行通信，以提供適當的端到端應用體驗。
第三類多集羣需要集羣間的流量。如果你想要集羣間流量支持，你的實現將取決於集羣之間的網絡，以及你對容錯的要求。
你能從多集羣中得到什麼？
當你考慮多集羣和服務網格時，你應該從確定你想要什麼開始，然後轉移到如何獲得它。
單一界面
你的多個服務網格從一個地方操作。你可以在一個單一的接口中查看所有集羣的配置、指標和跟蹤。
統一信任域
你使用服務網格來提供工作負載識別，並由強大的 mTLS 加密保護。這種零信任模型比基於源 IP 等拓撲信息來信任工作負載更好：你依靠的是它們是什麼的加密證明，而不是脆弱的外圍堆棧來控制它們的來源。
統一的信任域意味着所有的工作負載都可以通過綁定到一個共同的信任根來相互認證（它們是什麼）。服務網格控制平面都是爲這個共同的信任根配置的，無論這些平面有一個還是幾個。
獨立的故障域
一個不依賴其他集羣和相關基礎設施，本身就可以正常運行的集羣是一個獨立的故障域。我是把服務網格列爲相關基礎設施 —— 如果你要安裝服務網格，你是爲了把通信彈性轉移到應用下面的基礎設施層。如果一個集羣中的服務網格的故障可以破壞另一個集羣中的服務網格，那麼它就不能算是一個獨立的故障域。
集羣間的流量
如果你想讓一個集羣中的服務與另一個集羣中的服務直接通信，並且你想讓這種通信具有服務網格的好處，如高級路由、可觀察性或透明加密，那麼你需要集羣之間的流量保持爲服務網格的一部分。換句話說，你希望你的東 / 西流量離開一個集羣，中轉一些中間網絡，比如互聯網，然後進入另一個集羣。
這可能是大多數人在考慮多集羣服務網格時的第一想法，但我在這裏單獨把它列出來，因爲它對容錯有影響。
異構 / 非扁平化的網絡
非平面網絡支持跨多個集羣的服務，沒有平面網絡的要求。這意味着你可以做一些事情，比如在一個網格中分配 IP，而不考慮另一個網格，你不需要 VPN 或網絡隧道來進行跨網格的通信。
如果你的組織已經創建了一堆不同的集羣，而沒有衝突的 pod IP 地址範圍，或者你只是永遠不想再進入這種泥潭，這將是一個對你有吸引力的屬性。
多集羣服務網格方法
在闡述了你可能需要從多集羣中尋找的不同屬性之後，我可以介紹一下各種方法所帶來的好處。
獨立集羣
這就是解多集羣。僅僅因爲你有多個集羣，而且每個集羣都使用一個服務網格，並不意味着你必須採用統一的多集羣服務網格。捫心自問，你當初爲什麼會有多個集羣。如果你希望每個集羣都是自己獨立的故障域，那麼隔離和消除跨集羣的依賴關係是有意義的。如果這能滿足你的需求，那麼把服務網格當作另一個單集羣的服務，比如 pod 調度或持久性磁盤管理，也沒有什麼壞處。
共同管理
在獨立集羣方法之上的下一步是多個集羣的共同管理系統。在這種模式下，每個集羣都是獨立運行的，但你通過一個共同的管理界面來管理這套網格。讓你用來監控和調試系統（或者，在這種情況下，系統）的東西駐留在系統本身之外是一個很好的設計，這樣當系統壞了的時候，你仍然可以檢查和修復它。
如果你選擇在這些集羣中使用一個共同的信任根（證書授權或簽名證書），那麼你也可以擁有一個統一的信任域。
通過網關進行集羣感知的服務路由選擇
Istio 中的這種方法涉及多個獨立的服務網格，每個集羣中一個，以及一些配置技巧，以允許一個集羣中的服務與另一個集羣中的服務通信。首先，你要爲所有網格創建一個統一的信任域。接下來，你配置一個入口網關，以接受來自另一個對等集羣中的服務的可信流量。最後，配置服務條目，以允許某些服務的流量從一個集羣路由出來併發送到另一個集羣。
這是第一種允許不同集羣中的服務直接相互通信的方法。同時，每個集羣仍然是一個獨立的網格控制平面和故障域。這意味着，如果集羣 B 中的服務網格發生故障，集羣 A 仍然可以工作，只是看起來集羣 B 中的服務不可用。配置這種跨集羣流量的負擔就落在了用戶身上。
扁平網絡
分割區域端點發現服務（EDS）
這種方法也可以在集羣間創建一個服務網格，但不需要扁平網絡。你仍然有一個控制平面，可以從每個集羣中發現 pod、服務和配置，但 Istio 的 EDS，其功能類似於分裂水平 DNS，取代了對扁平網絡的要求。
一個集羣中的 pod 的 sidecar 被配置了它想要通信的每個服務的端點列表。如果 pod 在同一個集羣中，它就會直接顯示在 EDS 列表中。如果 pod 在另一個集羣中，則會出現另一個集羣的入口網關。pod 選擇一個端點進行對話併發送流量 —— 如果端點是本地的，則通信是直接的 pod 到 pod。如果 pod 選擇了一個遠程端點，它就會將流量發送到相關入口網關的地址，並標記爲 pod 想要訪問的服務。入口網關接收流量，並將其發送到其集羣中實現服務的 pod 之一。入口網關使用服務器名稱指示（SNI）來了解流量的目的地。
與扁平網絡方式一樣，這種方式創建了一個統一的服務網格控制平面，並增加了一個單一故障域和單一信任域。它不需要扁平網絡，只需要一個集羣可以將流量發送到其他集羣的入口網關的公共地址。
要不要多集羣？
如果你出於開發和組織的原因要運行多個集羣，那麼瞭解你的需求並決定是否要在多集羣環境中連接這些需求是很重要的，如果是這樣，瞭解各種方法和每個選項的相關權衡。
如果你已經讀到這裏，你可能已經決定了多集羣。真正的問題是什麼是最好的實現方法。希望下面的表格能幫助你決定適合你的方法。
像 Istio 這樣的服務網格可以提供幫助，如果使用得當，可以讓多集羣通信變得不痛苦。如果你想了解更多關於我對爲什麼以及團隊應該如何考慮採用服務網格來簡化跨多個集羣的通信的看法。
關於作者
Andrew Jenkins 是 Aspen Mesh 的首席技術官，他正在構建一個企業服務網格，以幫助企業減輕管理微服務的負擔。作爲容器環境（如 Kubernetes）的軟件和網絡架構師，Jenkins 曾擔任技術領導，推動快速發展的團隊取得切實成果。他的專長包括 C++、JavaScript（Node.js）、Python、C、Go 和 Java 的軟件開發。Jenkins 還在軟件和硬件測試、FPGA 和空間科學儀器的電路板設計方面擁有豐富的經驗。
引用鏈接
[1] To Multicluster, or Not to Multicluster: Inter-Cluster Communication Using a Service Mesh: https://www.infoq.com/articles/kubernetes-multicluster-comms/
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/pZ2bMCnbt8TBCaoXfDs9QA