Kubernetes的設計初衷是要解決管理大規模容器化環境時的困難。不過，這並不意味著Kubernetes在任何的環境下都可以進行擴展。有一些方法可以讓用戶最大限度地發揮Kubernetes的擴展能力，而在擴展Kubernetes時，有一些重要事項和限制需要註意，本文中我將對這些內容進行說明。

規模和性能

擴展Kubernetes集群，首先要註意的就是規模和性能之間的平衡。比如，Kubernetes 1.6可被用於多達5000個節點的集群。不過5000個節點並不是硬性限制的最大值，它只是一個推薦的節點最大值。在實際使用中，節點數可以遠超過5000個，只是這樣會導致性能下降罷了。

這個問題具體來說是這樣的：Kubernetes有兩個服務層級的目標，一個是在一秒內返回99%的API調用。另一個是在5秒內啟動99%的pods。盡管這些目標並不是完整的一套性能指標，但它們確實為評估通用集群性能提供了良好的基準。而據Kubernetes所說，超過5000個節點的集群可能無法實現這些服務層級的目標。

所以有一點請大家註意，在有些時候，為了發揮Kubernetes的擴展性，你有可能不得不犧牲一部分的性能，這些犧牲對你來說既可能是值得的，也可能是不值得的，而這取決於你具體的部署場景。

配額（quotas）

在建立非常大規模的Kubernetes集群時，你可能會遇到的一個主要問題就是配額問題。對於基於雲的節點尤為如此，因為雲服務提供商通常情況下會設置配額限制。

這個問題之所以如此重要，是因為部署大規模的Kubernetes集群實際上是一個看似簡單的過程。config-default.sh文件有NUM_NODES的設置。表面上，你可以通過加大與此設置相關聯的值來構建大規模集群。雖然這在某些情況下可行，但最終也可能會遭遇到配額問題。因此，在你打算擴展集群之前，很有必要就現有的任何配額先和雲供應商進行溝通。雲供應商不僅可以讓你了解現有配額的情況，而且至少一部分雲供應商會同意用戶增加配額限制的請求。

當你在評估這些限制的時候，需要註意，盡管配額限制會直接限制你創建Kubernetes集群的數量，然而集群大小的限制更多是出自與Kubernetes間接相關的配額。例如，提供商可能會限制允許你使用的IP地址數量，或者限制你創建的虛擬機實例數量。而好消息是，主要的幾個雲服務商已經有多次和Kubernetes打交道的經驗，應該能夠幫助你解決這些問題。

主節點

除了上述的限制外，還需要考慮的一個問題是集群大小對所需的主節點大小和數量的影響。這些取決於Kubernetes的實現方式，不過要記住的一點是，集群越大，所需的主節點數量也越多，而那些主節點的功能需求也就越高。

如果你正在從頭構建新的Kubernetes集群，這可能是一個無關的問題，畢竟確定需要的主節點數量是集群規劃過程中的正常階段。可是如果你打算擴展現有Kubernetes集群，那麽你更需要去多加考慮主節點的需求，因為在集群啟動時主節點的大小就已經設置好了，而且不能夠動態調整。

擴展附加組件（scaling add-ons）

另一件需要我們註意的是，Kubernetes定義了附加組件容器的資源限制。這些資源限制可確保附加組件不會消耗過多的CPU和內存資源。

這些有關限制的問題是，它們是基於相對較小的集群進行定義的。如果你在大規模集群中運行某些附加組件，它們可能會需要超額使用更多的資源。這是因為附加組件必須服務更多的節點，也因此需要額外的資源。如果開始出現與組件相關限制的問題，那麽你就會看到附加組件一個一個地被kill掉。

總結

Kubernetes集群可以大規模擴展，但可能會遇到與配額和性能相關的問題。因此，在向Kubernetes集群添加大量新節點之前，請一定要仔細考慮橫向擴展所出現的各種需求。

原文來源：Rancher Labs

本文出自 “12452495” 博客，請務必保留此出處http://12462495.blog.51cto.com/12452495/1977869

如何配置Kubernetes以實現最大程度的可擴展性