Kubernetes集羣規模-Kubernetes集羣應該有多大？

說在前面的話

今天談談k8s集羣規模問題，到底集羣應該有多大？雖然這個問題有些乾燥，卻包含了不少生產經驗，若是這個問題也對你有所困擾，你能夠選擇繼續讀下去，你們在本身的公司不論是上雲仍是虛擬化技術，都已經在容器的途中多多少少都已經在遷移或者遷移的路上，在雲原生的技術圈中，當談到kubernetes穩定性可靠性的問題時，你殊不知道如何下手，目前不少從事k8s的技術圈的人，可能還處於似懂非懂，多少知道點的狀況，可是深刻玩懂K8S的人，卻很少，真有大規模實踐的人卻少之又少，而這篇總結在集羣規模上的一些建議但願給你帶來幫助

談到Kubernetes集羣時，規模相當重要。羣集中的節點數在肯定工做負載的總體可用性和性能方面起着重要做用。在某種程度上，名稱空間的數量也是如此。

可是，這並不意味着越大越好。旨在最大化節點數量的Kubernetes集羣規模調整策略並不是總能帶來最佳結果，固然，從成本的角度來看，也可能從總體可用性或性能的角度來看，都不是。最大化的名稱空間也毫不是明智的策略。

相反，計算要包含在羣集中的節點數須要仔細考慮各類因素。

爲何Kubernetes集羣大小很重要？

Kubernetes集羣的大小（就節點數而言）以關鍵的方式影響着性能和可用性。

關於性能，更多的節點一般意味着更好的性能。這不是由於節點數自己能夠提升性能，而是由於擁有更多的節點一般意味着羣集可使用更多的資源。所以，從這個意義上講，節點數是性能的代理。

而至於可用性，節點數在塑造此特性方面起着更直接的做用。擁有的節點越多，遇到較大節點故障以致於破壞羣集可用性的機會就越小。

固然，除了節點數影響性能和可用性以外，還有許多其餘因素。pod和名稱空間之間的資源分配，網絡質量，底層基礎結構的可靠性以及網絡上節點之間的相互距離（僅舉幾個因素）也對性能和可用性產生重大影響。

爲何更多的節點並不老是更好?

你可能會想固然地認爲能夠添加到集羣中的節點越多越好。並不是徹底如此，緣由有幾個。

並不是全部節點都相等

首先也是最重要的事實是，組成節點的方式有不少變化。

一些節點比其餘節點爲集羣貢獻了更多的硬件資源，所以在提升性能方面作得更多。在這方面，總節點數不能很好地表示羣集的性能。具備5,000個節點（Kubernetes當前能夠支持的最大節點）的集羣，每一個節點的資源分配最少，其性能可能不如由100個高端節點組成的集羣。

在某些狀況下，某些節點比其餘節點更有可能保持可用性。與不託管在雲中的虛擬機相比，位於本地數據中心的沒有電源備份的物理服務器的可靠性較差（與本地基礎結構相比，可靠性要高得多）。所以，節點數不是羣集可用性的精確度量。

物理節點與虛擬機節點

一樣，Kubernetes集羣中物理機和虛擬機的混合會以關鍵方式影響其性能和可用性。

在Kubernetes中，物理服務器和虛擬機均可以充當節點。二者在本質上都不比另外一個更可靠或更高。可是，由僅在少許物理服務器上運行的許多虛擬機節點組成的羣集，其可靠性可能不如在其中包含更多物理服務器的羣集那樣可靠。不管物理服務器是直接充當節點仍是虛擬機節點的主機，擁有更多物理服務器均可以減小任何一臺服務器故障的影響。

換句話說，若是僅在五臺物理服務器上託管100個虛擬機節點，則一臺物理服務器的故障將使您的節點數減小20％。這是一個巨大的成功，所以最好混合使用更多的物理服務器。

也就是說，將事情推向相反的極端也不理想。若是要使每一個物理服務器成爲其本身的節點，則一臺服務器的故障將使您的羣集失去該服務器貢獻的總資源。出於可用性和性能的目的，最好在每一個物理服務器上至少運行幾個虛擬機，並讓這些虛擬機做爲節點鏈接到羣集。這樣，若是其中一個節點發生故障，或者啓動時間太長，則基礎物理服務器的資源只有一部分會丟失。

底線：羣集中物理機與虛擬機的比率以複雜的方式影響性能和可用性。找到合適的比率沒有簡單的公式，可是你應該尋求一個健康的中間立場。

更多的節點意味着更多的複雜性

一樣值得注意的是，節點越多，管理和跟蹤全部節點就越困難。

鑑於Kubernetes中的大部份內容都是自動化的，所以在這方面，擁有大量節點並非很大的障礙。但這仍然是要考慮的因素。你將必須配置，監視和保護每一個節點。若是你作這些事情的能力有限，則應考慮使羣集保持較小。

性能和可用性是相對的

最後要記住的事實是性能和可用性始終是相對的。不管你有多少個節點（或沒有節點），或者集羣的配置多麼完美，你都永遠不會最大化。

我提到這一點是爲了強調，若是你過於着迷於最大化節點數，最終可能會被扼殺。你應該努力達到可接受的性能和可用性水平，而後繼續前進。除此以外，你最終會減小節點投資的回報（更不用說管理沒必要要的複雜性了）。

調整Kubernetes集羣的大小

那麼，你如何找到最佳位置？如何確保有足夠的節點但又沒有太多的節點，而且物理機和虛擬機的混合恰到好處？

顯然，這個問題沒有簡單或廣泛的答案。你須要考慮多種因素及其對你特定需求的影響。

你的物理基礎設施有多可靠？

若是構成節點基礎的物理基礎結構很是可靠，那麼你能夠擁有更少的節點。整體而言，基於此緣由，基於雲的Kubernetes部署能夠具備比本地部署更少的節點。（不管你認爲本地數據中心多麼可靠，它均可能不如現代雲可靠。）

每一個節點有多少資源？

節點的硬件配置文件（不管是物理仍是虛擬硬件）也是一個關鍵因素。從性能角度來看，若是每一個節點提供相對大量的硬件資源，則不須要那麼多節點。

你有幾個主節點？

當涉及到整個羣集的可用性和性能時，主節點比工做節點要重要得多。你可能有多個工做節點發生故障，而且看不到重大影響。可是，若是主節點是你惟一的主節點，則它的故障多是災難性的。即便不是，它所產生的影響也是災難性的

所以，在擔憂添加更多工做進程以前，須要考慮羣集中包含多少個主節點，並可能集中精力增長主節點的數量。

你的羣集託管多少工做量？

工做負載總數是肯定羣集大小的關鍵考慮因素。儘管使用Kubernetes命名空間能夠輕鬆地將集羣劃分爲各個工做負載（或工做負載組）的隔離區域，但仍是有一點要比直接添加更多的命名空間更好地簡單地將集羣分爲較小的集羣。

每一個名稱空間都會增長管理開銷。這也增長了多個問題的挑戰（能夠經過資源配額解決，可是您你須手動設置配額，所以它們不是可擴展的解決方案）。

羣集大小調整的一些極其基本的經驗法則

若是你一直在閱讀這篇文章，以尋找有關使羣集多大的具體指導，請容許我重申，沒有什麼比「一刀切」的答案更好了。

儘管如此，我仍是願意提出一些很是基本的，很是廣泛的，過於簡化的建議：

對於生產名稱空間或羣集，每一個容器至少應有一個節點。（這並不意味着你應該在每一個容器上運行它的節點（相反），而是可用於承載容器實例的最小節點總數應等於容器總數。）
對於生產名稱空間或羣集中的每一個Pod，你應該有一臺物理計算機。它是做爲本身的節點運行仍是做爲節點託管虛擬機都可有可無。關鍵是經過擁有足夠的基礎物理計算機來提升羣集的可用性。

若是單個羣集中的名稱空間超過六個，那麼該考慮將羣集拆分爲較小的羣集了。
一樣，這些是很是基本的規則。（此外，請記住，若是在開發/測試環境中對性能和可用性的關注一般不那麼大）

結論

調整Kubernetes集羣的規模是一門藝術，而不是一門科學。影響因素多種多樣，從託管節點的基礎結構類型，設置的主節點數量到物理機與虛擬機的比率，不一而足。將以上指示視爲很是通常的準則，並準備根據你的特定需求調整集羣大小。

最後歡迎討論k8s技術我的v 信 kubefetch