受管節點更新行為

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. 它將節點標記為不可排程，以避免排程新的 Pods。它還使用 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 狀態。

升級階段

升級階段具有下列步驟：

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

2. 它耗盡節點中的 Pods。若 Pods 未在 15 分鐘內離開節點且未強制標記，則升級階段將失敗，並出現 PodEvictionFailure 錯誤。在這種情況下，您可以應用強制標記，同時使用 update-nodegroup-version 請求刪除 Pods。

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

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

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

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

積極的 PDB

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

容忍所有污點的部署

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

縮減規模階段

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

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