什麼是擴充性？
在 Kubernetes 叢集中，擴充性是指叢集保持在其服務等級目標 (SLO) 的前提下繼續成長的能力。Kubernetes 也有自己的一組 SLO
Kubernetes 是一個複雜的系統，其擴充能力取決於多種因素。其中一些因素包括節點集區中的節點類型與數量、節點集區的類型與數量、可用的 Pod 數量、將資源分配給 Pod 的方式，以及 Service 或 Service 後端的數量。
準備可用性
選擇地區或區域控制層
由於架構上的差異，地區叢集更適合高可用性。地區叢集在一個區域中的多個運算區域之間有多個主要節點，而區域叢集在單一運算區域中有一個主要節點。
如果區域叢集升級，單一主要 VM 會遭遇停機狀況，在此期間 Kubernetes API 就無法使用，直到升級完成為止。
在區域叢集中，控制層在叢集維護期間仍會保持可用，這些維護工作包括輪替 IP、升級主要 VM 或調整叢集或節點集區大小等情況。升級區域叢集時，在三個主要 VM 中有兩個一律會在漸進式升級期間執行，因此 Kubernetes API 仍會保持可用。同樣地，單一區域服務中斷並不會導致地區控制層中發生任何停機狀況。
但是，可用性越高的地區叢集越可能需要做出取捨：
對叢集配置進行變更需要更長的時間，因為變更必須在地區叢集中的所有主要執行個體上傳播，而不是在區域叢集中的單一控制層上傳播。
您可能無法像區域叢集那樣頻繁地建立或升級地區叢集。如果無法在其中一個區域建立 VM，無論是遇到容量不足還是其他暫時性的問題，都無法建立或升級叢集。
由於必須做出這些取捨，區域與地區叢集會有不同的用途：
- 如果比較不需要考慮到可用性，請使用區域叢集來快速建立或升級叢集。
- 如果可用性比靈活性更重要，請使用區域叢集。
建立叢集時，請謹慎選取叢集類型，因為建立叢集後即無法變更叢集類型。您必須建立新叢集，然後將流量遷移至該叢集。您可以在叢集之間遷移實際工作環境流量，但要大規模遷移就比較困難。
選擇多區域或區域節點集區
為了實現高可用性的目標，Kubernetes 控制層及其節點需要分佈到不同的區域。GKE 提供兩種類型的節點集區：區域性與多區域性。
如要部署高可用性應用程式，請在地區中的多個運算區域之間部署工作負載，方法是使用多區域節點集區來跨區域統一分配節點。
如果所有節點都在同一個區域中，且無法連至該區域，您就無法為 Pod 排定時間。使用多區域節點集區時必須做出一定的取捨：
間歇性區域間網路連線問題是另一個需要考量的故障模式。如果某些節點無法與其他節點通訊，您的應用程式必須設計成可正常運作。
GPU 只有在特定區域中才可用，可能沒辦法在地區中的所有區域使用。
單一地區中兩個位置之間的往返延遲預期保持在低於 1 毫秒 (第 95 個百分位數)。區域與區域間流量之間的流量延遲差異應該可以忽略不計。相同地區中的區域間輸出流量價格可在 Compute Engine 定價頁面上找到。
準備資源調度
基礎架構
Kubernetes 工作負載需要網路、運算和儲存空間。您需要提供足夠的 CPU 與記憶體才能執行 Pod。不過，目前已有越來越多的基礎架構可能會影響 GKE 叢集的效能與擴充性。
叢集網路
GKE 提供兩種類型的叢集網路：較舊的路徑式與較新的虛擬私人雲端原生。
路徑式叢集：每次新增節點時，都會將自訂路徑新增到虛擬私人雲端網路中的路徑表。
虛擬私人雲端原生叢集：在這個模式中，虛擬私人雲端網路的次要範圍包含所有 Pod IP 位址。然後，系統會針對每個節點自己的 Pod IP 位址，為每個節點指派次要配量範圍。這樣一來，虛擬私人雲端網路一開始就能瞭解如何將路徑傳送至 Pod，而不用依賴自訂路徑。一個虛擬私人雲端網路最多可以有 1.5 萬個連線的 VM，因此，虛擬私人雲端原生叢集最多可以向上擴充到 5000 個節點。
管理虛擬私人雲端原生叢集中的 IP
虛擬私人雲端原生叢集針對節點使用主要 IP 範圍，針對 Pod 與 Service 使用兩個次要 IP 範圍。虛擬私人雲端原生叢集中的最大節點數會受到可用 IP 位址的限制。節點數由主要範圍 (節點子網路) 與次要範圍 (Pod 子網路) 決定。Pod 與 Service 的最大數量由叢集次要範圍大小、Pod 子網路與 Service 子網路分別決定。
根據預設：
- Pod 次要範圍預設為 /14 (262,144 個 IP 位址)。
- 每個節點都為其 Pod 指派 /24 範圍 (Pod 為 256 個 IP 地址)。
- 節點的子網路是 /20 (4092 個 IP 位址)。
不過，兩個範圍 (節點與 Pod) 中都必須有足夠的位址才能佈建新節點。根據預設，由於 Pod IP 數量的限制，只能建立 1024 個 IP 位址。
根據預設，每個節點最多可以有 110 個 Pod，且叢集中的每個節點都已為其 Pod 分配 /24 範圍。這會為每個節點產生 256 個 Pod IP。Kubernetes 如果擁有像 Pod 一樣達到大約兩倍的可用 IP 位址，便能夠在將 Pod 新增至節點或從節點移除 Pod 時減少 IP 位址的重複使用情形。不過，對於某些計劃為每個節點排定較少量 Pod 的應用程式而言，這多少有些浪費。彈性 Pod CIDR 功能允許配置 Pod 的每個節點 CIDR 區塊大小，並使用較少的 IP 位址。
根據預設，Service 的次要範圍設定為 /20 (4,096 個 IP 位址)，將叢集中的 Service 數量限制為 4096 個。
設定節點以提高效能
GKE 節點是一般的 GCP 虛擬機器。部分參數 (例如核心數量或磁碟大小) 可能會影響 GKE 叢集的執行方式。
輸出流量
在 GCP 中，分配給執行個體的核心數量決定了網路容量。一個虛擬核心提供 2 Gbps 的輸出頻寬，Skylake 機器的最大頻寬為 16 Gbps 或 32 Gbps (測試版功能)。 所有共用核心機器類型的限制都是 1 Gbps。
IOPS 與磁碟總處理量
在 GCP 中，永久磁碟的大小決定了磁碟的 IOPS 與總處理量。GKE 通常使用永久磁碟做為開機磁碟，並用來備份 Kubernetes 的永久磁碟區。增加磁碟大小也會同時提高 IOPS 與總處理量，直至達到特定限制為止。
每個永久磁碟的寫入作業都會計入虛擬機器執行個體的累積網路輸出上限。因此，磁碟的 IOPS 效能 (尤其是 SSD) 不但取決於磁碟大小，同時也取決於執行個體中的 vCPU 數量。由於寫入總處理量的網路輸出上限，較低的核心 VM 會有較低的寫入 IOPS 限制。
如果虛擬機器執行個體的 CPU 不足，應用程式將無法達到 IOPS 限制。根據一般規則，每 2000 到 2500 IOPS 的預期流量應要有 1 個可用 CPU。
需要高容量或大量磁碟的工作負載需要考慮可以將多少 PD 附加至單一 VM 的限制。對於一般 VM 而言，該限制為總大小 64 TB 的 128 個磁碟，而共用核心 VM 的限制是總大小 3 TB 的 16 個 PD。GCP 會強制執行此限制，而 Kubernetes 不會強制執行此限制。
瞭解限制
Kubernetes 與其他系統一樣，在設計應用程式及規劃應用程式的成長時，都有需要考慮的限制。
Kubernetes 支援單一叢集中存在最多 5000 個節點。但是，Kubernetes 是一個複雜的系統，具有較大的特徵面。節點數量只是 Kubernetes 是否能夠擴充的眾多維度之一。其他維度還包括 Pod、Service 或 Service 後端的總數。
您目前不應拓展超過一個以上的維度。即使是在較小的叢集中，這種壓力也可能會導致發生問題。
例如，嘗試在 5000 個節點的叢集中為每個節點排定 100 個 Pod 可能不會成功，因為 Pod 的數量、每個節點的 Pod 數量以及節點數量會被擴展得太大。
維度限制
您可以閱讀官方 Kubernetes 限制清單。
無論是這份清單還是以下範例都無法列出 Kubernetes 限制的完整清單。這些數字是在沒有安裝擴充功能的普通 Kubernetes 叢集上取得。使用 Webhook 或 CRD 擴充 Kubernetes 叢集的做法很常見，但可能會限制您擴充叢集的能力。
這些限制大部分都沒有強制執行，因此您可以超越這些限制。超出限制不會使叢集立即無法使用。在失敗之前，效能會先降低 (有時會透過失敗的 SLO 顯示)。此外，最大的叢集可能還存在一些限制。在較小的叢集中，限制的比例比較低。
每個節點的 Pod 數。GKE 對每個節點的 Pod 數量有 110 個的硬性限制。這會假設每個 Pod 平均有兩個或更少的容器。如果容器數量太多，可能會降低 110 個的限制，因為會為每個容器分配一些資源。
Service 總數應維持在 10000 個以下。如果服務太多，或者 Service 背後有大量的後端，iptables 的效能就會降低。
如果單一 Service 背後的 Pod 數保持在 250 個以下，那就是安全的。Kube-proxy 會在每個節點上執行，並監視對端點與 Service 進行的所有變更。因此叢集越大，要傳送的資料就越多。根據 Pod 名稱的長度及其命名空間而定，硬性限制約在 5000 個左右。如果長度較長，會在 etcd 中儲存更多位元組，其中端點物件會超過 etcd 列的大小上限。隨著後端流量越來越多，更新會變得很大，尤其是在大型叢集 (500 個以上的節點) 中。只要 Service 背後的 Pod 流失情況保持在最小程度，或者將叢集大小保持在較小的大小，您就可以稍微超越這個數量。
每個命名空間的 Service 數量不應超過 5000 個。在此之後，Service 環境變數的數量會超過殼層限制，導致 Pod 在啟動時當機。從 Kubernetes 1.13 開始，您可以將 PodSpec 中的
enableServiceLinks設定為 false，以停用填入這些變數。物件總數。叢集中的所有物件都有限制，包括內建與 CRD 物件在內。這取決於物件的大小 (etcd 會儲存多少位元組)；物件變更的頻率；以及存取模式 (例如，經常讀取特定類型的所有物件會更快地刪除 etcd)。
