ノードの更新の各フェーズを理解する - Amazon EKS
セットアップフェーズスケールアップフェーズアップグレードフェーズスケールダウンフェーズ

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

本ユーザーガイドの改善にご協力いただけませんか? このページの下部までスクロールし、[GitHub でこのページの編集] を選択します。皆さまにご協力いただくことで、あらゆる人々に使いやすいユーザーガイドになります。

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

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

セットアップフェーズ

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

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

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

  3. ノードグループの updateConfig プロパティを使用して、並列でアップグレードするノードの最大数を決定します。使用不可の最大値には、クォータとして 100 ノードがあります。デフォルト値は 1 ノードです。詳細については、Amazon EKS API リファレンス内の updateConfig プロパティを参照してください。

スケールアップフェーズ

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

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

  1. Auto Scaling グループの最大サイズと希望のサイズを、次のうちいずれか大きい方だけ増加させます。

    • Auto Scaling グループがデプロイされているアベイラビリティーゾーン数の最大 2 倍。

    • アップグレードができない最大値。

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

  2. 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

  3. 新しい Pods のスケジュールを回避するために、ノードをスケジュール不可としてマークします。また、ノードを終了する前にロードバランサーからノードを削除するために、ノードに 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 状態にならない可能性があります。

アップグレードフェーズ

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

  1. ノードグループのために設定されている使用不可の最大数を上限として、アップグレードが必要なノードをランダムに選択します。

  2. ノードから Pods をドレインします。Pods が 15 分以内にノードを離れず、強制フラグがない場合、PodEvictionFailure というエラーが表示され、アップグレードフェーズは失敗します。このシナリオでは、update-nodegroup-version リクエストで強制フラグを適用して、Pods を削除できます。

  3. すべての Pod が削除された後にノードを遮断し、60 秒間待ちます。これは、サービスコントローラーがこのノードに新しくリクエストを送信しないようにするためと、アクティブなノードのリストからこのノードを削除するために行われます。

  4. 遮断されたノードの Auto Scaling グループに終了リクエストを送信します。

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

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

アグレッシブ PDB

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

すべてのテイントを許容するデプロイ

すべての Pod が削除されると、前のステップでノードがテイントされているため、ノードは空になると予想されます。ただし、デプロイがすべての汚染を許容する場合、ノードは空ではない可能性が高く、Pod エビクションの失敗につながります。

スケールダウンフェーズ

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

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