本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Cluster Autoscaler **提示** 透過 Amazon EKS 研討會[探索](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)最佳實務。 ## 概觀 [Kubernetes Cluster Autoscaler ](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)是由 [SIG Autoscaling 維護的熱門 Cluster Autoscaling](https://github.com/kubernetes/community/tree/master/sig-autoscaling) 解決方案。它負責確保您的叢集有足夠的節點來排程您的 Pod，而不會浪費資源。它會監控無法排程的 Pod，以及未充分利用的節點。然後，它會模擬在將變更套用至叢集之前新增或移除節點。Cluster Autoscaler 中的 AWS 雲端提供者實作會控制 EC2 Auto Scaling 群組`.DesiredReplicas`的欄位。 ![\[架構\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/autoscaling/cas_architecture.png) 本指南將提供心理模型，用於設定 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 通常會安裝為您叢集中的[部署](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/aws/examples)。它使用[領導者選擇](https://en.wikipedia.org/wiki/Leader_election)來確保高可用性，但工作一次由單一複本完成。它無法水平擴展。對於基本設定，預設應該使用提供的[安裝說明](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html)立即可用，但有幾件事需要記住。 請確認以下事項： + Cluster Autoscaler 的版本符合叢集的版本。[未測試或支援](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/README.md#releases)跨版本相容性。 + 除非您有特定的進階使用案例阻止使用此模式，否則會啟用[自動探索](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/aws#auto-discovery-setup)。 ### 使用最低權限存取 IAM 角色 使用 [Auto Discovery](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#Auto-discovery-setup) 時，強烈建議您透過限制動作`autoscaling:SetDesiredCapacity`和範圍為目前叢集的 Auto Scaling 群組`autoscaling:TerminateInstanceInAutoScalingGroup`來使用最低權限存取。 這可防止在一個叢集中執行的 Cluster Autoscaler 修改不同叢集中的節點群組，即使`--node-group-auto-discovery`引數沒有使用標籤縮小到叢集的節點群組 （例如 `k8s.io/cluster-autoscaler/`)。 ``` { "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 群組組態與這些假設保持一致，可將不需要的行為降至最低。 請確認以下事項： + 節點群組中的每個節點都有相同的排程屬性，例如標籤、標記和資源。 + 對於 MixedInstancePolicies，CPU、記憶體和 GPU 的執行個體類型必須具有相同的形狀 + 政策中指定的第一個執行個體類型將用於模擬排程。 + 如果您的政策有其他具有更多資源的執行個體類型，則縮減後可能會浪費資源。 + 如果您的政策有其他資源較少的執行個體類型，則 Pod 可能無法在執行個體上排程。 + 具有多個節點的節點群組優先於具有較少節點的多個節點群組。這將對可擴展性產生最大的影響。 + 盡可能在兩個系統提供支援時偏好 EC2 功能 （例如 區域、MixedInstancePolicy) **注意** 建議使用 [EKS 受管節點群組](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)。受管節點群組隨附強大的管理功能，包括 Cluster Autoscaler 的功能，例如自動 EC2 Auto Scaling 群組探索和正常節點終止。 ## 最佳化效能和可擴展性 了解自動擴展演算法的執行時間複雜性，可協助您調整 Cluster Autoscaler，在節點超過 [1，000](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/proposals/scalability_tests.md) 個的大型叢集中繼續順暢運作。 用於調校 Cluster Autoscaler 可擴展性的主要旋鈕是提供給程序的資源、演算法的掃描間隔，以及叢集中的節點群組數量。此演算法的實際執行時間複雜性涉及其他因素，例如排程外掛程式複雜性和 Pod 數量。這些被視為無法設定的參數，因為這些參數對叢集的工作負載而言是自然的，而且無法輕鬆調校。 Cluster Autoscaler 會將整個叢集的狀態載入記憶體，包括 Pod、節點和節點群組。在每個掃描間隔，演算法會識別無法排程的 Pod，並模擬每個節點群組的排程。調校這些因素有不同的權衡，應仔細考慮您的使用案例。 ### 垂直自動擴展 Cluster Autoscaler 將 Cluster Autoscaler 擴展至大型叢集的最簡單方法是增加其部署的資源請求。大型叢集的記憶體和 CPU 都應該增加，但這會因叢集大小而有很大差異。自動擴展演算法會將所有 Pod 和節點存放在記憶體中，在某些情況下，這可能會導致記憶體佔用空間大於 1 GB。增加資源通常手動完成。如果您發現持續的資源調校正在造成操作負擔，請考慮使用[附加元件恢復器](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer)或[垂直 Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)。 ### 減少節點群組的數量 將節點群組數量降至最低，是確保 Cluster Autoscaler 能在大型叢集上繼續正常運作的一種方式。對於每個團隊或每個應用程式建構其節點群組的一些組織而言，這可能具有挑戰性。雖然 Kubernetes API 完全支援此功能，但這被視為具有可擴展性影響的 Cluster Autoscaler 反模式。使用多個節點群組 （例如 Spot 或 GPUs) 有許多原因，但在許多情況下，有替代設計可在使用少量群組時達到相同的效果。 請確認以下事項： + Pod 隔離是使用命名空間而非節點群組來完成。 + 這可能無法在低信任的多租戶叢集中實現。 + Pod ResourceRequests 和 ResourceLimits 已正確設定，以避免資源爭用。 + 較大的執行個體類型將產生更理想的儲存貯體封裝，並減少系統 Pod 額外負荷。 + NodeTaints 或 NodeSelectors 用於將 Pod 排程為例外狀況，而非規則。 + 區域資源定義為具有多個可用區域的單一 EC2 Auto Scaling 群組。 ### 減少掃描間隔 低掃描間隔 （例如 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 ``` 請確認以下事項： + 每個碎片都設定為指向一組唯一的 EC2 Auto Scaling 群組 + 每個碎片都會部署到個別的命名空間，以避免領導者選擇衝突 ## 最佳化成本和可用性 ### Spot 執行個體 您可以在節點群組中使用 Spot 執行個體，並節省高達隨需價格 90% 的折扣，但當 EC2 需要恢復容量時，Spot 執行個體可以隨時中斷權衡。當您的 EC2 Auto Scaling 群組因為缺乏可用容量而無法擴展時，會發生容量不足錯誤。透過選取多個執行個體系列來最大化多樣性，可以利用許多 Spot 容量集區來增加實現所需擴展的機會，並減少 Spot 執行個體中斷對叢集可用性的影響。具有 Spot 執行個體的混合執行個體政策是在不增加節點群組數量的情況下增加多樣性的絕佳方式。請記住，如果您需要保證的資源，請使用隨需執行個體而非 Spot 執行個體。 設定混合執行個體政策時，所有執行個體類型都必須具有類似的資源容量。自動擴展器的排程模擬器使用 MixedInstancePolicy 中的第一個 InstanceType。如果後續執行個體類型較大，則擴展後可能會浪費資源。如果較小，由於容量不足，您的 Pod 可能無法在新執行個體上排程。例如，M4, M5, M5a 和 M5n 執行個體都有類似的 CPU 和記憶體數量，並且是 MixedInstancePolicy 的理想候選項目。[EC2 Instance Selector](https://github.com/aws/amazon-ec2-instance-selector) 工具可協助您識別類似的執行個體類型。 ![\[spot_mix_instance_policy\]](http://docs.aws.amazon.com/zh_tw/eks/latest/best-practices/images/autoscaling/cas_spot_mix_instance_policy.jpg) 建議將隨需和 Spot 容量隔離為不同的 EC2 Auto Scaling 群組。這優於使用[基本容量策略](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-instances-distribution)，因為排程屬性基本上不同。由於 Spot 執行個體隨時都會中斷 （當 EC2 需要恢復容量時），因此使用者通常會將可先佔節點污點化，要求對先佔行為進行明確的 Pod 容錯。這些污點會導致節點的排程屬性不同，因此它們應該分成多個 EC2 Auto Scaling 群組。 Cluster Autoscaler 具有 [Expanders](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-are-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 排程延遲增加一個數量級。 這可以使用[過度佈建](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#how-can-i-configure-overprovisioning-with-cluster-autoscaler)，其會交易排程延遲的成本。過度佈建是使用具有負優先順序的暫時 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 識別的標籤保護來防止。 請確認以下事項： + 昂貴的移出 Pod 具有 註釋 `cluster-autoscaler.kubernetes.io/safe-to-evict=false` ## 進階使用案例 ### EBS 磁碟區 持久性儲存對於建置具狀態的應用程式至關重要，例如資料庫或分散式快取。[EBS 磁碟區](https://aws.amazon.com/premiumsupport/knowledge-center/eks-persistent-storage/)會在 Kubernetes 上啟用此使用案例，但僅限於特定區域。如果針對每個 AZs使用個別的 EBS 磁碟區，在多個 AZ 之間分割，這些應用程式可以高度使用。然後，Cluster Autoscaler 可以平衡 EC2 Autoscaling 群組的擴展。 請確認以下事項： + 節點群組平衡是藉由設定 `balance-similar-node-groups=true` 啟用的。 + 節點群組的設定相同，但不同的可用區域和 EBS 磁碟區除外。 ### 共同排程 機器學習分散式訓練任務可從相同區域節點組態的最低延遲中獲益。這些工作負載會將多個 Pod 部署到特定區域。這可以透過使用 為所有共同排程的 Pod 或節點親和性設定 Pod 親和性來實現`topologyKey: failure-domain.beta.kubernetes.io/zone`。然後，Cluster Autoscaler 會擴展特定區域以符合需求。您可能想要配置多個 EC2 Auto Scaling 群組，每個可用區域一個，以啟用整個共同排程工作負載的容錯移轉。 請確認以下事項： + 節點群組平衡是藉由設定 `balance-similar-node-groups=false` 啟用的。 + 當叢集同時包含區域和區域節點群組時，會使用節點[親和](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)性和/或 [Pod 先佔](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)。 + 使用[節點親和](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)性來強制或鼓勵區域 Pod 以避免區域節點群組，反之亦然。 + 如果區域 Pod 排程到區域節點群組，這會導致區域 Pod 的容量不平衡。 + 如果您的區域工作負載可以容忍中斷和重新定位，請設定 [Pod 先佔](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)以啟用區域擴展的 Pod，強制先佔和重新排程較少競爭的區域。 ### 加速器 有些叢集會利用 GPU 等專用硬體加速器。向外擴展時，加速器裝置外掛程式可能需要幾分鐘的時間來向叢集公告資源。Cluster Autoscaler 已模擬此節點將具有加速器，但直到加速器就緒並更新節點的可用資源之前，無法在節點上排程待定 Pod。這可能會導致[重複不必要的擴增](https://github.com/kubernetes/kubernetes/issues/54959)。 此外，即使加速器未使用，具有加速器和高 CPU 或記憶體使用率的節點也不會考慮縮減規模。由於加速器的相對成本，這種行為可能很昂貴。相反地，如果節點有未佔用的加速器，Cluster Autoscaler 可以套用特殊規則來考慮縮減規模的節點。 為了確保這些案例的正確行為，您可以在加速器節點上設定 kubelet，以在節點加入叢集之前標記節點。Cluster Autoscaler 將使用此標籤選擇器來觸發加速器最佳化行為。 請確認以下事項： + GPU 節點的 Kubelet 已使用 設定 `--node-labels k8s.amazonaws.com/accelerator=$ACCELERATOR_TYPE` + 具有 Accelerator 的節點遵循上述相同的排程屬性規則。 ### 從 0 擴展 Cluster Autoscaler 能夠在零之間擴展節點群組，進而大幅節省成本。它會檢查其 LaunchConfiguration 或 LaunchTemplate 中指定的 InstanceType，以偵測 Auto Scaling 群組的 CPU、記憶體和 GPU 資源。有些 Pod 需要額外的資源，例如 `WindowsENI`或 `PrivateIPv4Address`或特定的 NodeSelectors 或 Taint，這些資源無法從 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](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-are-the-parameters-to-ca) 上取得完整的參數清單。 | 參數 | 描述 | 預設 | | --- | --- | --- | | 掃描間隔 | 重新評估叢集擴展或縮減的頻率 | 10 秒 | | max-empty-bulk-delete | 可同時刪除的空節點數量上限。 | 10 | | scale-down-delay-after-add | 在縮減規模之後，縮減規模評估會繼續多久 | 10 分鐘 | | scale-down-delay-after-delete | 在縮減評估的節點刪除恢復後多久， 預設為掃描間隔 | 掃描間隔 | | scale-down-delay-after-failure | 縮減規模失敗後，縮減規模評估會繼續多久 | 3 分鐘 | | scale-down-unneeded-time | 節點在符合縮減規模的資格之前，應該不需要多長時間 | 10 分鐘 | | scale-down-unready-time | 不需要尚未就緒的節點多久，才符合縮減規模的資格 | 20 分鐘 | | scale-down-utilization-threshold | 節點使用率層級，定義為請求的資源總和除以容量，低於此值時可考慮縮減節點 | 0.5 | | scale-down-non-empty-candidates-count | 在一次反覆運算中視為候選項目的非空節點數目上限，以使用耗盡縮減規模。值越低表示 CA 回應能力越好，但縮減延遲可能越慢。較高的值可能會影響大型叢集 （數百個節點） 的 CA 效能。設定為非正值以關閉此啟發式 - CA 不會限制其考慮的節點數量。」 | 30 | | scale-down-candidates-pool-ratio | 當先前反覆運算中的某些候選項目不再有效時，被視為額外非空白候選項目的節點比例會縮減。值越低表示 CA 回應能力越好，但縮減延遲可能越慢。較高的值可能會影響大型叢集 （數百個節點） 的 CA 效能。設定為 1.0 以關閉此啟發式 - CA 會將所有節點作為其他候選項目。 | 0.1 | | scale-down-candidates-pool-min-count | 當先前反覆運算中的某些候選項目不再有效時，視為擴展的其他非空白候選項目的節點數量下限。計算其他候選項目的集區大小時 `max(#nodes * scale-down-candidates-pool-ratio, scale-down-candidates-pool-min-count)` | 50 | ## 其他資源 此頁面包含 Cluster Autoscaler 簡報和示範的清單。如果您想要在此處新增簡報或示範，請傳送提取請求。 | 簡報/示範 | 簡報者 | | --- | --- | | [Kubernetes 上的自動擴展和成本最佳化：從 0 到 100](https://sched.co/Zemi) | Guy 坦伯頓、Skyscanner 和 Jiaxin Shan、Amazon | | [SIG-Autoscaling Deep Dive](https://youtu.be/odxPyW_rZNQ) | Maciek Pytel 和 Marcin Wielgus | ## 參考 + https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md + https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md + https://github.com/aws/amazon-ec2-instance-selector + https://github.com/aws/aws-node-termination-handler