Cluster Autoscaler

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

概觀

Kubernetes Cluster Autoscaler 是由 SIG Autoscaling 維護的熱門 Cluster Autoscaling 解決方案。它負責確保您的叢集有足夠的節點來排程您的 Pod，而不會浪費資源。它會監控無法排程的 Pod 和未充分利用的節點。然後，它會模擬節點的新增或移除，然後再將變更套用至叢集。Cluster Autoscaler 中的 AWS Cloud Provider 實作會控制 EC2 Auto Scaling 群組.DesiredReplicas的欄位。

本指南將提供心智模型，用於設定 Cluster Autoscaler 並選擇符合組織需求的最佳權衡集。雖然沒有單一最佳組態，但有一組組態選項可讓您權衡效能、可擴展性、成本和可用性。此外，本指南將提供最佳化 AWS 組態的秘訣和最佳實務。

詞彙表

本文件中將經常使用以下術語。這些術語可以有廣泛的意義，但僅限於以下定義，以用於本文件的目的。

可擴展性是指 Cluster Autoscaler 在 Kubernetes Cluster 數量增加時的效能。達到可擴展性限制時，Cluster Autoscaler 的效能和功能會降低。當 Cluster Autoscaler 超過其可擴展性限制時，可能不會再新增或移除叢集中的節點。

效能是指 Cluster Autoscaler 能夠做出和執行擴展決策的速度。完美執行的 Cluster Autoscaler 會立即做出決策並觸發擴展動作以回應刺激，例如 Pod 變得無法排程。

可用性表示可以快速排程 Pod，而不會中斷。這包括何時需要排程新建立的 Pod，以及向下擴展節點何時終止為其排程的任何剩餘 Pod。

成本取決於橫向擴展和縮減事件背後的決策。如果現有節點未充分利用，或新增了對傳入 Pod 太大的新節點，則會浪費資源。根據使用案例，由於積極縮減規模決策，提早終止 Pod 可能會產生相關成本。

節點群組是叢集內一組節點的抽象 Kubernetes 概念。它不是真正的 Kubernetes 資源，但以抽象形式存在於 Cluster Autoscaler、Cluster API 和其他元件中。節點群組內的節點共用標籤和污點等屬性，但可能包含多個可用區域或執行個體類型。

EC2 Auto Scaling 群組可以做為 EC2 上節點群組的實作。EC2 Auto Scaling 群組設定為啟動執行個體，以自動加入其 Kubernetes 叢集，並在 Kubernetes API 中將標籤和污點套用至其對應的節點資源。

EC2 受管節點群組是 EC2 上節點群組的另一個實作。它們可消除手動設定 EC2 Autoscaling 擴展群組的複雜性，並提供節點版本升級和正常節點終止等其他管理功能。

操作 Cluster Autoscaler

Cluster Autoscaler 通常會安裝為您叢集中的部署。它使用領導者選擇來確保高可用性，但工作是由單一複本一次完成。它不水平擴展。對於基本設定，預設應該使用提供的安裝說明，但有幾點需要記住。

請確定：

使用最低權限存取 IAM 角色

使用 Auto Discovery 時，強烈建議您透過限制動作autoscaling:SetDesiredCapacity和範圍為目前叢集的 Auto Scaling 群組autoscaling:TerminateInstanceInAutoScalingGroup來使用最低權限存取。

這將防止在一個叢集中執行的 Cluster Autoscaler 修改不同叢集中的節點群組，即使--node-group-auto-discovery引數沒有使用標籤縮小到叢集的節點群組 （例如 k8s.io/cluster-autoscaler/<cluster-name>)。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/enabled": "true",
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/<my-cluster>": "owned"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:DescribeScalingActivities",
                "autoscaling:DescribeTags",
                "ec2:DescribeImages",
                "ec2:DescribeInstanceTypes",
                "ec2:DescribeLaunchTemplateVersions",
                "ec2:GetInstanceTypesFromInstanceRequirements",
                "eks:DescribeNodegroup"
            ],
            "Resource": "*"
        }
    ]
}

設定節點群組

有效的自動擴展從為您的叢集正確設定一組節點群組開始。選取正確的節點群組集是將工作負載的可用性最大化並降低成本的關鍵。AWS 使用 EC2 Auto Scaling 群組實作節點群組，這些群組可靈活處理大量使用案例。不過，Cluster Autoscaler 會對您的節點群組進行一些假設。讓您的 EC2 Auto Scaling 群組組態與這些假設保持一致，可將不需要的行為降至最低。

請確定：

注意：建議使用 EKS 受管節點群組。受管節點群組隨附強大的管理功能，包括 Cluster Autoscaler 的功能，例如自動 EC2 Auto Scaling 群組探索和正常節點終止。

最佳化效能和可擴展性

了解自動擴展演算法的執行時間複雜性，可協助您調整 Cluster Autoscaler，在節點超過 1，000 個的大型叢集中繼續順暢運作。

用於調校 Cluster Autoscaler 可擴展性的主要旋鈕是提供給程序的資源、演算法的掃描間隔，以及叢集中的節點群組數量。此演算法的實際執行時間複雜性涉及其他因素，例如排程外掛程式複雜性和 Pod 數量。這些參數被視為無法設定的參數，因為它們對叢集的工作負載而言是自然的，而且無法輕鬆調校。

Cluster Autoscaler 會將整個叢集的狀態載入記憶體，包括 Pod、節點和節點群組。在每個掃描間隔，演算法會識別無法排程的 Pod，並模擬每個節點群組的排程。調校這些因素有不同的權衡，應仔細考慮您的使用案例。

垂直自動擴展叢集自動擴展器

將 Cluster Autoscaler 擴展至大型叢集的最簡單方法是增加其部署的資源請求。大型叢集的記憶體和 CPU 都應該增加，但這會因叢集大小而有很大差異。自動擴展演算法會將所有 Pod 和節點存放在記憶體中，在某些情況下，這可能會導致記憶體佔用量大於 1 GB。增加資源通常手動完成。如果您發現持續的資源調校造成操作負擔，請考慮使用附加元件恢復器或垂直 Pod Autoscaler。

減少節點群組的數量

將節點群組數量降至最低，是確保 Cluster Autoscaler 將繼續在大型叢集上正常運作的一種方式。對於每個團隊或每個應用程式建構其節點群組的一些組織而言，這可能具有挑戰性。雖然 Kubernetes API 完全支援此功能，但這被視為 Cluster Autoscaler 反模式，具有對可擴展性的影響。使用多個節點群組 （例如 Spot 或 GPUs) 的原因有很多，但在許多情況下，使用少量群組時，有替代設計可達到相同的效果。

請確定：

減少掃描間隔

低掃描間隔 （例如 10 秒） 可確保 Cluster Autoscaler 在 Pod 變得無法排程時盡快回應。不過，每次掃描都會對 Kubernetes API 和 EC2 Auto Scaling 群組或 EKS 受管節點群組 APIs 產生許多 API 呼叫。這些 API 呼叫可能會導致 Kubernetes 控制平面的速率限制，甚至無法使用服務。

預設掃描間隔為 10 秒，但在 AWS 上，啟動節點需要更長的時間才能啟動新的執行個體。這表示可以增加間隔，而不會顯著增加整體擴充規模時間。例如，如果啟動節點需要 2 分鐘的時間，將間隔變更為 1 分鐘將導致 6 倍的 API 呼叫減少，以降低 38% 的擴展速度。

跨節點群組碎片

Cluster Autoscaler 可設定為在特定的一組節點群組上操作。使用此功能，您可以部署 Cluster Autoscaler 的多個執行個體，每個執行個體都設定為在不同的一組節點群組上操作。此策略可讓您任意使用大量的節點群組，以交易成本實現可擴展性。我們只建議使用此做為改善效能的最後手段。

Cluster Autoscaler 原本不是為此組態設計，因此有一些副作用。由於碎片無法通訊，因此多個自動擴展器可能會嘗試排程無法排程的 Pod。這可能會導致多個節點群組不必要的向外擴展。這些額外的節點會在 之後縮減scale-down-delay。

metadata:
  name: cluster-autoscaler
  namespace: cluster-autoscaler-1

...

--nodes=1:10:k8s-worker-asg-1
--nodes=1:10:k8s-worker-asg-2

---

metadata:
  name: cluster-autoscaler
  namespace: cluster-autoscaler-2

...

--nodes=1:10:k8s-worker-asg-3
--nodes=1:10:k8s-worker-asg-4

請確定：

最佳化成本和可用性

Spot 執行個體

您可以在節點群組中使用 Spot 執行個體，並節省高達隨需價格 90% 的折扣，但當 EC2 需要恢復容量時，Spot 執行個體可以隨時中斷。當您的 EC2 Auto Scaling 群組因為缺乏可用容量而無法向上擴展時，就會發生容量不足錯誤。透過選取許多執行個體系列來最大化多樣性，可以利用許多 Spot 容量集區來增加實現所需擴展的機會，並減少 Spot 執行個體中斷對叢集可用性的影響。具有 Spot 執行個體的混合執行個體政策是在不增加節點群組數量的情況下增加多樣性的絕佳方式。請記住，如果您需要保證的資源，請使用隨需執行個體而非 Spot 執行個體。

設定混合執行個體政策時，所有執行個體類型都必須具有類似的資源容量。自動擴展器的排程模擬器會使用 MixedInstancePolicy 中的第一個 InstanceType。如果後續的執行個體類型較大，則擴展後可能會浪費資源。如果較小，由於容量不足，您的 Pod 可能無法在新執行個體上排程。例如，M4, M5, M5a 和 M5n 執行個體都有類似的 CPU 和記憶體數量，並且是 MixedInstancePolicy 的絕佳候選項目。EC2 Instance Selector 工具可協助您識別類似的執行個體類型。

建議將隨需和 Spot 容量隔離為不同的 EC2 Auto Scaling 群組。這優於使用基本容量策略，因為排程屬性基本上不同。由於 Spot 執行個體隨時都會中斷 （當 EC2 需要恢復容量時），使用者通常會污點其可先佔節點，因此需要明確 Pod 對先佔行為的容忍度。這些污點會導致節點的排程屬性不同，因此它們應該分成多個 EC2 Auto Scaling 群組。

Cluster Autoscaler 具有 Expanders 的概念，提供不同的策略來選擇要擴展的節點群組。此策略--expander=least-waste是良好的一般用途預設值，如果您要使用多個節點群組進行 Spot 執行個體多樣化 （如上圖所述），則可以透過擴展擴展在擴展活動後最適合使用的群組，進一步將節點群組成本最佳化。

排定節點群組 / ASG 的優先順序

您也可以使用優先順序擴展器來設定優先順序型自動擴展。 --expander=priority可讓您的叢集排定節點群組/ASG 的優先順序，如果因為任何原因而無法擴展，則會在優先順序清單中選擇下一個節點群組。例如，在您希望使用 P3 執行個體類型的情況下，這非常有用，因為其 GPU 為您的工作負載提供最佳效能，但做為第二個選項，您也可以使用 P2 執行個體類型。

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-priority-expander
  namespace: kube-system
data:
  priorities: |-
    10:
      - .*p2-node-group.*
    50:
      - .*p3-node-group.*

Cluster Autoscaler 將嘗試擴展符合 p3-node-group 名稱的 EC2 Auto Scaling 群組。 如果此操作未在 中成功--max-node-provision-time，則會嘗試擴展符合 p2-node-group 名稱的 EC2 Auto Scaling 群組。 此值預設為 15 分鐘，並且可以針對回應更靈敏的節點群組選擇進行減少，但是如果值太低，可能會導致不必要的向外擴展。

過度佈建

Cluster Autoscaler 可確保節點僅在需要時新增至叢集，並在未使用時移除，以將成本降至最低。這將顯著影響部署延遲，因為許多 Pod 會強制等待節點擴展，才能排程節點。節點可能需要數分鐘才能使用，這樣一來，便會使 Pod 排程延遲增加一個數量級。

這可以使用過度佈建，其會交易排程延遲的成本。過度佈建是使用具有負優先順序的暫時 Pod 實作，這會佔用叢集中的空間。當新建立的 Pod 無法排程且優先順序較高時，臨時 Pod 會先佔空間。然後，暫時 Pod 變得無法排程，觸發 Cluster Autoscaler 擴展新的過度佈建節點。

過度佈建還有其他較不明顯的好處。在不過度佈建的情況下，高度使用叢集的其中一個副作用是，Pod 會使用 Pod 或節點親和性preferredDuringSchedulingIgnoredDuringExecution規則來做出較不理想的排程決策。常見的使用案例是使用 AntiAffinity 跨可用區域區隔高可用性應用程式的 Pod。過度佈建可能會大幅增加可用正確區域節點的機會。

過度佈建的容量是組織謹慎的商業決策。其核心是效能和成本之間的權衡。做出此決策的其中一個方法是判斷您的平均擴展頻率，並將其除以擴展新節點所需的時間。例如，如果平均每 30 秒需要新的節點，而 EC2 需要 30 秒才能佈建新的節點，則過度佈建的單一節點將確保永遠有可用的額外節點，以單一額外 EC2 執行個體的成本將排程延遲減少 30 秒。為了改善區域排程決策，過度佈建多個節點，等同於 EC2 Auto Scaling 群組中的可用區域數量，以確保排程器可以為傳入的 Pod 選取最佳區域。

防止縮減規模

移出有些工作負載代價高昂。大數據分析、機器學習任務和測試執行器最終將完成，但如果中斷則必須重新啟動。Cluster Autoscaler 會嘗試縮減 scale-down-utilization-threshold 下的任何節點，這會中斷節點上任何剩餘的 Pod。這可以透過確保昂貴的 Pod 受到 Cluster Autoscaler 識別的標籤保護來防止。

請確定：

進階使用案例

EBS 磁碟區

持久性儲存對於建置具狀態的應用程式至關重要，例如資料庫或分散式快取。EBS 磁碟區會在 Kubernetes 上啟用此使用案例，但僅限於特定區域。如果針對每個 AZs使用個別的 EBS 磁碟區，在多個 AZ 之間分割，這些應用程式可以高度可用。然後，Cluster Autoscaler 可以平衡 EC2 Autoscaling 群組的擴展。

請確定：

共同排程

機器學習分散式訓練任務可從相同區域節點組態的最低延遲中獲益。這些工作負載會將多個 Pod 部署到特定區域。這可以透過使用 為所有共同排程的 Pod 或節點親和性設定 Pod 親和性來實現topologyKey: failure-domain.beta.kubernetes.io/zone。然後，Cluster Autoscaler 會擴展特定區域以符合需求。您可能想要配置多個 EC2 Auto Scaling 群組，每個可用區域一個，以啟用整個共同排程工作負載的容錯移轉。

請確定：

加速器

有些叢集會利用 GPU 等特殊硬體加速器。向外擴展時，加速器裝置外掛程式可能需要幾分鐘的時間來向叢集公告資源。Cluster Autoscaler 已模擬此節點將擁有加速器，但直到加速器準備就緒並更新節點的可用資源之前，無法在節點上排程待定 Pod。這可能會導致重複不必要的擴增。

此外，即使加速器未使用，具有加速器和高 CPU 或記憶體使用率的節點也不會考慮縮減規模。由於加速器的相對成本，這種行為可能很昂貴。相反地，如果節點有未佔用的加速器，Cluster Autoscaler 可以套用特殊規則來考慮縮減規模的節點。

為了確保這些案例的正確行為，您可以在加速器節點上設定 kubelet，以在節點加入叢集之前標記節點。Cluster Autoscaler 將使用此標籤選擇器來觸發加速器最佳化行為。

請確定：

從 0 擴展

Cluster Autoscaler 能夠在零之間擴展節點群組，進而大幅節省成本。它會檢查其 LaunchConfiguration 或 LaunchTemplate 中指定的 InstanceType，以偵測 Auto Scaling 群組的 CPU、記憶體和 GPU 資源。有些 Pod 需要額外的資源，例如 WindowsENI或 PrivateIPv4Address或特定的 NodeSelectors 或 Taints，這些資源無法從 LaunchConfiguration 中探索。Cluster Autoscaler 可以透過從 EC2 Auto Scaling 群組上的標籤探索它們來考慮這些因素。例如：

Key: k8s.io/cluster-autoscaler/node-template/resources/$RESOURCE_NAME
Value: 5
Key: k8s.io/cluster-autoscaler/node-template/label/$LABEL_KEY
Value: $LABEL_VALUE
Key: k8s.io/cluster-autoscaler/node-template/taint/$TAINT_KEY
Value: NoSchedule

注意：請記住，擴展至零時，您的容量會傳回 EC2，且未來可能無法使用。

其他參數

有許多組態選項可用來調整 Cluster Autoscaler 的行為和效能。您可以在 GitHub 上取得完整的參數清單。

其他資源

此頁面包含 Cluster Autoscaler 簡報和示範的清單。如果您想要在此處新增簡報或示範，請傳送提取請求。

參考