一、引言

上週，我參加了騰訊全球數字生態大會。

今天，就跟大家分享，我的一點收穫，就是理解了多集群工具。

軟件開發的同學，應該都聽說過 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 感興趣的同學，可以微信掃描下面的二維碼，查看產品手冊。

（完）