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叢集新增大量新節點之前，請一定要仔細考慮橫向擴充套件所出現的各種需求。