關於多集羣Kubernetes的一些思考

隨着Kubernetes在企業中應用的愈來愈普遍和普及，愈來愈多的公司在生產環境中運維多個集羣。本文主要講述一些關於多集羣Kubernetes的思考，包括爲何選擇多集羣，多集羣的好處以及多集羣的落地方案。

VMware2020年Kubernetes使用報告中指出，在採用kubernetes組織中20%的組織運行40+數目的集羣。

一：爲何企業須要多集羣？

1. 單集羣Kubernetes承載能力有限

首先看看官方文檔中關於單集羣承載能力的描述：

在v1.12，Kubernetes支持最多具備5000個節點的集羣。更具體地說，咱們支持知足如下全部條件的配置：
1：不超過5000個節點
2：Pod總數不超過150000
3：總共不超過300000個容器
4：每一個節點不超過100個Pod

雖然如今Kubernetes已經發展到v1.20，可是關於單集羣承載能力一直沒有變化。可見提升單集羣負載能力並非社區的發展方向。

若是咱們的業務規模超過了5000臺，那麼企業不得不考慮多個集羣。

2：混合雲或是多雲架構決定了須要多個集羣

到目前，其實多雲或是混合雲的架構很廣泛了。

好比企業是一個全球化的公司，提供Global服務。

或像新浪微博同樣，自建數據中心 + 阿里雲，阿里雲用於服務彈性流量。

另外公有云並無想象中的海量資源。好比公有云的頭部客戶搞大促須要很大數量機器的時候，都是須要提早和公有云申請，而後公有云提早準備的。

爲了不被單家供應商鎖定，或是出於成本等考慮，企業選擇了多雲架構，也決定了咱們須要多個集羣。

3：不把雞蛋放到一個籃子裏

即便前面兩條都未知足，那麼咱們是否要把全部的工做負載部署到一個集羣哪？

若是集羣控制面出現故障，那麼全部的服務都會受到影響。

也許你們認爲Kubernetes的控制面自己就是高可用的（三個api-server），不會有整個控制層不可用的可能。

其實則否則，咱們在生產環境中，已經處理不少次相似故障了。若是一個應用（通常指須要調用api-server接口）在大量地調用api-server，會致使api-server接連掛掉，最終不可用。直到找到故障應用，並把故障應用刪除。

因此在生產環境中，一是須要嚴格控制訪問api-server的權限，二是須要作好測試，三是能夠考慮業務應用和基礎設施分開部署。

其實單集羣和多集羣的選擇和」選擇一臺超算 or 多臺普通機器「的問題相似。後來分佈式計算的發展說明你們選擇了多個普通機器。

二：多集羣的好處

多集羣在如下三個方面，有着更好地表現：

• 可用性
• 隔離性
• 擴展性

三：多集羣應用程序架構

實際上，能夠經過兩種模型來構建多集羣應用程序架構

• 副本 ：將應用程序複製到多個可用性區域或數據中心，每一個集羣都運行應用程序的完整副本。咱們能夠依靠Smart DNS（在GCP，有Global 負載均衡器的概念） 將流量路由到距離用戶最近的集羣，以實現最小的網絡延遲。若是咱們一個集羣發生故障，咱們能夠將流量路由到其餘健康集羣，實現故障轉移。
• 按服務劃分：按照業務相關程度，將應用部署在不一樣的集羣。這種模型，提供了很是好的隔離性，可是服務劃分卻比較複雜。

四：社區多集羣落地方案

實際上，社區一直在探索多集羣Kubernetes的最佳實踐，目前來看主要有如下兩種。

1: 以Kubernetes爲中心

着力於支持和擴展用於多集羣用例的核心Kubernetes原語，從而爲多個集羣提供集中式管理平面。Kubernetes集羣聯邦項目採用了這種方法。

理解集羣聯邦的最好方法是可視化跨多個Kubernetes集羣的元集羣。想象一下一個邏輯控制平面，該邏輯控制平面編排多個Kubernetes主節點，相似於每一個主節點如何控制其自身集羣中的節點。

其實集羣聯邦本質上作了兩件事情：

• 跨集羣分發資源：經過抽象 Templates ，Placement，Overrides三個概念，能夠實現將資源（好比Deployment）部署到不通的集羣，而且實現多集羣擴縮。
• 多集羣服務發現：支持多集羣Service 和 Ingress。

截止到目前，聯邦項目尚處於 alpha狀態，當咱們選擇落地的時候，須要必定量的開發工做。

2：以網絡爲中心

「以網絡爲中心」的方法專一於在集羣之間建立網絡鏈接，以便集羣內的應用程序能夠相互通訊。

Istio的多集羣支持，Linkerd服務鏡像和Consul的Mesh網關是經過Service mesh 解決方案來實現網絡連通。

而另一種是Cilium關於多集羣網絡的方案。Cilium自己是一種CNI網絡，該方案少了服務治理的功能。

Cilium Cluster Mesh解決方案經過隧道或直接路由，解決跨多個Kubernetes集羣的Pod IP路由，而無需任何網關或代理。固然咱們須要規劃好每一個集羣的POD CIDR。

• 每一個Kubernetes集羣都維護本身的etcd集羣，其中包含該集羣的狀態。來自多個集羣的狀態永遠不會混入etcd中。
• 每一個集羣經過一組etcd代理公開其本身的etcd。在其餘集羣中運行的Cilium代理鏈接到etcd代理以監視更改，並將多集羣相關狀態複製到本身的集羣中。使用etcd代理可確保etcd觀察程序的可伸縮性。訪問受TLS證書保護。
• 從一個集羣到另外一個集羣的訪問始終是隻讀的。這樣能夠確保故障域保持不變，即一個集羣中的故障永遠不會傳播到其餘集羣中。
• 經過簡單的Kubernetes secret資源進行配置，該資源包含遠程etcd代理的尋址信息以及集羣名稱和訪問etcd代理所需的證書。

五：思考

上面咱們講到了兩種落地多集羣Kubernetes的方案，其實並非非A即B。

好比，當咱們在落地大集羣的過程當中，不少公司只是用Kubernetes解決部署的問題。服務發現選擇consul，zk等註冊中心，配置文件管理使用配置中心，負載均衡也沒有使用kubernetes中Service。

此時結合兩種方案是最佳實踐。

集羣聯邦解決部署和發佈的問題。Service mesh解決多集羣流量訪問的問題。不過此時，工做負載集羣中的Pod，Service mesh的控制面以及網關都須要對接外部的註冊中心。具體架構以下：