セットアップフェーズスケールアップフェーズアップグレードフェーズスケールダウンフェーズ

ノードの更新の各フェーズを理解する

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

セットアップフェーズ

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

ノードグループに関連付けられた Auto Scaling グループ用に新しい Amazon EC2 起動テンプレートバージョンを作成します。新しい起動テンプレートバージョンでは、ターゲットの AMI またはカスタム起動テンプレートバージョンを更新に使用します。
最新の起動テンプレートバージョンを使用するように、Auto Scaling グループを更新します。
ノードグループの updateConfig プロパティを使用して、並列でアップグレードするノードの最大数を決定します。使用不可の最大値には、クォータとして 100 ノードがあります。デフォルト値は 1 ノードです。詳細については、Amazon EKS API リファレンス 内の updateConfig プロパティを参照してください。

スケールアップフェーズ

マネージド型ノードグループ内のノードをアップグレードするとき、アップグレードされたノードは、アップグレードされているノードと同じアベイラビリティーゾーンで起動されます。この配置を保証するために、Amazon EC2 のアベイラビリティーゾーンの再調整を使用します。詳細については、Amazon EC2 Auto Scaling ユーザーガイドのアベイラビリティーゾーンの再調整を参照してください。この要件を満たすために、マネージド型ノードグループのアベイラビリティーゾーンごとに最大 2 つのインスタンスを起動できます。

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

Auto Scaling グループの最大サイズと希望のサイズを、次のうちいずれか大きい方だけ増加させます。
- Auto Scaling グループがデプロイされているアベイラビリティーゾーン数の最大 2 倍。
- アップグレードができない最大値。
  
  たとえば、ノードグループのアベイラビリティーゾーンが 5 つで、maxUnavailable が 1 である場合、アップグレードプロセスで最大 10 個のノードを起動できます。しかし、maxUnavailable が 20 (または 10 より大きいいずれかの値) である場合、プロセスにより起動される新しいノードは 20 個です。
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
    
    注記
    スケーリング設定を変更せずに更新またはアップグレードが開始されると、ワークフローはノードグループの保存されたスケーリング設定ではなく、ライブAuto Scaling グループの値を開始点として使用します。詳細については、マネージド型ノードグループの概念を参照してください。
新しい Pod がスケジュールされないように、ノードをスケジュール不可としてマークします。古いノードを終了する前にロードバランサーからノードを削除するため、ノードに node.kubernetes.io/exclude-from-external-load-balancers=true のラベルを付けます。

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

アベイラビリティーゾーンの容量が不十分です: アベイラビリティーゾーンに、リクエストされたインスタンスタイプの容量がない可能性があります。マネージド型ノードグループを作成するときは、複数のインスタンスタイプを設定することをお勧めします。
アカウント内の EC2 インスタンス制限: Service Quotas を使用してアカウントが同時に実行できる Amazon EC2 インスタンスの数を増やす必要がある場合があります。詳細については、Linux インスタンス向け Amazon Elastic Compute Cloud ユーザーガイドの EC2 の Service Quotas を参照してください。
カスタムユーザーデータ: カスタムユーザーデータは、ブートストラッププロセスを中断することがあります。このシナリオでは、ノードで kubelet が起動しないか、ノードで想定される Amazon EKS ラベルが取得されない可能性があります。詳細については、AMI を指定するを参照してください。
ノードを異常な状態または準備ができていない状態にする変更: ノードのディスク負荷、メモリ負荷、および同様の条件により、ノードが Ready 状態にならない可能性があります。
各ノードのブートストラップにかかる時間は通常 15 分以内: ブートストラップしてクラスターに加わるまでに 15 分以上かかるノードがあると、アップグレードがタイムアウトします。この時間は、新しいノードが必要になってからクラスターに加わるまで、新しいノードのブートストラップに要した合計時間です。マネージドノードグループをアップグレードする場合は、Auto Scaling グループのサイズが大きくなると、すぐに時間の測定が始まります。

アップグレードフェーズ

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

通常は、デフォルト戦略をお勧めします。古いノードを終了する前に新しいノードを作成するという戦略で、アップグレードフェーズ中も使用可能な容量が維持されます。最小は、リソースやコスト (例えば、GPU などのハードウェアアクセラレーター) が限られている場合に便利な戦略です。新しいノードを作成する前に古いノードを終了するため、合計容量が設定しておいた数量を超えることはありません。

デフォルト更新戦略のステップは次のとおりです。

Auto Scaling グループ内のノード数を (必要な数だけ) 増やして、ノードグループに追加でノードを作成します。
ノードグループのために設定されている使用不可の最大数を上限として、アップグレードが必要なノードをランダムに選択します。
ノードから Pod をドレインします。Pod が 15 分以内にノードを離れず、強制フラグがない場合は、PodEvictionFailure というエラーが表示されて、アップグレードフェーズは失敗します。この状況になった場合、update-nodegroup-version リクエストで強制フラグを適用して Pod を削除できます。
すべての Pod が削除されたらノードを遮断し、60 秒間待機します。これは、サービスコントローラーがこのノードに新しくリクエストを送信しないようにするためと、アクティブなノードのリストからこのノードを削除するために行われます。
遮断されたノードのAuto Scaling グループに終了リクエストを送信します。
以前のバージョンの起動テンプレートでデプロイされたノードグループ内にノードが存在しなくなるまで、以前のアップグレード手順を繰り返します。

最小更新戦略のステップは次のとおりです。

ノードグループのすべてのノードを最初に遮断して、サービスコントローラーがこれらのノードに新しいリクエストを送信しないようにします。
ノードグループのために設定されている使用不可の最大数を上限として、アップグレードが必要なノードをランダムに選択します。
選択したノードからポッドをドレインします。Pod が 15 分以内にノードを離れず、強制フラグがない場合は、PodEvictionFailure というエラーが表示されて、アップグレードフェーズは失敗します。この状況になった場合、update-nodegroup-version リクエストで強制フラグを適用して Pod を削除できます。
すべてのポッドを削除し 60 秒間待機すると、終了リクエストが、選択したノードのAuto Scaling グループに送信されます。Auto Scaling グループは、不足分の容量を補うために (選択したノードと同数の) 新しいノードを作成します。
以前のバージョンの起動テンプレートでデプロイされたノードグループ内にノードが存在しなくなるまで、以前のアップグレード手順を繰り返します。

アップグレードフェーズ中の `PodEvictionFailure` エラー

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

アグレッシブ PDB: Pod にアグレッシブ PDB が定義されているか、同じ Pod を指す複数の PDB が存在します。
すべてのテイントを許容するデプロイ: すべての Pod が削除されたら、前のステップでノードがテイントされているため、ノードは空になるはずです。ただし、デプロイがすべてのテイントを許容する場合、ノードが空でない可能性が高くなり、Pod のエビクションが失敗します。

スケールダウンフェーズ

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

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

注記


If your node group has a warm pool enabled, warm pool instances are drained before the scale-up operation begins. This is because warm pool instances have not been updated to the new launch template configuration — during the scale-up phase, they would be pulled into the Auto Scaling Group instead of launching new instances with the updated configuration, which would break the upgrade process. Draining the warm pool ensures that only new instances with the updated configuration are launched. Once the scale-down operation completes, the warm pool is restored, and the new instances in the warm pool are launched with the updated launch template configuration.

ウォームプールの詳細については、「マネージド型ノードグループを備えたウォームプールを使用して、起動時間の長いアプリケーションのレイテンシーを低減する」を参照してください。