**協助改進此頁面** 

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

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。

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

# 了解節點更新的每個階段
<a name="managed-node-update-behavior"></a>

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

## 設定階段
<a name="managed-node-update-set-up"></a>

設定階段具有下列步驟：

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

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

1. 它使用節點群組的 `updateConfig` 屬性決定要平行升級的節點數量上限。不可用節點上限配額為 100。預設值為一個節點。如需詳細資訊，請參閱《*Amazon EKS API 參考*》中的 [updateConfig](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateNodegroupConfig.html#API_UpdateNodegroupConfig_RequestSyntax) 屬性。

## 擴充規模階段
<a name="managed-node-update-scale-up"></a>

升級受管節點群組中的節點時，已升級的節點會在與正在升級的節點相同的可用區域中啟動。為了保證這種置放，我們使用 Amazon EC2 的可用區域重新平衡。如需詳細資訊，請參閱《[Amazon EC2 Auto Scaling 使用者指南](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage)》中的*可用區域容量重新平衡*。為了滿足這項需求，我們可在受管節點群組中每個可用區域啟動最多兩個執行個體。

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

1. 它按下面的任一大小 (以較大者為准) 增加 Auto Scaling 群組的最大大小和所需大小：
   + Auto Scaling 群組部署的可用區域數量的兩倍。
   + 升級無法使用的上限。

     例如，如果節點群組有五個可用區域，而 `maxUnavailable` 為一個，則升級程序最多能啟動 10 個節點。但是，當 `maxUnavailable` 為 20 (或任何大於 10 的數字)，該程序會啟動 20 個新節點。

1. 擴展 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` 

1. 它將節點標記為不可排程，以避免排程新的 Pod。它還使用 `node.kubernetes.io/exclude-from-external-load-balancers=true` 標記節點，以便在終止節點之前從負載平衡器中移除舊節點。

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

 **可用區域容量不足**   
可用區域可能沒有所請求執行個體類型的容量。建議在建立受管節點群組時設定多個執行個體類型。

 **您帳戶中的 EC2 執行個體限制**   
您可能需要增加帳戶可以使用 Service Quotas 同時執行的 Amazon EC2 執行個體的數量。如需詳細資訊，請參閱《[Amazon Elastic Compute Cloud Linux 執行個體使用者指南](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)》中的 *EC2 Service Quotas*。

 **自訂使用者資料**   
自訂使用者資料有時會中斷引導程序。這種情況可能會導致 `kubelet` 未在節點上啟動或節點上未取得預期的 Amazon EKS 標籤。如需詳細資訊，請參閱 [指定 AMI](launch-templates.md#launch-template-custom-ami)。

 **任何使節點運作狀態不良或未準備就緒的變更**   
節點磁碟壓力、記憶體壓力和類似情況，可能導致節點無法進入 `Ready` 狀態。

 **每個節點在 15 分鐘內必須完成引導**   
如果任何節點需要超過 15 分鐘才能完成引導並加入叢集，則會導致升級逾時。這是從需要新節點到新階段加入叢集時，測量的引導新節點的總執行時期。升級受管節點群組時，時間計數器會在 Auto Scaling 群組大小增加時立即啟動。

## 升級階段
<a name="managed-node-update-upgrade"></a>

升級階段有有兩種不同的行為方式，具體視*更新策略*而定。更新策略有兩種：**預設**和**最低**。

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

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

1. 它會增加 Auto Scaling 群組中的節點數量 (所需計數)，進而導致節點群組建立額外的節點。

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

1. 其會耗盡節點中的 Pod。如果 Pod 沒有在 15 分鐘內離開節點，並且沒有強制旗標，則升級階段將失敗，並會出現 `PodEvictionFailure` 錯誤。在這種情況下，您可以應用強制旗標，同時使用 `update-nodegroup-version` 請求刪除 Pod。

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

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

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

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

1. 它會在開頭包圍隔離節點群組的所有節點，以便服務控制器不會將任何新請求傳送至這些節點。

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

1. 它會從選取的節點中耗盡 Pod。如果 Pod 沒有在 15 分鐘內離開節點，並且沒有強制旗標，則升級階段將失敗，並會出現 `PodEvictionFailure` 錯誤。在這種情況下，您可以應用強制旗標，同時使用 `update-nodegroup-version` 請求刪除 Pod。

1. 在每個 Pod 被移出並等待 60 秒後，其會向選取的節點的 Auto Scaling 群組傳送終止請求。Auto Scaling 群組會建立新的節點 (與選取的節點的數量相同)，以取代缺少的容量。

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

### 升級階段期間的 `PodEvictionFailure` 錯誤
<a name="_podevictionfailure_errors_during_the_upgrade_phase"></a>

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

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

 **容忍所有污點的部署**   
一旦移出每個 Pod，節點預期為空，因為節點在先前的步驟中會受到[污染](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)。但是，如果部署容忍每一個污點，則節點更有可能是非空白，導致 Pod 移出失敗。

## 縮減規模階段
<a name="managed-node-update-scale-down"></a>

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

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