隨著Kubernetes在企業(yè)中應(yīng)用的越來(lái)越廣泛和普及，越來(lái)越多的公司在生產(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)的集群。更具體地說(shuō)，我們支持滿足以下所有條件的配置：
不超過(guò)5000個(gè)節(jié)點(diǎn)
Pod總數(shù)不超過(guò)150000
總共不超過(guò)300000個(gè)容器
每個(gè)節(jié)點(diǎn)不超過(guò)100個(gè)Pod
雖然現(xiàn)在Kubernetes已經(jīng)發(fā)展到v1.20，但是關(guān)于單集群承載能力一直沒(méi)有變化?？梢?jiàn)提高單集群負(fù)載能力并不是社區(qū)的發(fā)展方向。
如果我們的業(yè)務(wù)規(guī)模超過(guò)了5000臺(tái)，那么企業(yè)不得不考慮多個(gè)集群。
混合云或是多云架構(gòu)決定了需要多個(gè)集群
到目前，其實(shí)多云或是混合云的架構(gòu)很普遍了。
比如企業(yè)是一個(gè)全球化的公司，提供Global服務(wù)。
或像新浪微博一樣，自建數(shù)據(jù)中心+阿里云，阿里云用于服務(wù)彈性流量。
另外公有云并沒(méi)有想象中的海量資源。比如公有云的頭部客戶搞大促需要很大數(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)格控制訪問(wèn)api-server的權(quán)限，二是需要做好測(cè)試，三是可以考慮業(yè)務(wù)應(yīng)用和基礎(chǔ)設(shè)施分開(kāi)部署。其實(shí)單集群和多集群的選擇和”選擇一臺(tái)超算or多臺(tái)普通機(jī)器“的問(wèn)題類似。后來(lái)分布式計(jì)算的發(fā)展說(shuō)明大家選擇了多個(gè)普通機(jī)器。
多集群的好處
多集群在以下三個(gè)方面，有著更好地表現(xiàn)：
可用性
隔離性
擴(kuò)展性
多集群應(yīng)用程序架構(gòu)
實(shí)際上，可以通過(guò)兩種模型來(lái)構(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í)踐，目前來(lái)看主要有以下兩種。
以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ā)資源：通過(guò)抽象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í)候，需要一定量的開(kāi)發(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)是通過(guò)Service mesh解決方案來(lái)實(shí)現(xiàn)網(wǎng)絡(luò)連通。
而另外一種是Cilium關(guān)于多集群網(wǎng)絡(luò)的方案。Cilium本身是一種CNI網(wǎng)絡(luò)，該方案少了服務(wù)治理的功能。
Cilium Cluster Mesh解決方案通過(guò)隧道或直接路由，解決跨多個(gè)Kubernetes集群的Pod IP路由，而無(wú)需任何網(wǎng)關(guān)或代理。當(dāng)然我們需要規(guī)劃好每個(gè)集群的POD CIDR。
每個(gè)Kubernetes集群都維護(hù)自己的etcd集群，其中包含該集群的狀態(tài)。來(lái)自多個(gè)集群的狀態(tài)永遠(yuǎn)不會(huì)混入etcd中。
每個(gè)集群通過(guò)一組etcd代理公開(kāi)其自己的etcd。在其他集群中運(yùn)行的Cilium代理連接到etcd代理以監(jiān)視更改，并將多集群相關(guān)狀態(tài)復(fù)制到自己的集群中。使用etcd代理可確保etcd觀察程序的可伸縮性。訪問(wèn)受TLS證書(shū)保護(hù)。
從一個(gè)集群到另一個(gè)集群的訪問(wèn)始終是只讀的。這樣可以確保故障域保持不變，即一個(gè)集群中的故障永遠(yuǎn)不會(huì)傳播到其他集群中。
通過(guò)簡(jiǎn)單的Kubernetes secret資源進(jìn)行配置，該資源包含遠(yuǎn)程etcd代理的尋址信息以及集群名稱和訪問(wèn)etcd代理所需的證書(shū)。
思考
上面我們講到了兩種落地多集群Kubernetes的方案，其實(shí)并不是非A即B。
比如，當(dāng)我們?cè)诼涞卮蠹旱倪^(guò)程中，很多公司只是用Kubernetes解決部署的問(wèn)題。服務(wù)發(fā)現(xiàn)選擇consul，zk等注冊(cè)中心，配置文件管理使用配置中心，負(fù)載均衡也沒(méi)有使用kubernetes中Service。
此時(shí)結(jié)合兩種方案是最佳實(shí)踐。
集群聯(lián)邦解決部署和發(fā)布的問(wèn)題。Service mesh解決多集群流量訪問(wèn)的問(wèn)題。不過(guò)此時(shí)，工作負(fù)載集群中的Pod，Service mesh的控制面以及網(wǎng)關(guān)都需要對(duì)接外部的注冊(cè)中心。具體架構(gòu)如下：
