協助改善此頁面
本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
想要為此使用者指南做出貢獻? 捲動至此頁面底部,然後選取編輯此頁面 GitHub。您的貢獻將幫助我們的使用者指南更適合每個人。
本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Amazon EKS受管工作者節點升級策略有四個不同的階段,如以下各節所述。
設定階段
設定階段具有下列步驟:
-
它為與您的節點群組相關聯的 Auto Scaling 群組建立新的 Amazon EC2啟動範本版本。新的啟動範本版本會使用目標AMI或自訂啟動範本版本進行更新。
-
它會更新 Auto Scaling 群組,以使用最新的啟動範本。
-
它使用節點群組的
updateConfig
屬性決定要平行升級的節點數量上限。不可用節點上限配額為 100。預設值為一個節點。如需詳細資訊,請參閱 Amazon EKSAPI參考中的 updateConfig 屬性。
擴充規模階段
升級受管節點群組中的節點時,已升級的節點會在與正在升級的節點相同的可用區域中啟動。為了保證此置放,我們使用 Amazon EC2的可用區域重新平衡。如需詳細資訊,請參閱《Amazon EC2 Auto Scaling 使用者指南》中的可用區域重新平衡。為了滿足此要求,我們最多可能會啟動受管節點群組中每個可用區域的兩個執行個體。
擴充規模階段具有下列步驟:
-
它會將 Auto Scaling 群組的大小上限和所需大小增加下列其中之一的較大者:
-
Auto Scaling 群組部署的可用區域數量的兩倍。
-
升級無法使用的上限。
例如,如果節點群組有五個可用區域,而
maxUnavailable
為一個,則升級程序最多能啟動 10 個節點。不過,當maxUnavailable
為 20 (或任何高於 10 的節點) 時,程序會啟動 20 個新節點。
-
-
擴展 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
-
-
它將節點標記為無法排程,以避免排程新的 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
狀態。
升級階段
升級階段具有下列步驟:
-
它隨機選取需要升級的節點,最大不超過為節點群組設定的無法使用上限。
-
它會耗盡 Pods 從節點。如果 Pods 請勿在 15 分鐘內離開節點,而且沒有強制旗標,升級階段會失敗並發生錯誤
PodEvictionFailure
。在此案例中,您可以將強制旗標與update-nodegroup-version
刪除 Pods. -
它會在每個 之後封鎖節點 Pod 被移出並等待 60 秒。這樣做是為了讓服務控制器不會傳送任何新請求到此節點,並從其作用中節點清單中移除此節點。
-
它將終止請求傳送之包圍隔離節點的 Auto Scaling 群組。
-
它重複步驟先前的升級步驟,直到節點群組中沒有使用舊版啟動範本部署的節點為止。
以下是在這個階段中會導致 PodEvictionFailure
錯誤的已知原因:
- 積極性 PDB
-
積極性PDB定義於 Pod 或者有多個PDBs指向相同的 Pod.
- 部署可容忍所有污點
-
每 1 次 Pod 被移出,預期節點為空,因為節點在先前步驟中被污漬
。不過,如果部署可容忍每個污點,則節點更有可能是非空的,導致 Pod 移出失敗。
縮減規模階段
縮減規模階段會將 Auto Scaling 群組的大小上限和所需大小遞減一,以便回到更新開始之前的值。
如果升級工作流程判斷 Cluster Autoscaler 在工作流程的縮減規模階段期間擴充節點群組,它會立即結束,而不會將節點群組恢復至原始大小。