如何實現跨數百個K8s叢集的管理？

隨著雲原生程式的加快，傳統大型業務應用系統也走上了微服務化之路。服務功能分解是應用微服務化的巨大挑戰，對於大型應用系統來說更是如此。不僅如此，雖然K8s已經實現了很多功能的自動化，也支撐了越來越多的服務，但當我們深入研究這些服務之間的連線時，發現微服務還有很長的路要走。而以Istio等為代表的高階服務網格平臺，無疑已經成為微服務目前面臨諸多問題的最佳解決手段。

Intuit 實現數百個K8s叢集的管理

Intuit公司成立於1983年。它以個人財經軟體為主要產品。2019年10月入選《財富》雜誌“2019未來50強榜單”，排第21位。截至當年，Intuit公司4大BU、30個業務部門執行了大約160個K8s叢集，大約5400個名稱空間，每天要進行1300次的部署。那麼他是如何做到，今天我們做一個簡單的講解。

首先就是為什麼Intuit公司要劃分如此多的叢集?他們希望在不同的業務部門之間實現隔離，並且各業務部門能夠擁有自主權;其次，為了滿足合規，將審計限定在一定的範圍內;此外，還有一些傳統老舊應用以及跨多個區域的託管服務，都需要獨立的叢集去託管。

舉一個簡單的例子，在上圖中的三個叢集中，API閘道器恰好是一個多租戶系統，它支援多個BU，所以Intuit不希望該服務和任何其他服務部署在一起，所以這個API閘道器隔離在一個叢集中。相反，產品資訊服務和圖書訂購服務實際上由同一個BU維護，因此，二者形成了一個獨立的叢集。而支付服務是審計的一部分，Intuit把它拆分出來放到一個單獨的叢集裡。

從單控制平面到多控制平面

當然，實際生產中的Intuit 服務叢集要比這個示例複雜的多，也龐大的多。支撐Intuit 不斷探索的動力主要有六個需求，分別是“服務的唯一全域性標識”、“點對點身份驗證”、“端到端加密”、“沒有單點故障”、“服務發現和管理的解耦”以及“Istio 和 K8s 配置的協同”。

我們還是透過示例中的三個叢集來講解Intuit 走向Admiral 管理叢集的路程。

起先，為了實現多叢集的統一管理，最容易想到的就是多叢集使用一個共享的控制平面。所有Envoy 代理都直接連線到這個共享控制平面。同時，透過共享一個根CA進行身份驗證和加密，實現跨叢集的服務認證。但這種方案不能識別部署在不同名稱空間中的工作負載，也沒有將命名方案與名稱空間解耦。此外，Istio配置點在一個與服務分離的控制平面中，這讓開發人員很尷尬。最後，這種方案的最大致命問題就是不能避免單點失敗。

於是，有了改進方案，多叢集控制平面。每個叢集都有獨立的控制平面，各叢集執行的所有代理都可以從其叢集內部控制平面獲取其配置。但這也會遇到一個問題，那就是如何同步管理所有這些不同叢集之間的配置?比如，圖書訂購服務如何知道支付服務實際部署在另一個叢集中?它如何透過路由到達該叢集?雖然Istio中有這樣的配置功能，也可以實現這一點，但必須透過人工編輯，無法實現自動化。

而且，這種方案並沒有真正地將名稱空間與服務發現解耦。好在這個方案透過多空平面確實消除了單點故障。綜合評估這個方案，其優勢是單個叢集工作得更穩定，但是在需要多叢集之間聯動時，有些功能可能就需要更加複雜的配置署。

Admiral 如何實現多叢集管理

那麼，如何解決這第二種方案的聯動不足，Intuit 的答案是Admiral 。Admiral 為多叢集 Istio 服務網格提供自動配置和服務發現功能，目前它在Github平臺上Istio-ecosystem中，位列第一。雖然，Istio 擁有一套非常強大的多叢集功能，但跨多個叢集大規模管理配置對其來說仍然具有挑戰性。

Admiral 對此配置擁有獨特優勢，並提供跨叢集的自動配置和同步。Admiral 定義了兩個自定義資源，即依賴關係和全域性流量策略，它們用於在每個叢集上為每個跨叢集服務配置 ServiceEntries、VirtualServices 和 DestinationRules。這消除了開發人員和網格運營人員的工作複雜性。

最終，Intuit 基於Admiral結合多叢集控制平面方案部署實現了更高階別、自動化的配置管理。在這個方案中，使用Admiral作為多個叢集控制平面的“中介”，或者更確切的說作為各個叢集控制平面的統一“控制器”，自動化將配置同步到所有叢集中，使叢集之間的服務能夠相互通訊。

Admiral建立服務可以使用的全域性唯一名稱，設定到這些服務的路由，從而將名稱空間與服務配置分離。它還支援對同一個服務命名多個名稱，將某些端到端場景固定在指定的區域路由中。這使得跨叢集遷移部署變得輕鬆。它所做的就是隨時偵測這些叢集，然後跟隨著叢集的發展而變化。

Admiral本身並沒有任何執行時狀態。基本上，在這種方案中Istio管理的這些叢集的所有狀態實際上都下沉到每個叢集本身。這意味著，如果Admiral“消失”了，叢集中所有網格的當前執行狀態不會有任何變化。因此，它不會影響任何執行時部署。

Istio服務網格在國內某銀行的應用

儘管Istio技術能夠解決如此複雜的業務問題，但是在國內落地的場景並不多，某城商行算是金融領域的先行者。為了落實“強後臺，大中臺，敏前臺”技術戰略，構建雲原生技術體系，深入推進全行架構雲化轉型，持續進行應用服務化解耦，支撐產品快速迭代與低成本創新，某銀行在靈雀雲的支援下建立了完善的Service Mesh平臺，將服務治理、應用監控、鏈路追蹤等平臺功能下沉到資料平面，解耦平臺與業務功能。

平臺的建立使得該行在應用無感知情況下提供靈活的服務治理和可觀測能力，使業務開發人員更關注於業務開發，提升業務迭代速率，賦予開發人員更多創造性。