選取您的 Cookie 偏好設定

我們使用提供自身網站和服務所需的基本 Cookie 和類似工具。我們使用效能 Cookie 收集匿名統計資料,以便了解客戶如何使用我們的網站並進行改進。基本 Cookie 無法停用,但可以按一下「自訂」或「拒絕」以拒絕效能 Cookie。

如果您同意,AWS 與經核准的第三方也會使用 Cookie 提供實用的網站功能、記住您的偏好設定,並顯示相關內容,包括相關廣告。若要接受或拒絕所有非必要 Cookie,請按一下「接受」或「拒絕」。若要進行更詳細的選擇,請按一下「自訂」。

了解節點更新的每個階段

焦點模式
了解節點更新的每個階段 - Amazon EKS

協助改善此頁面

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

想要為此使用者指南做出貢獻? 捲動至此頁面底部,然後選取編輯此頁面 GitHub。您的貢獻將幫助我們的使用者指南更適合每個人。

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

協助改善此頁面

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

想要為此使用者指南做出貢獻? 捲動至此頁面底部,然後選取編輯此頁面 GitHub。您的貢獻將幫助我們的使用者指南更適合每個人。

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

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

設定階段

設定階段具有下列步驟:

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

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

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

擴充規模階段

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

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

  1. 它會將 Auto Scaling 群組的大小上限和所需大小增加下列其中之一的較大者:

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

    • 升級無法使用的上限。

      例如,如果節點群組有五個可用區域,而 maxUnavailable 為一個,則升級程序最多能啟動 10 個節點。不過,當 maxUnavailable為 20 (或任何高於 10 的節點) 時,程序會啟動 20 個新節點。

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

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

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

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

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

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

      • eks.amazonaws.com/nodegroup=$nodeGroupName

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

    +

    • 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 使用者指南》中的EC2Service Quotas。Linux 執行個體

自訂使用者資料

自訂使用者資料有時會中斷引導程序。此案例可能導致 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.

部署可容忍所有污點

每 1 次 Pod 被移出,預期節點為空,因為節點在先前步驟中被污漬。不過,如果部署可容忍每個污點,則節點更有可能是非空的,導致 Pod 移出失敗。

縮減規模階段

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

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

📝 在 上編輯此頁面 GitHub

下一個主題:

啟動範本

上一個主題:

更新
隱私權網站條款Cookie 偏好設定
© 2025, Amazon Web Services, Inc.或其附屬公司。保留所有權利。