AWS Fargate 上の Amazon EKS ポッドが保留中の状態でスタックしている場合のトラブルシューティング方法を教えてください。

最終更新日:2021年12月20日

AWS Fargate インスタンスで実行されている Amazon Elastic Kubernetes Service (Amazon EKS) ポッドが保留中の状態でスタックしています。これらのポッドを実行するにはどうしたらいいですか?

簡単な説明

AWS Fargate を使用してAmazon Elastic Kubernetes Service (Amazon EKS) でポッドが実行されないようにする一般的なシナリオをいくつか紹介します。

  • 特定の vCPU とメモリの組み合わせが使用できないため、キャパシティエラーが発生しています
  • CoreDNS Pod はデフォルトのアノテーションで作成されており、Fargate ノードでスケジュールするには削除する必要があります。
  • ポッドは作成時にどの Fargate プロファイルとも一致せず、fargate-scheduler に割り当てられていません。Pod が作成時に一致しない場合、一致するプロファイルが後で作成されても、Pod は Fargate ノードに自動的に再スケジュールされません。この場合、Pod は default-scheduler に割り当てられます。
  • Pod が fargate-scheduler に割り当てられているが Pending 状態のままである場合は、追加のトラブルシューティングが必要になることがあります。

トラブルシューティングを行う前に、Fargate の次の Pod ルールに注意してください。

  • Pod セレクターに名前空間とマッチラベルの両方を設定した場合:Fargate ワークフローは、両方の条件が Pod 仕様に一致する場合にのみ Pod を Fargate プロファイルに一致させます。
  • 単一の Fargate プロファイル内で複数の Pod セレクターを指定した場合、いずれかのセレクターに一致する場合、Pod は fargate-schedule によってスケジュールされます。
  • Pod 仕様が複数の Fargate プロファイルと一致する場合、Pod はランダムな Fargate プロファイルに従ってスケジュールされます。これを回避するには、<fp_name>ポッドの仕様内でアノテーション eks.amazonaws.com/fargate-profile: を使用できます。

解決方法

ポッドのステータスを確認する

1.    次のコマンドを実行して、ポッドの状態を確認します。

kubectl get pods -n <namespace>

2.    Pod に関する詳細なエラー情報を取得するには、次の describe コマンドを実行します。

kubectl describe pod YOUR_POD_NAME -n <namespace>

describe コマンドの出力に基づいて、次の解決方法を参照してください。

キャパシティエラーの解決

Pod にキャパシティの問題がある場合、 describe の出力は次のようになります。

Fargate capacity is unavailable at this time. Please try again later or in a different availability zone

このエラーを解決するには:

  • 15 ~ 20 分後に Pod を再試行します。誤差は容量に基づいているため、正確な時間は変動する可能性があります。
  • Pod 仕様内でリクエスト (CPU/メモリ) を変更します。vCPU/メモリの新しい組み合わせが Fargate ワークフローによってプロビジョニングされます。
    注:いずれかの組み合わせに基づいて請求されます。Pod の仕様に基づいて組み合わせがどのように確定されるかについては、「Pod CPU とメモリ」を参照してください。ターミナル/IDE から「kubectl describe node」コマンドを実行すると、vCPU/メモリーの組み合わせの値が大幅に高くなる可能性があります。Fargate は、リクエストに基づいて常にキャパシティを利用できるわけではなく、ベストエフォートベースでキャパシティプールからリソースをプロビジョニングします。ただし、Pod の使用量および同等の vCPU/メモリーの組み合わせに対してのみ課金されます。

保留状態の CoreDNS Pod の解決

Pod が CoreDNS Pod の場合、describe 出力の Pod の名前は次のようになります。

NAME                                     READY   STATUS     RESTARTS      AGE
coredns-6548845887-qk9vf                 0/1     Pending    0             157m

これを解決し、ポッドを Fargate スケジューラに再割り当てするには、 CoreDNS デプロイメントにパッチを適用して eks.amazonaws.com/compute-type: ec2 というデフォルトの注釈を削除します。

default-scheduler に割り当てられた Pod の解決

Pod が割り当てられているスケジューラーを確認するには、以下のコマンドを実行します。

kubectl get pods -o yaml -n <namespace> <pod-name> | grep schedulerName.

出力で schedulerName default-scheduler であることを確認し、Pod 仕様を更新して Pod を再作成します。

schedulerName fargate-scheduler であってもエラーが発生する場合は、Pod がすべてのルールと Fargate の考慮事項に従っていることを確認します。トラブルシューティングの手順については、次のセクションを参照してください。

fargate-scheduler に割り当てられた Pod のトラブルシューティング

Pod が fargate-scheduler に割り当てられているが Pending 状態のままである場合、 describe の出力は次のようになります。

Events:
Type       Reason              Age                     From     
----       ------              ----                    ----     
Warning    FailedScheduling    2m25s (x301 over 5h3m)  fargate-scheduler

このエラーのトラブルシューティング方法:

  • Pod を削除して再作成します。
  • Pod 仕様 YAML に以下が設定されていないことを確認します。
    ノードセレクタ
    <>ノード名
    schedulerName
    これらの仕様により、fargate-scheduler は Pod をスキップします。
  • Fargate プロファイルで選択したサブネットに、新しい Pod を作成するのに十分な空き IP アドレスがあることを確認します。各 Fargate ノードは、サブネットから 1 つの IP アドレスを消費します。
  • NAT ゲートウェイがパブリックサブネットに設定され、Elastic IP がアタッチされていることを確認します。
  • VPC に関連付けられている DHCP オプションセットに AmazonProvidedDNS またはドメインネームサーバー用の有効な DNS サーバーホスト名があることを確認します。
  • VPC の DNS ホスト名と DNS 解決がオンになっていることを確認します。
  • VPC エンドポイントのみがサービス通信用に設定された Fargate Pod にプライベートサブネットを使用している場合は、DNS 名が許可された次のエンドポイントがあることを確認します。
    ECR-API
    ECR-DKR
    S3 ゲートウェイエンドポイント
  • VPC エンドポイントにアタッチされたセキュリティグループが Fargate と API サーバーとの間の通信を許可していることを確認します。VPC エンドポイントセキュリティグループは、クラスター VPC CIDR からのポート 443 の進入を許可する必要があります。クラスターのプライベートエンドポイントアクセスもオンにする必要があります

この記事は役に立ちましたか?


請求に関するサポートまたは技術サポートが必要ですか?