了解節點更新的每個階段 - Amazon EKS
設定階段擴充規模階段升級階段縮減規模階段

協助改進此頁面

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的在 GitHub 上編輯此頁面連結。

了解節點更新的每個階段

Amazon EKS 受管工作節點升級策略有四個不同的階段，如下節所述。

設定階段

設定階段具有下列步驟：

  1. 它為與節點群組相關聯的 Auto Scaling 群組建立新的 Amazon EC2 啟動範本版本。新的啟動範本版本使用目標 AMI 或自訂啟動範本版本進行更新。

  2. 它會更新 Auto Scaling 群組，以使用最新的啟動範本。

  3. 它使用節點群組的 updateConfig 屬性決定要平行升級的節點數量上限。不可用節點上限配額為 100。預設值為一個節點。如需詳細資訊，請參閱《Amazon EKS API 參考》中的 updateConfig 屬性。

擴充規模階段

升級受管節點群組中的節點時，已升級的節點會在與正在升級的節點相同的可用區域中啟動。為了保證這種置放，我們使用 Amazon EC2 的可用區域重新平衡。如需詳細資訊，請參閱《Amazon EC2 Auto Scaling 使用者指南》中的可用區域容量重新平衡。為了滿足這項需求，我們可在受管節點群組中每個可用區域啟動最多兩個執行個體。

擴充規模階段具有下列步驟：

  1. 它按下面的任一大小 (以較大者為准) 增加 Auto Scaling 群組的最大大小和所需大小：

    • Auto Scaling 群組部署的可用區域數量的兩倍。

    • 升級無法使用的上限。

      例如，如果節點群組有五個可用區域，而 maxUnavailable 為一個，則升級程序最多能啟動 10 個節點。但是，當 maxUnavailable 為 20 (或任何大於 10 的數字)，該程序會啟動 20 個新節點。

  2. 擴展 Auto Scaling 群組後，會檢查使用最新配置的節點是否存在於節點群組之中。只有在符合下列條件時，此步驟才會成功：

    • 在節點所在的每個可用區域中，至少會啟動一個新節點。

    • 每個新節點都應該處於 Ready 狀態。

    • 新節點應該有 Amazon EKS 套用標籤。

      以下是一般節點群組中工作節點上的 Amazon EKS 套用標籤：

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      以下是自訂啟動範本或 AMI 節點群組中工作節點上的 Amazon EKS 套用標籤：

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      • eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId

      • eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion

  3. 它將節點標記為不可排程，以避免排程新的 Pod。它還使用 node.kubernetes.io/exclude-from-external-load-balancers=true 標記節點，以便在終止節點之前從負載平衡器中移除舊節點。

以下是在這個階段中會導致 NodeCreationFailure 錯誤的已知原因：

可用區域容量不足

可用區域可能沒有所請求執行個體類型的容量。建議在建立受管節點群組時設定多個執行個體類型。

您帳戶中的 EC2 執行個體限制

您可能需要增加帳戶可以使用 Service Quotas 同時執行的 Amazon EC2 執行個體的數量。如需詳細資訊，請參閱《Amazon Elastic Compute Cloud Linux 執行個體使用者指南》中的 EC2 Service Quotas。

自訂使用者資料

自訂使用者資料有時會中斷引導程序。這種情況可能會導致 kubelet 未在節點上啟動或節點上未取得預期的 Amazon EKS 標籤。如需詳細資訊，請參閱 指定 AMI。

任何使節點運作狀態不良或未準備就緒的變更

節點磁碟壓力、記憶體壓力和類似情況，可能導致節點無法進入 Ready 狀態。

每個節點在 15 分鐘內必須完成引導

如果任何節點需要超過 15 分鐘才能完成引導並加入叢集，則會導致升級逾時。這是從需要新節點到新階段加入叢集時，測量的引導新節點的總執行時期。升級受管節點群組時，時間計數器會在 Auto Scaling 群組大小增加時立即啟動。

升級階段

升級階段有有兩種不同的行為方式，具體視更新策略而定。更新策略有兩種：預設和最低。

大多數情況下，我們建議使用預設策略。它會在終止舊節點之前建立新節點，以便在升級階段維持可用容量。在資源或成本受限制的情況下 (例如使用 GPU 等硬體加速器)，這種最低策略非常有用。它會在建立新節點之前終止舊節點，以便總容量永遠不會超過您設定的數量。

預設更新策略包含下列步驟：

  1. 它會增加 Auto Scaling 群組中的節點數量 (所需計數)，進而導致節點群組建立額外的節點。

  2. 它隨機選取需要升級的節點，最大不超過為節點群組設定的無法使用上限。

  3. 其會耗盡節點中的 Pod。如果 Pod 沒有在 15 分鐘內離開節點，並且沒有強制旗標，則升級階段將失敗，並會出現 PodEvictionFailure 錯誤。在這種情況下，您可以應用強制旗標，同時使用 update-nodegroup-version 請求刪除 Pod。

  4. 在每個 Pod 被移出並等待 60 秒後，其會包圍隔離節點。這樣做是為了讓服務控制器不會將任何新的請求傳送到此節點，並將此節點從其作用中的節點清單中移除。

  5. 它將終止請求傳送之包圍隔離節點的 Auto Scaling 群組。

  6. 它重複步驟先前的升級步驟，直到節點群組中沒有使用舊版啟動範本部署的節點為止。

最低更新策略包含下列步驟：

  1. 它會在開頭包圍隔離節點群組的所有節點，以便服務控制器不會將任何新請求傳送至這些節點。

  2. 它隨機選取需要升級的節點，最大不超過為節點群組設定的無法使用上限。

  3. 它會從選取的節點中耗盡 Pod。如果 Pod 沒有在 15 分鐘內離開節點，並且沒有強制旗標，則升級階段將失敗，並會出現 PodEvictionFailure 錯誤。在這種情況下，您可以應用強制旗標，同時使用 update-nodegroup-version 請求刪除 Pod。

  4. 在每個 Pod 被移出並等待 60 秒後，其會向選取的節點的 Auto Scaling 群組傳送終止請求。Auto Scaling 群組會建立新的節點 (與選取的節點的數量相同)，以取代缺少的容量。

  5. 它重複步驟先前的升級步驟，直到節點群組中沒有使用舊版啟動範本部署的節點為止。

升級階段期間的 PodEvictionFailure 錯誤

以下是在這個階段中會導致 PodEvictionFailure 錯誤的已知原因：

積極的 PDB

在 Pod 上定義積極的 PDB，或有多個 PDB 指向同一個 Pod。

容忍所有污點的部署

一旦移出每個 Pod，節點預期為空，因為節點在先前的步驟中會受到污染。但是，如果部署容忍每一個污點，則節點更有可能是非空白，導致 Pod 移出失敗。

縮減規模階段

縮減規模階段會將 Auto Scaling 群組的大小上限和所需大小遞減一，以便回到更新開始之前的值。

如果升級工作流程判斷 Cluster Autoscaler 在工作流程的縮減規模階段期間擴充節點群組，它會立即結束，而不會將節點群組恢復至原始大小。