一、引言
上週，我參加了騰訊全球數字生態大會。
今天，就跟大家分享，我的一點收穫，就是理解了多叢集工具。
軟體開發的同學，應該都聽說過 Kubernetes 吧。它是一個容器管理工具，本身很複雜。
可想而知，同時管理多個 Kubernetes 叢集的工具，一定更復雜。但是，我這次發現，多叢集其實很好理解。
當時，大會有一個演講，關於騰訊的一個新服務，跟多叢集管理有關，叫做 TKE AppFabric，講得很淺顯，我一下就聽懂了。
下面，我儘量用最簡單的語言，解釋什麼是 Kubernetes，什麼是多叢集工具，什麼是最簡單的使用方法。
二、從 Docker 講起
為了理解 Kubernetes，需要從 Docker 講起。
2013年，Docker 誕生，創造性地將軟體應用的執行環境與原始碼打包在一起，做成一個容器映象（image）。
容器映象本身是一個二進位制檔案，可以直接釋出。其他機器只要安裝了 Docker，就能執行這個檔案。它能讓軟體執行在一個虛擬環境（稱為"容器"）裡面，從而保證執行環境和開發環境一致，避免了環境配置、啟動報錯等等麻煩事。
更重要的是，容器映象是一個標準化檔案，不管軟體使用什麼語言開發，最後做成容器，都是一個格式。因此，就可以用一個工具去處理所有容器專案的釋出，完全忽略開發語言的差異。
正是因為 Docker 提供了標準化、一站式的軟體執行流程，才為後來通用的"容器應用管理工具"鋪平了道路。
現在，Docker 已經成為軟體部署的標準。不管軟體是以原始碼釋出，還是以容器映象釋出，最後都部署執行在 Docker 裡面。
三、微服務架構
Docker 出現後，大大簡化了軟體部署，變成只需執行容器映象。很自然地，開發者就開始考慮，能不能把單體的巨型軟體，拆分成為多個元件（即多個容器）部署？
早期的企業級大型應用，通常都是一個巨大的單體軟體（monolithic），包含不同功能的多個元件。哪怕只修改一個元件，也需要把整個軟體重新部署一次。
現在的實踐則是，把較大的功能元件拆分出來，每一個元件都是一個獨立的服務，作為一個 Docker 容器單獨釋出和部署。
於是，單體軟體就變成了多個 Docker 容器組成的軟體系統，這就是現在流行的"微服務架構"（microservices）。軟體包含多個微服務，每個微服務對應一個 Docker 容器。
四、容器管理工具 Kubernetes
微服務意味著，每次釋出都涉及大量不同的容器，管理它們就成了一種挑戰。容器管理工具就應運而生。
各種容器管理工具之中，名氣最大的非 Kubernetes 莫屬。
它是谷歌開發的一款開源軟體，因為詞首K和詞尾s之間有8個字元，所以常常寫成 K8s。它已經成為事實上的容器管理標準。
具體來說，它主要有以下功能。
（1）統一的硬體介面。開發者不必關注底層的硬體細節，不管底層伺服器有什麼差異，都被抽象成統一的操作介面。
（2）自動擴充套件。它可以根據軟體負載情況，快速完成水平擴充套件。
（3）高可用。當某個容器失敗時，它會自動重啟或替換掉該容器，保證流量流向可用的節點。如果軟體釋出出現問題，還能自動回滾。
（4）其他功能。它還具有服務發現、負載均衡、資源監控等大量相關功能，同時帶有龐大的外掛和擴充套件，以及活躍的社群。
五、多叢集是什麼？
Kubernetes 的底層就是一組伺服器，上面執行著許多容器。每個 Kubernetes 例項，就被稱為一個叢集（cluster）。
普通的軟體應用，只要一個叢集就夠了。但是，出於下面提到的原因，企業級應用往往需要部署在多個叢集。
多叢集（multi cluster）可以在同一個機房，也可以在不同機房。實際應用中往往是後者，即分佈在不同機房，這時如果叢集來自不同的雲服務商，或者是不同性質的雲，就稱為"多雲"（multicloud）。
多叢集的主要考慮如下。
（1）容災。如果一個叢集出問題，那麼還有另一個叢集，可以保證可用。
（2）隔離。叢集之間可以做到非常強的物理隔離，從而實現上層使用者（租戶）的隔離。
（3）靈活性。多雲有助於減少供應商鎖定，可以根據需求選擇最合適的基礎設施和服務。
（4）合規性。不同地區可能有不同的監管要求，多叢集可以為每個叢集實施更精細的安全策略和訪問控制。
六、多叢集的挑戰
多叢集雖然有上一節的好處，但是複雜性也隨之加倍，為使用者帶來了許多挑戰。
（1）配置和管理複雜性。所有叢集需要一致的配置和部署，儘量消除差異。
（2）網路連線和延遲。如何保證不同地理位置的叢集，有安全可靠的連線，同時最大限度地減少延遲。
（3）服務發現和負載均衡。某個服務如何發現不同叢集中的其他服務，以及如何讓不同叢集負載均衡。
（4）監控。所有叢集的指標和日誌，最好彙集在一起，便於集中式監控。
（5）安全和訪問控制。多叢集的安全策略、訪問控制、憑證管理都變得更加複雜，需要仔細規則和逐一設定。
七、多叢集工具及其問題
為了解決上面的挑戰，就誕生了專門的多叢集管理工具，比如 Argo CD、Rancher Fleet、Karmada 等。
它們可以看作是開發者與 Kubernetes 之間的中間層，解決叢集管理的複雜性。
問題是，要使用它們，必須先學會 Kubernetes，再去學習這些工具本身。這是巨大的學習成本，所以多叢集工具不是針對應用開發者，而是針對叢集管理員。
現實中，多叢集是高度專業的領域，其他領域的開發者根本看不懂。開發者完成軟體開發後，會把應用交給叢集管理員，讓後者去部署。
這對雙方都很麻煩。一方面，開發者不能決定部署策略，也不瞭解底層資源，許多情況下可能不得不接觸容器管理。另一方面，叢集管理員會被迫介入應用層，一旦發生底層資源的調整，還需要通知開發者，讓其參與進來保證應用的執行。
八、面向應用的多叢集助手 TKE AppFabric
怎樣才能讓開發者更簡單地使用多叢集呢？
騰訊雲的解決方案，就是增加一個面向應用的中間層，把多叢集工具這一層隱藏，降低使用門檻，這種服務就起名為 TKE AppFabric。
它的名字中，TKE 指的是"騰訊雲容器服務"（Tencent Kubernetes Engine），AppFabric 指的是把應用容器像織物一樣編織在一起。
它面向應用開發者，定位就是"向上服務好應用，向下管理好叢集"，可以看作是應用的多叢集助手。
由於封裝了多叢集工具這一層，所以它沒有複雜的專業術語，特別好懂，開發者能夠快速理解和上手，不用關心底層資源，甚至不需要知道"叢集"這個概念。
它的簡單性，體現在下面幾個方面。
首先，它使用開發者更容易理解的"可用區"（availability zone）。應用部署時，你只需要指定在哪幾個區（比如廣州1區、上海1區），也就是部署位置，就可以了。
整個過程都面向應用，跟 Kubernetes 解耦。這一方面，有利於開發者將更多精力放在業務上面，另一方面使得雲服務商可以充分調配資源，提高資源利用率。同時，叢集的升級和維護，上層使用者也是無感的。
其次，它簡化了設定，採用宣告式設定，只需要寫好宣告檔案即可，進一步降低了學習成本。
再次，它封裝了 Kubernetes 跟應用執行相關的一些功能，讓其更易用，各種監控指標和日誌也彙集在一個地方，更容易發現。
九、多叢集案例：騰訊健康
騰訊健康就架設在 TKE AppFabric 之上，我們透過它，來看看怎麼使用多叢集架設大型服務。
下圖就是騰訊健康的後臺架構。
上圖中，閘道器（gateway）是訪問入口，下面同時部署了三個可用區：zone1，zone2 和 zone3。它們部署在不同的機房。
這三個可用區是一模一樣的，每個區都部署一個系統例項。每個系統例項包含三個層層依賴的應用：app1 依賴於 app2，app2 依賴 app3。這三個應用本身，每一個都是容器組（app pods）。
這樣的架構有三個好處，可以保證高可用和負載均衡。
（1）容災部署。如果一個可用區出現故障，可以切換到另一個可用區（比如 zone1 的 app2 出現故障，可以切換到 zone2 的 app2），保證可用。
（2）路由控制。自動為使用者分配就近的可用區，提高訪問速度。
（3）灰度釋出。新功能可以先在單個可用區進行灰度驗證，完成之後再全可用區釋出，降低釋出風險。
根據現場演講，所有騰訊內部資源上雲的業務，比如 QQ、騰訊會議、音影片業務都會部署在 TKE AppFabric 上面。今年第四季度，它就會對外試執行，明年一季度正式對外開放。
十、總結
對於採用"微服務架構"的企業級應用，如果業務比較重要，需要高可用，那麼多個 Kubernetes 叢集幾乎是必然的選擇。
如果公司有專門的團隊，你可以選擇自己來做多叢集管理，否則可以考慮雲服務商的工具。
我相信，越來越多的雲服務商，以後可能會同時提供兩套工具：一套是原始的多叢集工具，專門供高階使用者使用，另一套就是 TKE AppFabric 那樣的面向應用、隱藏多叢集細節的助手工具，供普通開發者使用。
對多叢集或者 TKE AppFabric 感興趣的同學，可以微信掃描下面的二維碼，檢視產品手冊。
（完）