隨著 Kubernetes 在企業(yè)中應(yīng)用的越來越廣泛和普及，越來越多的公司在生產(chǎn)環(huán)境中運(yùn)維多個(gè)集群。本文主要講述一些關(guān)于多集群 Kubernetes 的思考，包括為什么選擇多集群，多集群的好處以及多集群的落地方案。

VMware2020 年 Kubernetes 使用報(bào)告中指出，在采用 kubernetes 組織中 20%的組織運(yùn)行 40+數(shù)目的集群。

為什么企業(yè)需要多集群？

單集群 Kubernetes 承載能力有限

首先看看官方文檔中關(guān)于單集群承載能力的描述：

在 v1.12，Kubernetes 支持最多具有 5000 個(gè)節(jié)點(diǎn)的集群。更具體地說，我們支持滿足以下所有條件的配置：

•  不超過 5000 個(gè)節(jié)點(diǎn)
•  Pod 總數(shù)不超過 150000
•  總共不超過 300000 個(gè)容器
•  每個(gè)節(jié)點(diǎn)不超過 100 個(gè) Pod

雖然現(xiàn)在 Kubernetes 已經(jīng)發(fā)展到 v1.20，但是關(guān)于單集群承載能力一直沒有變化?？梢娞岣邌渭贺?fù)載能力并不是社區(qū)的發(fā)展方向。

如果我們的業(yè)務(wù)規(guī)模超過了 5000 臺(tái)，那么企業(yè)不得不考慮多個(gè)集群。

混合云或是多云架構(gòu)決定了需要多個(gè)集群

到目前，其實(shí)多云或是混合云的架構(gòu)很普遍了。

比如企業(yè)是一個(gè)全球化的公司，提供 Global 服務(wù)。

或像新浪微博一樣，自建數(shù)據(jù)中心 + 阿里云，阿里云用于服務(wù)彈性流量。

另外公有云并沒有想象中的海量資源。比如公有云的頭部客戶搞大促需要很大數(shù)量機(jī)器的時(shí)候，都是需要提前和公有云申請(qǐng)，然后公有云提前準(zhǔn)備的。

為了避免被單家供應(yīng)商鎖定，或是出于成本等考慮，企業(yè)選擇了多云架構(gòu)，也決定了我們需要多個(gè)集群。

不把雞蛋放到一個(gè)籃子里

即使前面兩條都未滿足，那么我們是否要把所有的工作負(fù)載部署到一個(gè)集群呢？

如果集群控制面出現(xiàn)故障，那么所有的服務(wù)都會(huì)受到影響。

也許大家認(rèn)為 Kubernetes 的控制面本身就是高可用的（三個(gè) api-server），不會(huì)有整個(gè)控制層不可用的可能。

其實(shí)則不然，我們?cè)谏a(chǎn)環(huán)境中，已經(jīng)處理很多次類似故障了。如果一個(gè)應(yīng)用（一般指需要調(diào)用 api-server 接口）在大量地調(diào)用 api-server，會(huì)導(dǎo)致 api-server 接連掛掉，最終不可用。直到找到故障應(yīng)用，并把故障應(yīng)用刪除。

所以在生產(chǎn)環(huán)境中，一是需要嚴(yán)格控制訪問 api-server 的權(quán)限，二是需要做好測(cè)試，三是可以考慮業(yè)務(wù)應(yīng)用和基礎(chǔ)設(shè)施分開部署。其實(shí)單集群和多集群的選擇和”選擇一臺(tái)超算 or 多臺(tái)普通機(jī)器“的問題類似。后來分布式計(jì)算的發(fā)展說明大家選擇了多個(gè)普通機(jī)器。

多集群的好處

多集群在以下三個(gè)方面，有著更好的表現(xiàn)：

•  可用性
•  隔離性
•  擴(kuò)展性

多集群應(yīng)用程序架構(gòu)

實(shí)際上，可以通過兩種模型來構(gòu)建多集群應(yīng)用程序架構(gòu)

•  副本 ：將應(yīng)用程序復(fù)制到多個(gè)可用性區(qū)域或數(shù)據(jù)中心，每個(gè)集群都運(yùn)行應(yīng)用程序的完整副本。我們可以依靠 Smart DNS（在 GCP，有 Global 負(fù)載均衡器的概念） 將流量路由到距離用戶最近的集群，以實(shí)現(xiàn)最小的網(wǎng)絡(luò)延遲。如果我們一個(gè)集群發(fā)生故障，我們可以將流量路由到其他健康集群，實(shí)現(xiàn)故障轉(zhuǎn)移。
•  按服務(wù)劃分：按照業(yè)務(wù)相關(guān)程度，將應(yīng)用部署在不同的集群。這種模型，提供了非常好的隔離性，但是服務(wù)劃分卻比較復(fù)雜。

社區(qū)多集群落地方案

實(shí)際上，社區(qū)一直在探索多集群 Kubernetes 的最佳實(shí)踐，目前來看主要有以下兩種。

以 Kubernetes 為中心

著力于支持和擴(kuò)展用于多集群用例的核心 Kubernetes 原語(yǔ)，從而為多個(gè)集群提供集中式管理平面。Kubernetes 集群聯(lián)邦項(xiàng)目采用了這種方法。

理解集群聯(lián)邦的最好方法是可視化跨多個(gè) Kubernetes 集群的元集群。想象一下一個(gè)邏輯控制平面，該邏輯控制平面編排多個(gè) Kubernetes 主節(jié)點(diǎn)，類似于每個(gè)主節(jié)點(diǎn)如何控制其自身集群中的節(jié)點(diǎn)。

其實(shí)集群聯(lián)邦本質(zhì)上做了兩件事情：

•  跨集群分發(fā)資源：通過抽象 Templates ，Placement，Overrides 三個(gè)概念，可以實(shí)現(xiàn)將資源（比如 Deployment）部署到不同的集群，并且實(shí)現(xiàn)多集群擴(kuò)縮。
•  多集群服務(wù)發(fā)現(xiàn)：支持多集群 Service 和 Ingress。截止到目前，聯(lián)邦項(xiàng)目尚處于 alpha 狀態(tài)，當(dāng)我們選擇落地的時(shí)候，需要一定量的開發(fā)工作。

以網(wǎng)絡(luò)為中心

以網(wǎng)絡(luò)為中心的方法專注于在集群之間創(chuàng)建網(wǎng)絡(luò)連接，以便集群內(nèi)的應(yīng)用程序可以相互通信。

Istio 的多集群支持，Linkerd 服務(wù)鏡像和 Consul 的 Mesh 網(wǎng)關(guān)是通過 Service mesh 解決方案來實(shí)現(xiàn)網(wǎng)絡(luò)連通。

而另外一種是 Cilium 關(guān)于多集群網(wǎng)絡(luò)的方案。Cilium 本身是一種 CNI 網(wǎng)絡(luò)，該方案少了服務(wù)治理的功能。

Cilium Cluster Mesh 解決方案通過隧道或直接路由，解決跨多個(gè) Kubernetes 集群的 Pod IP 路由，而無需任何網(wǎng)關(guān)或代理。當(dāng)然我們需要規(guī)劃好每個(gè)集群的 POD CIDR。

•  每個(gè) Kubernetes 集群都維護(hù)自己的 etcd 集群，其中包含該集群的狀態(tài)。來自多個(gè)集群的狀態(tài)永遠(yuǎn)不會(huì)混入 etcd 中。
•  每個(gè)集群通過一組 etcd 代理公開其自己的 etcd。在其他集群中運(yùn)行的 Cilium 代理連接到 etcd 代理以監(jiān)視更改，并將多集群相關(guān)狀態(tài)復(fù)制到自己的集群中。使用 etcd 代理可確保 etcd 觀察程序的可伸縮性。訪問受 TLS 證書保護(hù)。
•  從一個(gè)集群到另一個(gè)集群的訪問始終是只讀的。這樣可以確保故障域保持不變，即一個(gè)集群中的故障永遠(yuǎn)不會(huì)傳播到其他集群中。
•  通過簡(jiǎn)單的 Kubernetes secret 資源進(jìn)行配置，該資源包含遠(yuǎn)程 etcd 代理的尋址信息以及集群名稱和訪問 etcd 代理所需的證書。

思考

上面我們講到了兩種落地多集群 Kubernetes 的方案，其實(shí)并不是非 A 即 B。

比如，當(dāng)我們?cè)诼涞卮蠹旱倪^程中，很多公司只是用 Kubernetes 解決部署的問題。服務(wù)發(fā)現(xiàn)選擇 consul，zk 等注冊(cè)中心，配置文件管理使用配置中心，負(fù)載均衡也沒有使用 kubernetes 中 Service。

此時(shí)結(jié)合兩種方案是最佳實(shí)踐。

集群聯(lián)邦解決部署和發(fā)布的問題。Service mesh 解決多集群流量訪問的問題。不過此時(shí)，工作負(fù)載集群中的 Pod，Service mesh 的控制面以及網(wǎng)關(guān)都需要對(duì)接外部的注冊(cè)中心。具體架構(gòu)如下：