節點自動擴縮
為了在叢集中執行工作負載，你需要節點。叢集中的節點可以被**自動擴縮**——動態**供給**或**整合**，以提供所需容量並最佳化成本。自動擴縮由節點**自動擴縮器**執行。
節點供給
如果叢集中有 Pod 無法排程到現有節點上，可以自動向叢集新增新節點（**供給**）以容納這些 Pod。這在 Pod 數量隨時間變化時特別有用，例如由於結合水平工作負載自動擴縮和節點自動擴縮。
自動擴縮器透過建立和刪除其背後的雲提供商資源來供給節點。最常見的是，支援節點的資源是虛擬機器。
供給的主要目標是使所有 Pod 都可以排程。這個目標並非總是可以實現，因為存在各種限制，包括達到配置的供給限制，供給配置與特定 Pod 集不相容，或雲提供商容量不足。在供給時，節點自動擴縮器通常會嘗試實現其他目標（例如最小化供給節點的成本或平衡故障域之間的節點數量）。
節點自動擴縮器在決定要供給的節點時有兩個主要輸入：Pod 排程約束和自動擴縮器配置施加的節點約束。
自動擴縮器配置還可以包括其他節點供給觸發器（例如，節點數量低於配置的最小限制）。
注意
在 Cluster Autoscaler 中，供給以前稱為**擴容**。Pod 排程約束
Pod 可以表達排程約束來限制它們可以排程到的節點型別。節點自動擴縮器會考慮這些約束，以確保待處理的 Pod 可以排程到供給的節點上。
最常見的排程約束是 Pod 容器指定的資源請求。自動擴縮器將確保供給的節點具有足夠的資源來滿足這些請求。但是，它們不直接考慮 Pod 執行後實際的資源使用情況。為了根據實際工作負載資源使用情況自動擴縮節點，你可以將水平工作負載自動擴縮與節點自動擴縮結合使用。
其他常見的 Pod 排程約束包括節點親和性、Pod 間親和性或對特定儲存卷的要求。
自動擴縮器配置施加的節點約束
供給節點的具體細節（例如資源量、是否存在給定標籤）取決於自動擴縮器配置。自動擴縮器可以從預定義的節點配置集中選擇它們，或使用自動供給。
自動供給
節點自動供給是一種供給模式，使用者無需完全配置可以供給的節點的具體細節。相反，自動擴縮器根據其響應的待處理 Pod 以及預配置的約束（例如，最小資源量或對給定標籤的需求）動態選擇節點配置。
節點整合
執行叢集時主要考慮的是確保所有可排程的 Pod 都在執行，同時將叢集成本保持在儘可能低的水平。為了實現這一目標，Pod 的資源請求應儘可能多地利用節點的資源。從這個角度來看，叢集中的整體節點利用率可以作為叢集成本效益的衡量標準。
注意
正確設定 Pod 的資源請求對於叢集的整體成本效益與最佳化節點利用率一樣重要。將節點自動擴縮與垂直工作負載自動擴縮結合使用可以幫助你實現這一目標。叢集中的節點可以自動**整合**，以提高整體節點利用率，進而提高叢集的成本效益。整合透過從叢集中移除一組利用率不足的節點來實現。另外，可以供給一組不同的節點來替換它們。
整合和供給一樣，在做出決策時只考慮 Pod 資源請求，而不考慮實際資源使用情況。
出於整合目的，如果節點上只執行 DaemonSet 和靜態 Pod，則該節點被認為是**空**的。在整合過程中移除空節點比移除非空節點更直接，自動擴縮器通常具有專門為整合空節點而設計的最佳化。
在整合過程中移除非空節點具有破壞性——執行在它們上面的 Pod 會被終止，並可能需要重新建立（例如透過 Deployment）。但是，所有這些重新建立的 Pod 都應該能夠在叢集中的現有節點上排程，或者作為整合一部分供給的替換節點上排程。**在整合過程中，通常不應有 Pod 變成待處理狀態。**
注意
自動擴縮器會預測在節點供給或整合後，重新建立的 Pod 將如何排程，但它們不控制實際排程。因此，一些 Pod 可能會由於整合而變成待處理狀態——例如，如果在執行整合時出現了一個全新的 Pod。自動擴縮器配置還可以根據其他條件（例如，節點建立以來經過的時間）觸發整合，以最佳化不同的屬性（例如，叢集中節點的最大生命週期）。
整合的具體執行方式取決於給定自動擴縮器的配置。
注意
在 Cluster Autoscaler 中，整合以前稱為**縮容**。自動擴縮器
前面幾節中描述的功能由節點**自動擴縮器**提供。除了 Kubernetes API，自動擴縮器還需要與雲提供商 API 互動以供給和整合節點。這意味著它們需要與每個受支援的雲提供商進行顯式整合。給定自動擴縮器的效能和功能集可能因雲提供商整合而異。
自動擴縮器實現
Cluster Autoscaler 和 Karpenter 是目前由 SIG Autoscaling 贊助的兩個節點自動擴縮器。
從叢集使用者的角度來看，這兩個自動擴縮器都應該提供類似的節點自動擴縮體驗。兩者都將為無法排程的 Pod 供給新節點，並且都將整合不再以最佳方式利用的節點。
不同的自動擴縮器也可能提供此頁面描述的節點自動擴縮範圍之外的功能，這些附加功能可能有所不同。
請查閱以下部分以及各個自動擴縮器的連結文件，以決定哪個自動擴縮器更適合你的用例。
Cluster Autoscaler
Cluster Autoscaler 向預配置的**節點組**新增或刪除節點。節點組通常對映到某種雲提供商資源組（最常見的是虛擬機器組）。單個 Cluster Autoscaler 例項可以同時管理多個節點組。在供給時，Cluster Autoscaler 會將節點新增到最符合待處理 Pod 請求的組中。在整合時，Cluster Autoscaler 總是選擇要移除的特定節點，而不是僅僅調整底層雲提供商資源組的大小。
附加背景資訊
Karpenter
Karpenter 根據叢集操作員提供的 NodePool 配置自動供給節點。Karpenter 處理節點生命週期的所有方面，而不僅僅是自動擴縮。這包括在節點達到一定生命週期後自動重新整理節點，以及在新工作節點映象釋出時自動升級節點。它直接與單個雲提供商資源（最常見的是單個虛擬機器）配合使用，不依賴於雲提供商資源組。
附加背景資訊
實現比較
Cluster Autoscaler 和 Karpenter 的主要區別
- Cluster Autoscaler 僅提供與節點自動擴縮相關的功能。Karpenter 具有更廣泛的範圍，還提供用於管理節點生命週期的功能（例如，利用中斷在節點達到一定生命週期後自動重新建立它們，或將它們自動升級到新版本）。
- Cluster Autoscaler 不支援自動供給，它可以供給的節點組必須預先配置。Karpenter 支援自動供給，因此使用者只需配置一組供給節點的約束，而無需完全配置同構組。
- Cluster Autoscaler 直接提供雲提供商整合，這意味著它們是 Kubernetes 專案的一部分。對於 Karpenter，Kubernetes 專案將 Karpenter 作為庫釋出，雲提供商可以整合它來構建節點自動擴縮器。
- Cluster Autoscaler 集成了眾多雲提供商，包括較小和不太流行的提供商。與 Karpenter 整合的雲提供商較少，包括 AWS 和 Azure。
結合工作負載和節點自動擴縮
水平工作負載自動擴縮
節點自動擴縮通常響應 Pods——它會供給新節點以容納不可排程的 Pods，然後在 Pods 不再需要時整合這些節點。
水平工作負載自動擴縮自動擴縮工作負載副本的數量，以在副本中保持所需的平均資源利用率。換句話說，它會響應應用程式負載自動建立新 Pods，然後在負載降低時移除 Pods。
你可以將節點自動擴縮與水平工作負載自動擴縮結合使用，以根據 Pods 的平均實際資源利用率自動擴縮叢集中的節點。
如果應用程式負載增加，其 Pods 的平均利用率也應增加，從而促使工作負載自動擴縮建立新的 Pods。節點自動擴縮應隨後供給新節點以容納新 Pods。
一旦應用程式負載降低，工作負載自動擴縮應移除不必要的 Pods。節點自動擴縮應反過來整合不再需要的節點。
如果配置正確，這種模式可確保你的應用程式始終具有節點容量以應對可能需要的負載高峰，但你在不需要容量時無需為此付費。
垂直工作負載自動擴縮
使用節點自動擴縮時，正確設定 Pod 資源請求非常重要。如果給定 Pod 的請求過低，為它供給新節點可能無法幫助該 Pod 實際執行。如果給定 Pod 的請求過高，它可能會錯誤地阻止整合其節點。
垂直工作負載自動擴縮根據 Pods 的歷史資源使用情況自動調整其資源請求。
你可以將節點自動擴縮與垂直工作負載自動擴縮結合使用，以調整 Pods 的資源請求，同時保留叢集中的節點自動擴縮能力。
注意
使用節點自動擴縮時，不建議為 DaemonSet Pod 設定垂直工作負載自動擴縮。自動擴縮器必須預測新節點上的 DaemonSet Pod 將是什麼樣子，才能預測可用的節點資源。垂直工作負載自動擴縮可能會使這些預測不可靠，從而導致錯誤的擴縮決策。相關元件
本節描述了提供與節點自動擴縮相關功能的元件。
Descheduler
descheduler 是一個提供基於自定義策略的節點整合功能以及其他與最佳化節點和 Pod 相關的特性（例如刪除頻繁重啟的 Pod）的元件。
基於叢集大小的工作負載自動擴縮器
Cluster Proportional Autoscaler 和 Cluster Proportional Vertical Autoscaler 根據叢集中的節點數量提供水平和垂直工作負載自動擴縮。你可以在基於叢集大小的自動擴縮中閱讀更多資訊。
下一步
- 閱讀關於工作負載級別自動擴縮