**このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# ノードの更新の各フェーズを理解する
<a name="managed-node-update-behavior"></a>

Amazon EKS マネージド型ワーカーノードのアップグレード戦略には、次のセクションで説明する 4 つの異なるフェーズがあります。

## セットアップフェーズ
<a name="managed-node-update-set-up"></a>

セットアップフェーズには、次の手順があります。

1. ノードグループに関連付けられた Auto Scaling グループ用に新しい Amazon EC2 起動テンプレートバージョンを作成します。新しい起動テンプレートバージョンでは、ターゲットの AMI またはカスタム起動テンプレートバージョンを更新に使用します。

1. 最新の起動テンプレートバージョンを使用するように、Auto Scaling グループを更新します。

1. ノードグループの `updateConfig` プロパティを使用して、並列でアップグレードするノードの最大数を決定します。使用不可の最大値には、クォータとして 100 ノードがあります。デフォルト値は 1 ノードです。詳細については、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)の*アベイラビリティーゾーンの再調整*を参照してください。この要件を満たすために、マネージド型ノードグループのアベイラビリティーゾーンごとに最大 2 つのインスタンスを起動できます。

スケールアップフェーズには、次の手順があります。

1. Auto Scaling グループの最大サイズと希望のサイズを、次のうちいずれか大きい方だけ増加させます。
   + Auto Scaling グループがデプロイされているアベイラビリティーゾーン数の最大 2 倍。
   + アップグレードができない最大値。

     たとえば、ノードグループのアベイラビリティーゾーンが 5 つで、`maxUnavailable` が 1 である場合、アップグレードプロセスで最大 10 個のノードを起動できます。しかし、`maxUnavailable` が 20 (または 10 より大きいいずれかの値) である場合、プロセスにより起動される新しいノードは 20 個です。

1. Auto Scaling グループのスケーリング後、最新の設定を使用するノードがノードグループに存在するかどうかをチェックします。この手順は、次の基準を満たす場合にのみ成功します。
   + ノードが存在するすべてのアベイラビリティーゾーンで、少なくとも 1 つの新しいノードが起動されます。
   + 新しいノードはすべて、`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 インスタンスの数を増やす必要がある場合があります。詳細については、*Linux インスタンス向け Amazon Elastic Compute Cloud ユーザーガイド*の [EC2 の Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) を参照してください。

 **カスタムユーザーデータ**   
カスタムユーザーデータは、ブートストラッププロセスを中断することがあります。このシナリオでは、ノードで `kubelet` が起動しないか、ノードで想定される Amazon EKS ラベルが取得されない可能性があります。詳細については、「[AMI を指定する](launch-templates.md#launch-template-custom-ami)」を参照してください。

 **ノードを異常な状態または準備ができていない状態にする変更**   
ノードのディスク負荷、メモリ負荷、および同様の条件により、ノードが `Ready` 状態にならない可能性があります。

 **各ノードのブートストラップにかかる時間は通常 15 分以内**   
ブートストラップしてクラスターに加わるまでに 15 分以上かかるノードがあると、アップグレードがタイムアウトします。この時間は、新しいノードが必要になってからクラスターに加わるまで、新しいノードのブートストラップに要した合計時間です。マネージドノードグループをアップグレードする場合は、Auto Scaling グループのサイズが大きくなると、すぐに時間の測定が始まります。

## アップグレードフェーズ
<a name="managed-node-update-upgrade"></a>

アップグレードフェーズの動作には 2 通りの方法があり、*更新戦略*によって異なります。**デフォルト**と**最小**という 2 つの更新戦略があります。

通常は、デフォルト戦略をお勧めします。古いノードを終了する前に新しいノードを作成するという戦略で、アップグレードフェーズ中も使用可能な容量が維持されます。最小は、リソースやコスト (例えば、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 が 15 分以内にノードを離れず、強制フラグがない場合は、`PodEvictionFailure` というエラーが表示されて、アップグレードフェーズは失敗します。この状況になった場合、`update-nodegroup-version` リクエストで強制フラグを適用して Pod を削除できます。

1. すべてのポッドを削除し 60 秒間待機すると、終了リクエストが、選択したノードの Auto Scaling グループに送信されます。Auto Scaling グループは、不足分の容量を補うために (選択したノードと同数の) 新しいノードを作成します。

1. 以前のバージョンの起動テンプレートでデプロイされたノードグループ内にノードが存在しなくなるまで、以前のアップグレード手順を繰り返します。

### アップグレードフェーズ中の `PodEvictionFailure` エラー
<a name="_podevictionfailure_errors_during_the_upgrade_phase"></a>

このフェーズで `PodEvictionFailure` エラーが発生する既知の原因を次に示します。

 **アグレッシブ PDB**   
Pod にアグレッシブ PDB が定義されているか、同じ Pod を指す複数の PDB が存在します。

 **すべてのテイントを許容するデプロイ**   
すべての Pod が削除されたら、前のステップでノードが[テイント](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)されているため、ノードは空になるはずです。ただし、デプロイがすべてのテイントを許容する場合、ノードが空でない可能性が高くなり、Pod のエビクションが失敗します。

## スケールダウンフェーズ
<a name="managed-node-update-scale-down"></a>

スケールダウンフェーズでは、Auto Scaling グループの最大サイズと希望するサイズが 1 ずつ減り、更新が開始される前の値に戻ります。

ワークフローのスケールダウンフェーズ中に Cluster Autoscaler がノードグループをスケールアップしているとアップグレードワークフローが判断した場合、ノードグループを元のサイズに戻すことなく、すぐに終了します。