Cluster Autoscaler - Amazon EKS

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

Cluster Autoscaler

Kubernetes Cluster Autoscaler 會在 Pod 失敗或重新排程至其他節點時,自動調整叢集中的節點數。亦即,Kubernetes Cluster Autoscaler 中的 AWS Cloud Provider 實作會控制 .DesiredReplicas Auto Scaling 群組的 Amazon EC2 欄位。Cluster Autoscaler 通常會在您的叢集中安裝為 Deployment (部署)。它使用領導者選擇來確保高可用性,但擴展是由單一複本一次執行。

在部署 Cluster Autoscaler 之前,請務必了解 Kubernetes 概念與 AWS 功能的關係。本主題通篇使用下列術語:

  • Kubernetes – Cluster Autoscaler 進行排程和擴展的 Kubernetes 控制平面的核心元件。如需詳細資訊,請查看 上的 Kubernetes 控制平面常見問答集GitHub。

  • AWS Cloud provider – 實作 Kubernetes Cluster Autoscaler 的延伸,其會透過與AWS平台通訊 (例如 ),實作 Kubernetes Cluster Autoscaler 的判斷。 Amazon EC2如需詳細資訊,請前往 上的 AWS 上的 Cluster GitHubAutoscaler。

  • 節點群組 – 叢集中一組節點的 Kubernetes 抽象。節點群組不是真正的 Kubernetes 資源,但它們存在於 Cluster Autoscaler、Cluster API 和其他元件中做為抽象。單一節點群組中存在的節點可能共享數個屬性,例如標籤和植被。不過,它們仍可以由多個 可用區域或 執行個體類型組成。

  • Amazon EC2 Auto Scaling 群組 – 叢集 Autoscaler 使用AWS的 功能。Auto Scaling 群組適用於大量使用案例。 Amazon EC2 Auto Scaling 群組設定為執行會自動加入其 Kubernetes 叢集的執行個體。他們也會在 Kubernetes API 中,將標籤和 contains 套用到其對應的節點資源。

為了參考, 使用 受管節點群組 Amazon EC2 群組Auto Scaling實作,並與 Cluster Autoscaler 相容。

本主題示範如何將 Cluster Autoscaler 部署到Amazon EKS您的叢集,並將其設定為修改您的 Amazon EC2 Auto Scaling 群組。

Prerequisites

部署 Cluster Autoscaler 之前,您必須滿足下列必要條件。

  • 擁有現有的 Kubernetes 叢集 – 如果您尚無叢集,請查看 建立 Amazon EKS 叢集

  • 叢集現有的 IAM OIDC 提供者。若要判斷您是否擁有一個,或若要建立一個 (如果尚未建立),請查看 為您的叢集建立 IAM OIDC 提供者

  • 節點群組的Auto Scaling群組標籤 – Cluster Autoscaler 需要 群組上的下列標籤,才能自動探索這些Auto Scaling群組。如果您使用 eksctl 建立節點群組,則會自動套用這些標籤。如果您未使用 eksctl 來建立節點群組,則必須使用下列標籤手動標記Auto Scaling群組。如需詳細資訊,請前往 中的標記您的 Amazon EC2 資源Linux 執行個體的 Amazon EC2 使用者指南。

    金鑰 數值
    k8s.io/cluster-autoscaler/<cluster-name>

    owned

    k8s.io/cluster-autoscaler/enabled TRUE

建立 IAM 政策和角色

建立 IAM 政策,授與 Cluster Autoscaler 所需的許可給 IAM 角色。將 <example-values> (包括 <>) 取代為您在整個程序中您自己的值。

  1. 建立 IAM 政策。

    1. 將下列項目儲存至名為 的檔案cluster-autoscaler-policy.json。 如果您現有的節點群組是使用 建立eksctl,且您使用了 --asg-access 選項,則此政策已存在,您可以跳到步驟 2。

      { "Version": "2012-10-17", "Statement": [ { "Action": [ "autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeAutoScalingInstances", "autoscaling:DescribeLaunchConfigurations", "autoscaling:DescribeTags", "autoscaling:SetDesiredCapacity", "autoscaling:TerminateInstanceInAutoScalingGroup", "ec2:DescribeLaunchTemplateVersions" ], "Resource": "*", "Effect": "Allow" } ] }
    2. 使用下列命令建立政策。您可以變更 的值policy-name

      aws iam create-policy \ --policy-name AmazonEKSClusterAutoscalerPolicy \ --policy-document file://cluster-autoscaler-policy.json

      請記下輸出中傳回的 ARN,以便在後續步驟中使用。

  2. 您可以建立 IAM 角色,並使用 IAM 或 將 eksctl 政策連接至該角色AWS 管理主控台。選取含有您要用來建立角色之工具名稱的標籤。

    eksctl
    1. 如果您使用 建立叢集,請執行下列命令eksctl。 如果您使用 --asg-access 選項建立節點群組,請將 <AmazonEKSClusterAutoscalerPolicy> 取代為 為您IAM建立eksctl的政策名稱。政策名稱類似於 eksctl-<cluster-name>-nodegroup-ng-<xxxxxxxx>-PolicyAutoScaling

      eksctl create iamserviceaccount \ --cluster=<my-cluster> \ --namespace=kube-system \ --name=cluster-autoscaler \ --attach-policy-arn=arn:aws:iam::<AWS_ACCOUNT_ID>:policy/<AmazonEKSClusterAutoscalerPolicy> \ --override-existing-serviceaccounts \ --approve
    2. 如果您使用 --asg-access 選項建立節點群組,我們建議您分離 IAM 所建立的eksctl政策Amazon EKS 節點IAM角色,並連接到 為您的節點群組eksctl建立的 。將政策與節點IAM角色分離可讓 Cluster Autoscaler 正常運作,但不在您的節點上提供其他 Pod 政策中的許可。如需詳細資訊,請查看 中的移除 IAM 身分許可Linux 執行個體的 Amazon EC2 使用者指南。

    AWS 管理主控台
    1. 開啟位於 https://console.aws.amazon.com/iam/ 的 IAM 主控台。

    2. 在導覽窗格中,選擇 Roles (角色)Create role (建立新角色)

    3. Select type of trusted entity (選取信任的實體類型) 區段中,選擇 Web identity (Web 身分)

    4. Choose a web identity provider (選擇 Web 身分供應商) 區段中:

      1. 針對 Identity provider (身分提供者),選擇叢集的 URL。

      2. 針對 Audience (對象),選擇 sts.amazonaws.com.

    5. 選擇 Next: Permissions (下一步:許可)

    6. Attach Policy (附加原則) 區段中,選取 AmazonEKSClusterAutoscalerPolicy 您在步驟 1 建立的 政策,用於您的服務帳號。

    7. 選擇 Next: Tags (下一步:標籤)

    8. Add tags (optional) (新增標籤 (選用)) 畫面上,您可以新增帳戶的標籤。選擇 Next: Review (下一步:檢閱)

    9. 針對 Role name (角色名稱),輸入您的角色名稱,例如,AmazonEKSClusterAutoscalerRole, 然後選擇 Create role (建立角色)

    10. 建立角色之後,在主控台中選擇角色,以開啟角色進行編輯。

    11. 選擇 Trust Relationships (信任關係) 標籤,然後選擇 Edit Trust Relationship (編輯信任關係)

    12. 尋找與下列相似的行:

      "oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:aud": "sts.amazonaws.com"

      變更行,如下所示。以您叢集的 OIDC 供應商 ID 取代 <EXAMPLED539D4633E53DE1B716D3041E> (包括 <>)<region-code>,並以您叢集所在的區域程式碼取代 。

      "oidc.eks.<region-code>.amazonaws.com/id/<EXAMPLED539D4633E53DE1B716D3041E>:sub": "system:serviceaccount:kube-system:cluster-autoscaler"
    13. 選擇 Update Trust Policy (更新信任政策) 以完成操作。

部署 Cluster Autoscaler

完成以下步驟以部署 Cluster Autoscaler。我們建議您在將 Cluster Autoscaler 部署部署到正式環境叢集之前,先檢視部署考量和最佳化該部署。

部署 Cluster Autoscaler

  1. 部署 Cluster Autoscaler。

    kubectl apply -f https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml
  2. 使用您先前建立之 cluster-autoscaler 角色的 ARN 通知IAM服務帳號。將 <example values> 與您自己的值。

    kubectl annotate serviceaccount cluster-autoscaler \ -n kube-system \ eks.amazonaws.com/role-arn=arn:aws:iam::<AWS_ACCOUNT_ID>:role/<AmazonEKSClusterAutoscalerRole>
  3. 使用下列命令修補部署,將 cluster-autoscaler.kubernetes.io/safe-to-evict notion 新增至 Cluster Autoscaler Pod。

    kubectl patch deployment cluster-autoscaler \ -n kube-system \ -p '{"spec":{"template":{"metadata":{"annotations":{"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"}}}}}'
  4. 使用下列命令編輯 Cluster Autoscaler 部署。

    kubectl -n kube-system edit deployment.apps/cluster-autoscaler

    編輯cluster-autoscaler容器命令以取代 <YOUR CLUSTER NAME> (包括 <>),並新增下列選項。

    • --balance-similar-node-groups

    • --skip-nodes-with-system-pods=false

    spec: containers: - command: - ./cluster-autoscaler - --v=4 - --stderrthreshold=info - --cloud-provider=aws - --skip-nodes-with-local-storage=false - --expander=least-waste - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/<YOUR CLUSTER NAME> - --balance-similar-node-groups - --skip-nodes-with-system-pods=false

    儲存並關閉檔案以套用變更。

  5. 在 Web 瀏覽器中從 打開 Cluster Autoscaler 發行版本GitHub頁面,尋找符合您叢集 Kubernetes 主要和次要版本的最新 Cluster Autoscaler 版本。例如,如果叢集的 Kubernetes 版本是 1.19,請尋找開頭為 1.19. 的 Cluster Autoscaler 最新版本。記下該版本在下一個步驟中使用的語意版本編號 (1.19.n)。

  6. 使用下列命令,將 Cluster Autoscaler 映像標籤設定為您在前一個步驟中記錄的版本。Replace 1.19.n 與您自己的 值。

    kubectl set image deployment cluster-autoscaler \ -n kube-system \ cluster-autoscaler=k8s.gcr.io/autoscaling/cluster-autoscaler:v<1.19.n>

檢視 Cluster Autoscaler 日誌

部署 Cluster Autoscaler 之後,您可以檢視日誌並確認其正在監控您的叢集負載。

使用下列命令檢視 Cluster Autoscaler 日誌。

kubectl -n kube-system logs -f deployment.apps/cluster-autoscaler

輸出:

I0926 23:15:55.165842 1 static_autoscaler.go:138] Starting main loop I0926 23:15:55.166279 1 utils.go:595] No pod using affinity / antiaffinity found in cluster, disabling affinity predicate for this loop I0926 23:15:55.166293 1 static_autoscaler.go:294] Filtering out schedulables I0926 23:15:55.166330 1 static_autoscaler.go:311] No schedulable pods I0926 23:15:55.166338 1 static_autoscaler.go:319] No unschedulable pods I0926 23:15:55.166345 1 static_autoscaler.go:366] Calculating unneeded nodes I0926 23:15:55.166357 1 utils.go:552] Skipping ip-192-168-3-111.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166365 1 utils.go:552] Skipping ip-192-168-71-83.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166373 1 utils.go:552] Skipping ip-192-168-60-191.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166435 1 static_autoscaler.go:393] Scale down status: unneededOnly=false lastScaleUpTime=2019-09-26 21:42:40.908059094 ... I0926 23:15:55.166458 1 static_autoscaler.go:403] Starting scale down I0926 23:15:55.166488 1 scale_down.go:706] No candidates for scale down

部署考量

查看下列考量事項,以最佳化您的 Cluster Autoscaler 部署。

擴展考量

Cluster Autoscaler 可以設定為考慮節點的其他功能。這些功能可能包括連接到節點Amazon EBS的Amazon EC2磁碟區、節點類型和 GPU 加速器。

可用區域s

我們建議您設定多個節點群組,將每個群組範圍限定於單一 可用區域,並允許 --balance-similar-node-groups 功能。否則,如果您只建立一個節點群組,則可以將該節點群組範圍限定為跨多個 可用區域。

節點群組組成

Cluster Autoscaler 會假設您正在使用節點群組,例如您在群組中使用哪些執行個體類型。為了符合這些假設,請務必根據這些考量設定您的節點群組:

  • 節點群組中的每個節點都有相同的排程屬性,例如標籤、物件和資源。

    • 對於 MixedInstancePolicies,執行個體類型必須具有相同的 CPU、記憶體和 GPU 形狀。

    • 政策中指定的第一個執行個體類型會模擬排程。

    • 如果您的政策具有更多資源的額外執行個體類型,則資源可能會在向外擴展之後浪費。

    • 如果您的政策擁有的資源比原始執行個體類型少的額外執行個體類型,則 Pod 可能無法在執行個體上排程。

  • 建議您設定具有較大量節點 (而不是相反節點) 的更少量節點群組。這是因為相反的組態會對可擴展性造成負面影響。

  • 當兩個系統都提供支援時,我們建議您使用 Amazon EC2 功能。(例如,使用區域 和 MixedInstancePolicy。)

如果可能,建議您使用 受管節點群組。受管節點群組隨附有效的管理功能,包括 Cluster Autoscaler 的功能,例如自動Amazon EC2Auto Scaling群組探索和正常節點終止。

EBS 磁碟區

持久性儲存對於建置狀態應用程式 (例如資料庫和分散式快取) 至關重要。使用 Amazon EBS 磁碟區,您可以在 Kubernetes 上建置可設定狀態的應用程式,但您只能在特定區域中執行此操作。如需詳細資訊,請查看如何在 Amazon EKS? 中使用持久性儲存。如果將分片 (分割) 跨多個可用區域使用不同Amazon EBS磁碟區的 ,則狀態應用程式可高度可用可用區域。因此,Cluster Autoscaler 可以平衡Amazon EC2Auto Scaling群組的擴展。若要這樣做,請確定符合下列條件。

  • 透過設定 來支援節點群組平衡balance-similar-node-groups=true

  • 節點群組的設定相同可用區域,但 和 Amazon EBS 磁碟區不同。

共同排程

機器學習分散式訓練任務可大幅減少相同區域節點組態的延遲。這些工作負載會將多個 Pod 部署到特定區域。這可以透過使用 設定所有共同排程 Pod 或節點親和性來達成topologyKey: failure-domain.beta.kubernetes.io/zone。 根據此組態,Cluster Autoscaler 會擴展特定區域以符合需求。您可能想要配置多個Amazon EC2Auto Scaling群組,每個群組都有一個群組可用區域,以讓整個共同排程工作負載得以容錯移轉。請確定已滿足下列條件。

Accelerator 和 GPUs

有些 叢集利用專用硬體加速器,例如專用 GPU。進行向外擴展時,加速器裝置 plugin 可能需要幾分鐘的時間向叢集公告資源。在此期間,Cluster Autoscaler 會模擬此節點具有 加速器。不過,在加速器準備就緒並更新節點的可用資源之前,無法在節點上排程擱置中的 Pod。這可能會導致重複不必要的向外擴展。

具有 加速器以及高 CPU 或記憶體使用率的節點,即使加速器未使用,也不會視為會縮減規模。不過,這可能很昂貴。若要避免這些成本,Cluster Autoscaler 可以套用特殊規則,以考慮將具有無空加速器的節點向下擴展。

為確保這些案例的正確行為,您可以在加速器節點kubelet上設定 ,在加入叢集之前標記節點。Cluster Autoscaler 使用此標籤選取器來呼叫加速器最佳化行為。請確定已滿足下列條件。

  • 適用於 GPU 節點kubelet 的 已透過 設定--node-labels k8s.amazonaws.com/accelerator=$ACCELERATOR_TYPE

  • 具有 加速器的節點遵守相同的排程屬性規則。

從零擴展

Cluster Autoscaler 可以將節點群組從零擴展到零,大幅節省成本。它會檢查 或 Auto Scaling 中指定的 ,以偵測 InstanceType 群組的 CPU、記憶體LaunchConfiguration和 GPU 資源LaunchTemplate。 有些 Pod 需要其他資源 (例如 WindowsENIPrivateIPv4Address 或 特定 NodeSelectors Taints 或 ),而無法從 探索這些資源LaunchConfiguration。 Cluster Autoscaler 可透過從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
注意

擴展至零時,您的容量會傳回給 Amazon EC2 ,且未來可能無法使用。

其他組態參數

有許多組態選項可用於調整 Cluster Autoscaler 的行為和效能。如需參數的完整清單,請查看 上的哪些參數要傳送至 GitHubCA?。

效能考量

您可以變更以調整 Cluster Autoscaler 效能和可擴展性的主要項目,是提供給程序的資源、演算法的掃描間隔,以及叢集中的節點群組數量。此演算法的真正執行時間複雜性涉及其他因素,例如,排程嵌入式複雜性和裝置數量。這些視為無法設定的參數,因為它們對叢集的工作負載而言很自然,並且無法輕鬆調校。

可擴展性是指 Cluster Autoscaler 在 Kubernetes 叢集中的 Pod 和節點數量增加時,執行效果有多好。如果達到可擴展性限制,Cluster Autoscaler 的效能和功能會降級。此外,當它超過其可擴展性限制時,Cluster Autoscaler 就無法再在叢集中新增或移除節點。

效能是指 Cluster Autoscaler 可以多快做出並實作擴展選擇。效能最佳的 Cluster Autoscaler 會立即做出判斷,並叫用擴展動作來回應刺激,例如裝置變得無法排程。

熟悉自動調整規模演算法的執行時間複雜性,可讓調校 Cluster Autoscaler 時更順利地在大型叢集中 (有超過 1,000 個節點) 運作。

Cluster Autoscaler 會將整個叢集的狀態載入記憶體,包括 Pod、節點和節點群組。在每個掃描間隔,演算法會辨識無法排程的裝置,並模擬每個節點群組的排程。調整這些因素伴隨著不同的權衡,應該仔細考慮。

垂直自動擴展

將 Cluster Autoscaler 擴展至較大叢集的最簡單方式,是增加其部署的資源請求。針對大型叢集來增加記憶體和 CPU,但這應該會隨叢集大小而明顯不同。自動擴展演算法將所有裝置和節點存放在記憶體中。在某些案例中,這會導致大於 GB 的記憶體使用量。提高資源通常手動完成。如果您發現持續資源調校會造成操作負擔,請考慮使用 Addon ResizerVertical Pod Autoscaler。

減少節點群組數量

將節點群組數量降至最低,是確保 Cluster Autoscaler 在大型叢集上表現良好的其中一種方式。如果您以單一團隊或應用程式為基礎建構節點群組,這可能會是很具挑戰性的。即使 Kubernetes API 完全支援此項目,這仍視為 Cluster Autoscaler 反模式模式,具有可重複使用的擴展性。使用多個節點群組的原因很多,例如 Spot 或 GPU 執行個體。在許多案例中,還有其他設計在使用少量的群組時也能達到相同效果。請確定已滿足下列條件。

  • Pod 隔離是使用命名空間來完成,而非節點群組。

    • 這在低信任多租用叢集中可能無法實現。

    • 裝置ResourceRequestsResourceLimits 已正確設定,以避免資源爭用。

    • 較大的執行個體類型會造成更理想的 bin packing 和降低系統裝置額外負荷。

  • NodeTaintsNodeSelectors 用來排程 Pod 做為例外,而不是做為規則。

  • 區域資源定義為具有多個 的單一Amazon EC2Auto Scaling群組可用區域。

減少掃描間隔

低掃描間隔 (例如 10 秒) 可確保 Cluster Autoscaler 在裝置變成無法排程時盡快回應。不過,每次掃描都會造成 Kubernetes API 和 Amazon EC2 Auto Scaling 群組或Amazon EKS受管節點群組 有許多 API 呼叫APIs。 這些 API 呼叫可能導致您的 Kubernetes 控制平面的速率限制或甚至服務無法使用。

預設掃描間隔為 10 秒,但在 AWS上,發出節點會花費很長的時間來執行新的執行個體。這表示您可以增加間隔,而不需大幅增加整體擴展時間。例如,如果需要兩分鐘來推出節點,將間隔變更為一分鐘會導致取捨 6x的 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

請確定下列條件為 true。

  • 每個碎片都設定為指向一組獨特的 Amazon EC2 Auto Scaling 群組。

  • 每個碎片會部署到單獨的命名空間,以避免領導者選擇衝突。

成本效益與可用性

調校 Cluster Autoscaler 成本效益的主要選項與設定Amazon EC2執行個體有關。此外,成本效益必須與可用性達成平衡。本節描述各種策略,例如使用 Spot 執行個體來降低成本,以及在建立新節點時過度配置以降低延遲。

  • 可用性 – Pod 可以快速排程,不會中斷。即使當需要排程新建立的 Pod,以及當向下擴展節點終止任何排程的剩餘 Pod 時,也是如此。

  • Cost – (成本) 根據向外擴展和縮小事件來判斷。如果現有節點使用率過低,或新增節點對傳入裝置太大,則會浪費資源。根據特定的使用案例,可能會因積極的縮減規模而與提早終止 Pod 相關的成本。

Spot 執行個體

您可以在您的節點群組中使用 Spot 執行個體,並節省高達隨需價格的 90%。當 Amazon EC2 需要取回容量時,這隨時會中斷 Spot 執行個體的取捨。Insufficient Capacity Errors 只要 群組因為缺少可用容量Amazon EC2Auto Scaling而無法擴展,就會發生 。選取許多不同的執行個體系列有兩個主要優點。首先,您可以利用許多 Spot 容量集區來增加達到所需規模的機會。其次,它也可以降低 Spot 執行個體中斷對叢集可用性的影響。使用 Spot 執行個體的混合執行個體政策是增加多樣性的好方法,而不會增加節點群組的數量。不過,請注意,如果您需要保證資源,請使用隨需執行個體,而不是 Spot 執行個體。

Spot 執行個體可能會在執行個體需求增加時終止。如需詳細資訊,請查看 的 Spot 執行個體中斷部分Linux 執行個體的 Amazon EC2 使用者指南。AWS 節點終止處理常式專案會在節點停機時自動提醒 Kubernetes 控制平面。專案使用 Kubernetes API 來圍住節點,以確保不會在該處排定任何新工作,然後耗盡該專案並移除任何現有工作。

設定混合執行個體政策時,所有執行個體類型都具有類似的資源容量至關重要。自動擴展器的排程模擬器使用混合執行個體政策的第一個執行個體類型。如果後續執行個體類型較大,資源可能會在擴展之後浪費。如果較小的,您的裝置可能會因為容量不足而無法在新的執行個體上排程。例如M4,、 M5 M5a,M5n 執行個體都有類似的 CPU 和記憶體數量,並且是混合執行個體政策的良好候選者。執行個體Amazon EC2選取器工具可協助您辨識類似的執行個體類型。如需詳細資訊,請前往 上的 Instance Selector (Amazon EC2執行個體選擇器GitHub)。

我們建議您將您的隨需和 Spot 執行個體容量隔離成不同的 Amazon EC2 Auto Scaling 群組。建議不要使用基本容量策略,因為隨需和 Spot 執行個體的排程屬性不同。Spot 執行個體可以隨時中斷。當 Amazon EC2 需要取回容量時,會經常將前導節點分,因此需要明確 Pod 公差,才能避免發生前述行為。這會導致節點有不同的排程屬性,因此應將其分成多個Amazon EC2Auto Scaling群組。

Cluster Autoscaler 涉及 Expanders 的概念。它們共同提供不同的策略,以選取要擴展的節點群組。此策略--expander=least-waste是良好的一般用途預設值,如果您要將多個節點群組用於 Spot 執行個體分散,如先前所述,它可以透過擴展 群組 (在擴展活動之後將最適合使用),進一步將節點群組成本最佳化。

排定節點群組或Auto Scaling群組的優先順序

您也可以使用 Priority 擴展器設定以優先順序為基礎的自動擴展。--expander=priority 可讓叢集將節點群組的優先順序設為優先Auto Scaling,如果群組因為任何原因而無法擴展,則會選擇優先順序清單中的下一個節點群組。例如,當您想要使用 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 會嘗試擴展符合名稱 的Amazon EC2Auto Scaling群組p2-node-group。 如果此操作在 中不成功--max-node-provision-time,則會嘗試擴展符合名稱 的 Amazon EC2 Auto Scaling 群組p3-node-group。 此值預設為 15 分鐘,而且如果值太低,則可以減少以回應性更高的節點群組選擇,但可能會導致不必要的向外擴展。

Overprovisioning

Cluster Autoscaler 可確保節點僅在需要時新增至叢集,並在未使用時遭到移除,藉此將成本降至最低。這會大幅影響部署延遲,因為許多裝置被迫等待節點擴展,然後才能排程。節點可能需要多個分鐘才會可供使用,這可能會增加裝置排程延遲的量級。

這可透過過度配置來緩解,這會對排程延遲的成本進行交易。過度配置是使用優先順序為負的臨時裝置來實作。這些 Pod 包含在叢集中的空間。當新建立的 Pod 無法排程且優先順序較高時,臨時的 Pod 會優先預留空間。然後,臨時裝置會變得無法排程,導致 Cluster Autoscaler 擴展新的預留節點。

過度配置有其他優點。若無須過度配置,則高度使用叢集中的 Pod 會使得使用該preferredDuringSchedulingIgnoredDuringExecution規則的最佳排程判斷較不理想。此項目的常用案例是使用 為高可用性應用程式分隔 可用區域 AntiAffinityPod。 過度配置可能會大幅增加所需區域的節點可用的機率。

選擇正確的過度配置容量數量很重要。判斷此判斷的其中一種方法是判斷您的平均擴展頻率,並將此數字除以擴展新節點所需的時間量。例如,如果平均每隔 30 秒需要新節點,且Amazon EC2需要 30 秒來配置新節點,則透過配置的單一節點可確保永遠有額外節點可用。如此可降低排程延遲 30 秒,但只需要多一個Amazon EC2執行個體。若要改善區域排程的判斷,您可以覆寫要等於Amazon EC2Auto Scaling群組中可用區域數量的節點數量。這樣做可確保排程器可以為傳入的裝置選取最佳區域。

防止縮減移出

有些工作負載的移出成本很高。大數據分析、機器學習任務和測試執行器可能需要很長的時間才能完成,若中斷則必須重新開機。Cluster Autoscaler 函數可縮減 下的任何節點scale-down-utilization-threshold。 這會中斷節點上剩餘的任何裝置。不過,您可以確保昂貴的移出裝置受到 Cluster Autoscaler 辨識的標籤保護,以防止發生此問題。若要這樣做,請確定用於移出的 Pod 成本很高,且具有 標籤cluster-autoscaler.kubernetes.io/safe-to-evict=false