Kubernetes 多集羣在開源項目 KubeSphere 的應用

時間 2020-08-22

標籤 kubernetes 集羣開源項目 kubesphere 應用欄目負載均衡简体版

原文原文鏈接

Kubernetes 多集羣使用場景

隨着容器的普及和 Kubernetes 的日漸成熟，企業內部運行多個 Kubernetes 集羣已變得頗爲常見。歸納起來，多個集羣的使用場景主要有如下幾種。nginx

多集羣使用場景

高可用

能夠將業務負載分佈在多個集羣上，使用一個全局的 VIP 或者 DNS 域名將請求發送到對應的後端集羣，當一個集羣發生故障沒法處理請求時，將 VIP 或者DNS記錄切換健康的集羣。git

低延遲

在多個區域部署集羣，將用戶請求轉向距離最近的集羣處理，以此來最大限度減小網絡帶來的延遲。舉個例子，假如在北京，上海，廣州三地部署了三個 Kubernetes 集羣，對於廣東的用戶就將請求轉發到所在廣州的集羣處理，這樣能夠減小地理距離帶來的網絡延遲，最大限度地實現各地一致的用戶體驗。github

故障隔離

一般來講，多個小規模的集羣比一個大規模的集羣更容易隔離故障。當集羣發生諸如斷電、網絡故障、資源不足引發的連鎖反應等問題時，使用多個集羣能夠將故障隔離在特定的集羣，不會向其餘集羣傳播。json

業務隔離

雖然 Kubernetes 裏提供了 namespace 來作應用的隔離，可是這只是邏輯上的隔離，不一樣 namespace 之間網絡互通，並且仍是存在資源搶佔的問題。要想實現更進一步的隔離須要額外設置諸如網絡隔離策略，資源限額等。多集羣能夠在物理上實現完全隔離，安全性和可靠性相比使用 namespace 隔離更高。例如企業內部不一樣部門部署各自獨立的集羣、使用多個集羣來分別部署開發/測試/生成環境等。後端

避免單一廠商鎖定

Kubernetes 已經成容器編排領域的事實標準，在不一樣雲服務商上部署集羣避免將雞蛋都放在一個籃子裏，能夠隨時遷移業務，在不一樣集羣間伸縮。缺點是成本增長，考慮到不一樣廠商提供的 Kubernetes 服務對應的存儲、網絡接口有差別，業務遷移也不是垂手可得。api

多集羣部署

上面說到了多集羣的主要使用場景，多集羣能夠解決不少問題，可是它自己帶來的一個問題就是運維複雜性。對於單個集羣來講，部署、更新應用都很是簡單直白，直接更新集羣上的yaml便可。多個集羣下，雖然能夠挨個集羣更新，但如何保證不一樣集羣的應用負載狀態一致？如何在不一樣集羣間作服務發現？如何作集羣間的負載均衡？社區給出的答案是聯邦集羣（Federation）。安全

Federation v1

Federation 方案經歷了兩個版本，最先的 v1 版本已經廢棄。在 v1 版本中，總體架構與 Kubernetes 自身的架構很是類似，在管理的各個集羣以前引入了 Federated APIServer 用來接收建立多集羣部署的請求，在控制平面的 Federation Controller Manager 負責將對應的負載建立到各個集羣上。微信

在 API 層面上，聯邦資源的調度經過 annotation 實現，最大程度地保持與原有 Kubernetes API 的兼容，這樣的好處是能夠複用現有的代碼，用戶已有的部署文件也不須要作太大改動便可遷移過來。但這也是制約 Federation 進一步的發展，沒法很好地對 API 進行演進，同時對於每一種聯邦資源，須要有對應的 Controller 來實現多集羣的調度，早期的 Federation 只支持有限的幾種資源類型。網絡

Federation v2

社區在 v1 的基礎上發展出了 Federation v2，即 Kubefed。Kubefed 使用 Kubernetes 已經相對成熟的 CRD 定義一套本身的 API 規範，拋棄了以前使用的 annotation 方式。架構上也較以前有很大改變，放棄了以前須要獨立部署的 Federated APIServer/etcd，Kubefed 的控制平面採用了流行的 CRD + Controller 的實現方式，能夠直接安裝在現有的 Kubernetes 集羣上，無需額外的部署。架構

v2定義的資源類型主要包含4種：

Cluster Configuration：定義了 Member Cluster 加入到控制平面時所須要用到的註冊信息，包含集羣的名稱， APIServer 地址以及建立部署時須要用到的憑證。

Type Configuration：定義了 Federation 能夠處理的資源對象。每一個 Type Configuration 便是一個 CRD 對象，包含下面三個配置項：

Template Template 包含了要處理的資源對象，若是處理的對象在即將部署的集羣上沒有相應的定義，則會建立失敗。下面例子中的 FederatedDeployment，template 包含了建立 Deployment 對象所須要的所有信息。
Placement 定義了該資源對象將要建立到的集羣名稱，可使用 clusters 和 clusterSelector 兩種方式。
Override 顧名思義，Override 能夠根據不一樣集羣覆蓋 Template 中的內容，作個性化配置。下面例子中，模板定義的副本數爲 1，Override 裏覆蓋了 gondor 集羣的副本數，當部署到 gondor 集羣時再也不時模板中的 1 副本，而是 4 副本。Override 實現了 jsonpatch 的一個子集，理論上 template 裏的全部內容均可以被覆蓋。

Schedule：主要定義應用在集羣間的分佈，目前主要涉及到 ReplicaSet 和Deployment。能夠經過 Schedule 定義負載在集羣中的最大副本和最小副本數，這部分是將以前 v1 中經過 annotation 調度的方式獨立出來。

MultiClusterDNS：MultiClusterDNS 實現了多個集羣間的服務發現。多集羣下的服務發現相比單個集羣下要複雜許多，kubefed 裏使用了 ServiceDNSRecord、IngressDNSRecord、DNSEndpoint 對象來處理多集羣的服務發現，須要配合 DNS 使用。

整體來講，Kubefed 解決了 v1 存在的許多問題，使用 CRD 的方式很大程度地保證了聯邦資源的可擴展性，基本上 Kubernetes 全部的資源均可以實現多集羣部署，包含用戶自定義的 CRD 資源。

Kubefed 目前也存在一些值得關注的問題：

單點問題：Kubefed 的控制平面便是 CRD + Controller 的實現方式，雖然 controller 自己能夠實現高可用，但若是其運行所在的 Kubernetes 沒法使用，則整個控制平面即會失效。這點上在社區中也有討論，Kubefed 目前使用的是一種 Push reconcile 的方式，當聯邦資源建立時，由控制平面上對應的 Controller 將資源對象的發送對應的集羣上，至於資源以後怎麼處理那是 Member Cluster 本身的事情了，和控制平面無關。因此當 Kubefed 控制平面不可用時，不影響已經存在的應用負載。
成熟度：Kubefed 社區不如 Kubernetes 社區活躍，版本迭代的週期較長，目前不少功能仍處在 beta 階段。
過於抽象：Kubefed 使用 Type Configuration 來定義須要管理的資源，不一樣的 Type Configuration 僅是 Template 不一樣，好處是對應處理邏輯能夠統一，便於快速實現，Kubefed 裏 Type Configuration 資源對應的 Controller 都是模板化的。可是缺點也很明顯，不能針對特殊的 Type 實現個性化的功能。例如 FederatedDeployment 對象，對於 Kubefed 來講僅須要根據 Template 和 Override 生成對應的 Deployment 對象，而後建立到 Placement 指定的集羣，至於 Deployment 在集羣上是否生成了對應的 Pod，狀態是否正常則不能反映到 FederatedDeployment 上，只能去對應的集羣上查看。社區目前也意識到這點，正在積極的解決，已經有對應的提案。

KubeSphere 多集羣

上面提到的 Federation 是社區提出的解決多集羣部署問題的方案，能夠經過將資源聯邦化來實現多集羣的部署。對於不少企業用戶來講，多集羣的聯合部署其實並非剛需，更須要的在一處可以同時管理多個集羣的資源便可。

咱們開源的 KubeSphere v3.0 支持了多集羣管理的功能，實現了資源獨立管理和聯邦部署的功能，支持對集羣與應用等不一樣維度的資源實現監控、日誌、事件與審計的查詢，以及多渠道的告警通知，以及能夠結合 CI/CD 流水線部署應用至多個集羣中。

權限管理基於 Kubefed、RBAC 和 Open Policy Agent，多租戶的設計主要是爲了方便業務部門、開發人員與運維人員在一個統一的管理面板中對資源進行隔離與按需管理。

總體架構

KubeSphere 多集羣的總體架構圖如圖所示，多集羣控制平面所在的集羣稱之爲 Host 集羣，其管理的集羣稱爲 Member 集羣，本質上是一個安裝了 KubeSphere 的 Kubernetes 集羣，Host 集羣須要可以訪問 Member 集羣的 kube-apiserver，Member 集羣之間的網絡連通性沒有要求。管理集羣 Host Cluster 獨立於其所管理的成員集羣，Member Cluster 並不知道 Host Cluster 存在，這樣作的好處是當控制平面發生故障時不會影響到成員集羣，已經部署的負載仍然能夠正常運行，不會受到影響。

Host 集羣同時承擔着 API 入口的做用，由 Host Cluster 將對 Member 集羣的資源請求轉發到 Member 集羣，這樣作的目的是方便聚合，並且也利於作統一的權限認證。

認證鑑權

從架構圖上能夠看出，Host 集羣負責同步集羣間的身份和權限信息，這是經過 Kubefed 的聯邦資源實現的，Host 集羣上建立 FederatedUser/FederatedRole/FederatedRoleBinding ，Kubefed 會將 User/Role/Rolebinding 推送到 Member 集羣。涉及到權限的改動只會應用到 Host 集羣，而後再同步到 Member 集羣。這樣作的目的是爲了保持每一個 Member 集羣的自己的完整性，Member 集羣上保存身份和權限數據使得集羣自己能夠獨立的進行鑑權和受權，不依賴 Host 集羣。在 KubeSphere 多集羣架構中，Host 集羣的角色是一個資源的協調者，而不是一個獨裁者，儘量地將權力下放給 Member 集羣。

集羣連通性

KubeSphere 多集羣中只要求 Host 集羣可以訪問 Member 集羣的 Kubernetes APIServer，對於集羣層面的網絡連通性沒有要求。KubeSphere中對於 Host 和 Member 集羣的鏈接提供了兩種方式：

直接鏈接：若是 Member 集羣的 kube-apiserver 地址能夠在 Host 集羣上的任一節點都能連通，那麼便可以使用這種直接鏈接的方式，Member 集羣只需提供集羣的 kubeconfig 便可。這種方式適用於大多數的公有云 Kubernetes 服務，或者 Host 集羣和 Member 集羣在同一網絡的情形。

代理鏈接：若是 Member 集羣在私有網絡中，沒法暴露 kube-apiserver 地址， KubeSphere 提供了一種代理的方式，即 Tower。具體來講 Host 集羣上會運行一個代理服務，當有新集羣須要加入時，Host 集羣會生成加入全部的憑證信息，Member 集羣上運行 Agent 會去鏈接 Host 集羣的代理服務，鏈接成功後創建一個反向代理隧道。因爲 Member 集羣的 kube-apiserver 地址在代理鏈接下會發生變化，須要 Host 集羣爲 Member 集羣生成一個新的 Kubeconfig 。這樣的好處是能夠屏蔽底層細節，對於控制平面來講不管是直接鏈接仍是代理方式鏈接，呈現給控制平面的都是一個能夠直接使用的 Kubeconfig。

API 轉發

KubeSphere 多集羣架構中，Host 集羣承擔着集羣入口的職責，全部的用戶請求 API 是直接發往 Host 集羣，再由 Host 集羣決定請求發往何處。爲了儘量兼容以前的 API，在多集羣環境下，API 請求路徑中以 /apis/clusters/{cluster} 開頭的請求會被轉發到 {cluster} 集羣，而且去除 /clusters/{cluster}，這樣的好處對應的集羣收到請求和其餘的請求並沒有任何區別，無需作額外的工做。舉個例子：

會被轉發到名稱爲 rohan 的集羣，而且請求會被處理爲：

總結

多集羣問題遠比想象的要複雜，從社區 Federation 方案就能看出，經歷了先後兩個版本可是時至今日還未發佈正式版。軟件領域有句經典的話，No Silver Bullet，Kubefed、KubeSphere 等多集羣工具並不能也不可能解決多集羣的全部問題，仍是須要根據具體業務場景選擇合適本身的。相信隨着時間的推移，這些工具也會變得更加成熟，屆時能夠覆蓋到更多的使用場景。

Q&A

Q：多集羣方案是偏向高可用仍是容災方向？若是是高可用（涉及到跨集羣調用），應該如何對微服務進行改造，好比 Spring Cloud？

A：多集羣能夠用來作高可用，也能夠用來作容災，社區的 Federation 方案是比較通用的方案，比較偏向容災。高可用通常須要結合具體的業務來看，Federation 更偏向一個多集羣部署，至於底層數據如何同步來支持 HA 須要業務自己來作了。

Q：多集羣的管理操做界面是自研的嗎？若是是，能分享下大體的研發步驟和界面操做圖給你們嗎？

A：Yes，是自研的。操做界面能夠經過下面幾個視頻瞭解下：

Q：大佬，大家的業務在Kubernetes中運行期間有碰到一些網絡通訊問題嗎？能分享下問題和大體排查步驟嗎，謝謝。

A：網絡問題太多了，能夠看看這個，能覆蓋大部分網絡問題場景了。至於太難的，不容易碰到。

Q：聯邦層面的 HPA 大家是怎麼處理的呢？

A：目前 KubeSphere 多集羣中尚未涉及到多集羣的 HPA，這須要對底層的監控設施進行必定的改造，在 roadmap 裏。

Q：咱們以前也有嘗試使用聯邦來解決多集羣下的服務發現問題，可是後面仍是放棄了，不敢用，可否分享下多集羣服務發現這塊的解決方案呢？

A：是的，Kubefed 服務發現相比較單個集羣不是那麼好用，這塊咱們也在和社區一塊兒積極推動，遇到問題仍是要向社區提 issue 的，幫助社區瞭解用戶場景，也是爲開源作貢獻 : )

Q：KubeSphere 在多雲管理的時候，如何打通公有云和私有云？另外是否會動態調整不一樣集羣裏的 Pod 副本數？依據是什麼？

A：KubeSphere 管理的集羣是一個 KubeSphere 集羣，實際是用 Kubernetes 來消除了公有云和私有云底層的異構性，須要解決的僅是網絡問題。今天分享提到了 KubeSphere 多集羣如何實現和 Member Cluster 的連通性，有一種方式就是適合私有云的，能夠了解下。

Q：多集羣下的 http 的解決方案是什麼，咱們在用的單集羣是 ingress-nginx -》service，多集羣該如何處理？

A：多集羣下若是你使用的是 kubefed ，那麼能夠了解下 multiclusterdns，裏面有作多集羣 Ingress 的。若是不是的話，只是多個獨立的 Kubernetes 集羣，那就須要人肉去配置下了。

本文來自 KubeSphere 團隊在 DockOne 社區的分享，您能夠查看原文。

相關連接：

關於 KubeSphere

KubeSphere 是在 Kubernetes 之上構建的容器混合雲，提供全棧的 IT 自動化運維的能力，簡化企業的 DevOps 工做流。

KubeSphere 已被 Aqara 智能家居、原本生活、新浪、中國人保壽險、華夏銀行、浦發硅谷銀行、四川航空、國藥集團、微衆銀行、紫金保險、Radore、ZaloPay 等海內外數千家企業採用。KubeSphere 提供了運維友好的嚮導式操做界面和豐富的企業級功能，包括多雲與多集羣管理、Kubernetes 資源管理、DevOps (CI/CD)、應用生命週期管理、微服務治理 (Service Mesh)、多租戶管理、監控日誌、告警通知、存儲與網絡管理、GPU support 等功能，幫助企業快速構建一個強大和功能豐富的容器雲平臺。

KubeSphere 官網：https://kubesphere.io/
KubeSphere GitHub：https://github.com/kubesphere...