瞭解節點更新的每個階段 - 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

      以下是 Amazon 在自訂啟動範本或節點群組中的工作者AMI節點上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 增加帳戶可同時EC2執行的 Amazon 執行個體數量。如需詳細資訊，請參閱 Amazon 彈性運算雲端Linux執行個體使用者指南中的 Ser EC2vice 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

侵略性PDB是在Pod或有多個PDBs指向相同的定義Pod。

容忍所有污點的部署

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

縮減規模階段

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

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