Amazon EKS ノードグループの更新の失敗に関する一般的な問題をトラブルシューティングするにはどうすればよいですか?

簡単な説明

Amazon EKS の新しいリリースには、ノードグループの更新用の Amazon AMI の新しいバージョンも含まれています。複数のノードグループにワークロードをデプロイしているお客様は、リリースサイクルに合わせてノードを更新するという課題に対処しなければなりません。

マネージドノードグループの更新を開始すると、Amazon EKS が自動的にノードを更新します。Amazon EKS 最適化 AMI を使用している場合、Amazon EKS は最新の AMI リリースバージョンの一部として、最新のセキュリティパッチとオペレーティングシステムの更新をノードに自動的に適用します。更新を実装するために、AWS Auto Scaling はノードグループにノードが存在するすべてのアベイラビリティーゾーンでノードを起動します。このサービスはアベイラビリティーゾーンのリバランスも行います。既存のノードは一度しかドレインされないため、起動ステップは成功します。スケールダウンフェーズでは、Auto Scaling グループの最大サイズと希望サイズを 1 ずつ減らして、更新前の値に戻します。詳細については、「マネージド型ノードの更新動作」の「スケールダウンフェーズ」を参照してください。

解決方法

この更新プロセス中に、独自の緩和ステップを必要とする次のエラーの一部が表示される場合があります。これらの問題を事前に認識しておくと、ダウンタイムを最小限に抑えることができます。更新エラーの詳細については、「マネージド型ノードの更新動作」を参照してください。

Update failed due to PodEvictionFailure (PodEvictionFailure のため、更新に失敗しました)

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

このエラーは、アップグレードが PodEvictionFailure によってブロックされていることを示します。ポッドが 15 分以内にノードを離れず、強制フラグがない場合、アップグレードフェーズは PodEvictionFailure エラーで失敗します。

アップグレードフェーズで PodEvictionFailure エラーが発生する理由は次のとおりです。

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

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

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

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

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

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

$ kubectl get pdb --all-namespaces

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

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

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

3.    CloudWatch コンソールで、[Logs] (ログ) を選択します。その後、[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.    右上の [Custom] (カスタム) を選択して、更新の日付を指定します。アグレッシブ PDB が原因でノードグループの更新に失敗した場合は、resposeObject.message にポッドのエビクションが失敗した理由が記述されます。

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

$ kubectl edit pdb pdb_name;

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

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

Update failed due to non-valid release version (リリースバージョンが無効であるため、更新に失敗しました)

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 コントロールプレーンでサポートされているバージョンに置き換えてください。

Update failed as node group has health issues (ノードグループの正常性に問題があるため、更新に失敗しました)

Error message: Nodegroup has health issue other than [ AsgInstanceLaunchFailures, InstanceLimitExceeded, InsufficientFreeAddresses, ClusterUnreachable]

この失敗は、別のバージョンの Amazon Elastic Compute Cloud (Amazon EC2) 起動テンプレートを使用するようにノードグループの Auto Scaling グループを手動で変更した場合に発生します。または、ノードグループに関連付けられているテンプレートのバージョンを削除した可能性があります。EKS ノードグループは Auto Scaling グループの起動テンプレートと競合するデフォルトの起動テンプレートを使用します。この起動テンプレートにより、EKS はノードグループをデグレード済みと表示します。

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

---