多集羣應用如何幫助企業級Kubernetes獲益

擴大Kubernetes集羣規模運維人員有兩個選擇：Scale Up和Scale Out。若是想將工做量以及成本維持在較低水平，那麼多集羣應用程序將是一個重要功能。本文將介紹這兩種選擇，並闡述爲什麼多集羣應用程序如此重要。

---

Kubernetes有許多受用戶喜好的功能。它提供了一種在大型資源池上部署和運行應用程序的最佳方式。

憑藉其易於使用的UI和開箱即用的RBAC、監控、審計、日誌等功能，Rancher能夠輕鬆地管理企業級Kubernetes。

使用Rancher，IT運維人員能夠鏈接他們的雲提供商（AWS、GCP、Azure等）或者數據中心，只需簡單點擊幾下就能夠建立集羣。

隨着企業對Kubernetes需求的增加，IT運維人員能夠有兩種選擇：

• Scale Up：團隊在相關項目上一塊兒工做，不須要經過添加更多節點來擴大現有集羣的規模。

• Scale Out：因爲安全問題、資源回收或其餘緣由，團隊須要高度隔離，能夠經過添加更多集羣來scale out Kubernetes環境。Rancher均支持這兩種選擇。

要如何作到不管選擇scale up仍是scale out，都可以確保企業級Kubernetes管理的工做量和成本都控制在一個比較低的水平呢？

支持多集羣應用程序就是實現這一目標的其中一步。儘管名稱上彷彿表示該功能僅適用於多個集羣，但其實它也適用於同一集羣中的多個項目。

Scale up場景

隨着對高可靠性、高可用性或更大規模集羣的需求增加，集羣管理員可能會向現有集羣添加更多節點。爲了實現某種程度的隔離，管理員能夠爲每一個團隊提供他們本身的項目。Rancher中的項目是比命名空間更高級別的抽象，可使用RBAC進行限制。

使用相同集羣的團隊仍然能夠在本身的項目中工做，而不須要查看其餘項目。出於公司的需求或者不一樣的團隊可能使用相同的應用程序，所以必須將該應用程序的副本push到多個項目中。例如，由內部開發人員組成的項目團隊可能必須與外包團隊協做。由於他們必須在相同的應用程序上工做，而須要有本身的獨立實例，所以兩個項目中都應該有應用程序的副本。

Scale out場景

隨着Kubernetes在企業中的應用愈來愈多，咱們常常發現客戶會構建多個集羣，以在不一樣的團隊之間得到最高級別的隔離。在這種狀況下，企業需求（例如須要在每一個集羣中部署安全工具）要求集羣管理員將相同應用程序的副本push到每一個集羣。

在客戶可能擁有數百（甚至數千）個集羣的邊緣計算場景中，這種問題的複雜度是指數級的。

爲什麼多集羣應用程序如此重要

在這兩種狀況下，將應用程序副本部署到多個目標的場景都算是較小的問題。若是沒有複雜的腳本和高度熟練的支持團隊，想要升級和維護這些應用程序的同步幾乎是不可能的。

這就是對於多集羣應用程序的支持變得如此重要的緣由。想象一下在同一（或多）集羣上的多個項目內針對應用程序的Helm charts，咱們須要提供配置的值，覆蓋項目/集羣具體的設置，而後單擊一個按鈕部署應用程序。

不久前的如何部署和管理多Kubernetes集羣一文就詳細介紹了這種功能。

爲這些應用程序選擇升級策略（滾動或同步更新）的能力，進一步簡化了應用程序保持最新版本的方式。

能夠說，不管是那些支持具備多個集羣的企業級Kubernetes用戶，仍是那些職場時具備多個項目、單個集羣的用戶，多集羣應用程序都擁有着強大的能力。

總 結

百聞不如一見，試着用用它吧。你可能會發現，採用Kubernetes做爲你的企業策略並不會像有些人說的那樣複雜！

若是要在實驗室或者開發環境中測試這些特性，請安裝最新的alpha版本：

https://rancher.com/docs/rancher/v2.x/en/installation/server-tags/#helm-chart-repositories

若是有任何須要反饋的內容，請進入Github中的issue，或者直接加入咱們的論壇或者添加小助手微信（rancher2)進技術羣，與同道中人一塊兒交流。

Github：

https://github.com/rancher/rancher/issues

論壇連接：

https://forums.cnrancher.com/