了解節點更新的每個階段

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 群組大小增加時立即啟動。

升級階段

升級階段的行為有兩種不同方式，取決於更新策略。更新策略有兩種：預設和最小。

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

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

1. 它會增加 Auto Scaling 群組中的節點數量 （所需計數），導致節點群組建立其他節點。

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

3. 它會從節點耗盡 Pod。如果 Pod 未在 15 分鐘內離開節點，而且沒有強制旗標，升級階段會失敗並顯示PodEvictionFailure錯誤。在此案例中，您可以將強制旗標與刪除 Pod 的update-nodegroup-version請求套用。

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

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

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

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

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

2. 它會從節點耗盡 Pod。如果 Pod 未在 15 分鐘內離開節點，而且沒有強制旗標，升級階段會失敗並顯示PodEvictionFailure錯誤。在此案例中，您可以將強制旗標與刪除 Pod 的update-nodegroup-version請求套用。

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

4. 它將終止請求傳送之包圍隔離節點的 Auto Scaling 群組。Auto Scaling 群組會建立新的節點以取代缺少的容量。

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

PodEvictionFailure 升級階段期間的錯誤

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

積極 PDB

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

部署可容忍所有污點

一旦每個 Pod 被移出，節點預期會是空的，因為節點在先前步驟中被污點。不過，如果部署可容忍每個污點，則節點可能不是空的，導致 Pod 移出失敗。

縮減規模階段

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

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