Amazon EKS ノードグループの更新の失敗に関する一般的な問題をトラブルシューティングする方法を教えてください。

所要時間2分
0

Amazon Elastic Kubernetes Service (Amazon EKS) ノードグループを最新の Amazon マシンイメージ (AMI) バージョンを使用して更新したいと考えています。

簡単な説明

マネージドノードグループの更新を開始すると、Amazon EKS はノードを自動的に更新します。Amazon EKS に最適化された AMI を使用する場合、Amazon EKS は最新のセキュリティパッチとオペレーティングシステムの更新をノードに自動的に適用します。

この更新プロセス中に、次のエラーのいずれかが表示される場合があります。発生したエラーに関連するトラブルシューティングの手順に従ってください。更新エラーの詳細については、「マネージド型ノードの更新動作」を参照してください。

解決策

PODevictionFailer のためアップデートが失敗しました

次のエラーは、アップグレードが PODevictionFailure によってブロックされていることを示します。

「Error Message : Reached max retries while trying to evict pods from nodes in node group.」

ポッドが 15 分以内にノードを離れず、強制フラグがない場合、アップグレードフェーズは PodEvictionFailure エラーで失敗します。

PODevictionFailure エラーは、次のいずれかの理由で発生する可能性があります。

アグレッシブ PDB (ポッドの停止状態の予算)

アグレッシブ PDB は、同じポッドをポイントする PDB が複数ある場合にポッド上で定義されます。

PDBは、あるポッドのクラスについて、特定の時間に許容できる停止状態の数 (障害の予算) を示します。自発的な停止状態によってサービスのポッドが予算を下回ると、予算を維持できるまでオペレーションが一時停止します。ノードドレインイベントは、ポッドがエビクションされたことによって予算が超過しないように、より多くのポッドが使用可能になるまで一時的に停止します。詳細については、Kubernetes ウェブサイトの「Disruption」(停止状態) を参照してください。

マネージドノードグループの更新がスムーズに行われることを確認するには、ポッドの停止状態の予算を一時的に削除するか、強制オプションを使用して更新する必要があります。このオプションでは、ポッドの停止状態の予算は考慮されません。代わりに、このオプションはノードを強制的に再起動させることで更新を実装します。

**注:**アプリが Quorum ベースのアプリケーションの場合、強制オプションを使用するとアプリケーションが一時的に利用できなくなる可能性があります。

次のコマンドを実行して、クラスターで PDB が設定されていることを確認します。

$ kubectl get pdb --all-namespaces

または、Amazon EKS コンソールで監査ログ記録をオンにした場合は、次のステップに従います。

  1. [Clusters] (クラスター) タブで、目的のクラスター (例: rpam-eks-qa2-control-plane) をリストから選択します。

  2. [Logging} (ログ記録) タブで、[Audit] (監査 )を選択します。これにより、Amazon CloudWatch コンソールにリダイレクトされます。

  3. CloudWatch コンソールで、[ログ] を選択します。次に、[Log Insights] を選択し、次のクエリを実行します。

    fields @timestamp, @message| filter @logStream like "kube-apiserver-audit"
    | filter ispresent(requestURI)
    | filter objectRef.subresource = "eviction"
    | display @logStream, requestURI, responseObject.message
    | stats count(*) as retry by requestURI, responseObject.message
  4. [カスタム] を選択して、更新の日付を指定します。アグレッシブ PDB が原因でノードグループの更新に失敗した場合は、resposeObject.message にポッドのエビクションが失敗した理由が記述されます。

  5. PDB が原因で失敗した場合は、次のコマンドを使用して PDB を変更します。その後、ノードグループを再度アップグレードします。

    $ kubectl edit pdb pdb_name;

あらゆるテイントを許容するデプロイ

ポッドがエビクションされるたびに、ノードは前のステップでテイントされるため、ノードは空になります。ただし、デプロイであらゆるテイントが許容される場合は、ノードが空でない可能性が高くなり、ポッドのエビクションが失敗する可能性があります。詳細については、Kubernetes ウェブサイトの「Taints and tolerations」を参照してください。

リリースバージョンが無効であるため、更新に失敗しました

リリースバージョンが有効でない場合、次のエラーが表示されることがあります。

「Error Message: Requested release version 1.xx is not valid for kubernetes version 1.xx.」

この問題を解決するには、アップグレードコマンドをもう一度実行します。このコマンドは、ノードグループをコントロールプレーンの Kubernetes バージョンと同じバージョンにアップグレードします。

eksctl upgrade nodegroup --name=test --cluster=test --kubernetes-version=1.xx

**注:**1.xx バージョンを Amazon EKS コントロールプレーンでサポートされているバージョンに置き換えてください。

ノードグループの正常性に問題があるため、更新に失敗しました

ノードグループの正常性に問題がある場合、更新に失敗すると次のエラーが返されます。

「Error Message: Nodegroup has health issue other than [ AsgInstanceLaunchFailures, InstanceLimitExceeded, InsufficientFreeAddresses, ClusterUnreachable]」

これは、ノードグループの Auto Scaling グループが Amazon Elastic Compute Cloud (Amazon EC2) 起動テンプレートの期待されるバージョンを見つけられないことを示しています。この失敗は、ノードグループに関連付けられているテンプレートのバージョンを手動で変更または削除した場合に発生します。これにより、EKS はノードグループをデグレード済みと表示します。

起動テンプレートをまだ削除していない場合は、Auto Scaling グループの起動テンプレートバージョンを手動で適切なバージョンに戻します。これにより、ノードグループは正常でアクティブな状態に戻り、更新プロセスを再開できます。

新しいノードがノードグループに移行していないため、更新に失敗しました

この問題は、ノードグループの新しいノードがクラスターに移行できない場合に発生します。その結果、ノードグループは以前のバージョンにロールバックします。この場合、次のエラーが表示されることがあります。

「NodeCreationFailure
Couldn't proceed with upgrade process as new nodes are not joining node group ng-backend」

更新したノードがクラスターに移行できない理由は複数あります。

既存のノードグループが使用するセキュリティグループルールを変更しました

ノードのセキュリティグループのアウトバウンドルールで、クラスターのセキュリティグループへのポート 443 が許可されていることを確認します。

**クラスターのセキュリティグループは、ノードセキュリティグループからのトラフィックを許可していません **

クラスターのセキュリティグループのインバウンドルールで、ノードのセキュリティグループからのポート 443 が許可されていることを確認します。詳細については、「Amazon EKS セキュリティグループの要件および考慮事項」を参照してください。

カスタム起動テンプレートを使用してノードグループを作成しました

カスタム起動テンプレートを更新する場合、テンプレートの新しいバージョンには正しいユーザーデータが含まれている必要があります。また、カスタム AMI を使用する場合は、その AMI がクラスターに移行するように正しく設定されていることを確認してください。

起動テンプレートの問題をトラブルシューティングするには、同じ起動テンプレートを使用して新しいノードグループを作成します。テンプレートがカスタム AMI の最新バージョンを使用していることを確認します。次に、ノードがクラスターに正常に移行するかどうかを確認します。ノードがクラスターに移行しない場合は、SSH でノードインスタンスに接続し、kubelet ログを確認します。

IAM 権限が不足しています

ノードグループの AWS ID およびアクセス管理 (IAM) ロールに必要な権限があるかどうかを確認します。

ACL がトラフィックを拒否します

ノードのサブネットのアクセスコントロールリスト (ACL) は、ポート 443 のアウトバウンドトラフィックまたはエフェメラルポートのインバウンドトラフィックを拒否する場合があります。ノードのサブネットでこれらのルールを許可するようにしてください。

同様に、クラスターのサブネットの ACL は、ポート 443 のインバウンドトラフィックを拒否する場合があります。クラスターのサブネットでこのトラフィックを許可するようにしてください。

新しいノードがプラグインを追加できません

Amazon Virtual Private Cloud (Amazon VPC) CNI プラグインまたは kube-proxy アドオンが表示されないことがあります。詳細については、「How do I resolve kubelet or CNI plugin issues for Amazon EKS? (Amazon EKS の kubelet または CNI のプラグインの問題を解決するにはどうすればよいですか?)」を参照してください。

サブネットに接続上の問題があります

Amazon EKS がノードを作成するサブネットは、必要なエンドポイントに接続できない場合があります。これらのエンドポイントには、Amazon Elastic Container Registry (Amazon ECR)、Amazon Simple Storage Service (Amazon S3)、Amazon EC2 などがあります。インターネットまたは VPC エンドポイントのいずれかを介して接続に失敗する可能性があります。VPC エンドポイントの場合は、ノードとエンドポイントのセキュリティグループをチェックし、必要なトラフィックが許可されていることを確認します。NAT ゲートウェイまたはインターネットゲートウェイを使用する場合は、サブネットのルートテーブル内のルーティングルールが正しいことを確認してください。また、対応する NAT ゲートウェイまたはインターネットゲートウェイが存在することを確認してください。

AWS公式
AWS公式更新しました 7ヶ月前
コメントはありません

関連するコンテンツ