**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # EKS 自動モードl のトラブルシューティング EKS 自動モードl ではAWS が AWS アカウント内の EC2 インスタンスに対してより多くの責任を負います。EKS はノード上のコンテナランタイム、ノード上のオペレーティングシステム、および特定のコントローラーに対して責任を負います。これにはブロックストレージコントローラー、ロードバランシングコントローラー、コンピューティングコントローラーなどがあります。 ノードのトラブルシューティングにはAWS API および Kubernetes API を使用する必要があります。次のようにできます： + Kubernetes `NodeDiagnostic` リソースを使用し、[ノードモニタリングエージェント](#auto-node-monitoring-agent)を使用することでノードログを取得します。詳細な手順については、[kubectl と S3 を使用してマネージドノードのノードログを取得する](auto-get-logs.md) を参照してください。 + Kubernetes `NodeDiagnostic` リソースを使用し、ノード上のネットワークトラフィックをキャプチャします。詳細な手順については、[kubectl と S3 を使用して、マネージドノード上のネットワークトラフィックをキャプチャする](auto-get-tcpdump.md) を参照してください。 + AWS EC2 CLI コマンド `get-console-output` を使用して、ノードからコンソール出力を取得します。詳細な手順については、[AWS EC2 CLI を使用して EC2 マネージドインスタンスからコンソール出力を取得する](#auto-node-console) を参照してください。 + Kubernetes *デバッグコンテナ*を使用してノードログを取得します。詳細な手順については、[*デバッグコンテナ*と `kubectl` CLI を使用してノードログを取得する](#auto-node-debug-logs) を参照してください。 **注記** EKS 自動モードl は EC2 マネージドインスタンスを使用します。SSH による場合を含め、EC2 マネージドインスタンスに直接アクセスすることはできません。 EKS Auto Mode コンポーネントに固有の解決策がある、次のような問題が発生する可能性があります。 + Auto Mode ノードにスケジュールされていない Pod が `Pending` 状態でスタックする。解決策については、「[Auto Mode ノードにスケジュールできない Pod のトラブルシューティング](#auto-troubleshoot-schedule)」を参照してください。 + EC2 マネージドインスタンスが Kubernetes ノードとしてクラスターに参加しない。解決策については、「[クラスターに参加しないノードのトラブルシューティング](#auto-troubleshoot-join)」を参照してください。 + EKS Auto Mode に含まれているコントローラーを使用する `NodePools`、`PersistentVolumes`、`Services` に関するエラーと問題。解決策については、「[Auto Mode に含まれているコントローラーのトラブルシューティング](#auto-troubleshoot-controllers)」を参照してください。 + 強化された Pod のセキュリティにより、Pod 間でボリュームを共有できない。解決策については、「[Pod 間でボリュームを共有する](#auto-troubleshoot-share-pod-volumes)」を参照してください。 EKS Auto Mode コンポーネントのトラブルシューティングには、次の方法を使用できます。 + [AWS EC2 CLI を使用して EC2 マネージドインスタンスからコンソール出力を取得する](#auto-node-console) + [*デバッグコンテナ*と `kubectl` CLI を使用してノードログを取得する](#auto-node-debug-logs) + [AWS コンソールで EKS 自動モード に関連付けられたリソースを表示する](#auto-node-ec2-web) + [AWS アカウントの IAM エラーを表示します](#auto-node-iam) + [`VPC Reachability Analyzer` でノード接続の問題を検出する](#auto-node-reachability) ## ノードモニタリングエージェント EKS 自動モードl には Amazon EKS ノードモニタリングエージェントが備わっています。このエージェントを使用して、ノードに関するトラブルシューティングとデバッグの情報を表示できます。ノードモニタリングエージェントはKubernetes `events` とノードの `conditions` を発行します。詳細については、[ノードのヘルス問題を検出し、自動ノード修復を有効にする](node-health.md) を参照してください。 ## AWS EC2 CLI を使用して EC2 マネージドインスタンスからコンソール出力を取得する この手順はブートタイムまたはカーネルレベルの問題のトラブルシューティングに役立ちます。 まず、ワークロードに関連付けられたインスタンスの EC2 インスタンス ID を決定する必要があります。次に、AWS CLI を使用してコンソール出力を取得します。 1. `kubectl` がインストールされ、クラスターに接続されていることを確認します 1. (任意 Kubernetes デプロイの名前を使用して、関連するポッドを一覧表示します。 ``` kubectl get pods -l app= ``` 1. Kubernetes ポッドの名前を使用して、関連付けられたノードの EC2 インスタンス ID を決定します。 ``` kubectl get pod -o wide ``` 1. EC2 インスタンス ID を使用してコンソール出力を取得します。 ``` aws ec2 get-console-output --instance-id --latest --output text ``` ## *デバッグコンテナ*と `kubectl` CLI を使用してノードログを取得する EKS Auto Mode ノードからログを取得するために推奨される方法は、`NodeDiagnostic` リソースを使用することです。手順については、「[kubectl と S3 を使用してマネージドノードのノードログを取得する](auto-get-logs.md)」を参照してください。 ただし、`kubectl debug node` コマンドを使用してインスタンスからログをライブストリーミングすることができます。このコマンドにより、デバッグするノードで新しい Pod が起動されて、インタラクティブに使用することができます。 1. デバッグコンテナを起動します。次のコマンドは、ノードのインスタンス ID に `i-01234567890123456` を使用し、インタラクティブな使用のために `-it` で `tty` を割り当てて `stdin` をアタッチし、kubeconfig ファイルの `sysadmin` プロファイルを使用します。 ``` kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 ``` 出力例は次のとおりです。 ``` Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456. If you don't see a command prompt, try pressing enter. bash-5.2# ``` 1. シェルから、`nsenter` コマンドを提供する `util-linux-core` をインストールできるようになりました。`nsenter` を使用してホスト上の PID 1 (`init`) のマウント名前空間を入力し、`journalctl` コマンドを実行して `kubelet` からログをストリーミングします。 ``` yum install -y util-linux-core nsenter -t 1 -m journalctl -f -u kubelet ``` セキュリティのため、Amazon Linux コンテナイメージはデフォルトでは多くのバイナリをインストールしません。`yum whatprovides` コマンドを使用して、特定のバイナリを提供するためにインストールする必要があるパッケージを識別できます。 ``` yum whatprovides ps ``` ``` Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025. procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities Repo : @System Matched from: Filename : /usr/bin/ps Provide : /bin/ps procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities Repo : amazonlinux Matched from: Filename : /usr/bin/ps Provide : /bin/ps ``` ## AWS コンソールで EKS 自動モード に関連付けられたリソースを表示する AWS コンソールを使用して、EKS 自動モードl クラスターに関連付けられているリソースのステータスを表示できます。 + [EBS ボリューム](https://console.aws.amazon.com/ec2/home#Volumes) + タグキー `eks:eks-cluster-name` を検索して EKS 自動モードl ボリュームを表示します + [ロードバランサー](https://console.aws.amazon.com/ec2/home#LoadBalancers) + タグキー `eks:eks-cluster-name` を検索して EKS 自動モードl ロードバランサーを表示します + [EC2 インスタンス](https://console.aws.amazon.com/ec2/home#Instances) + タグキー `eks:eks-cluster-name` を検索して EKS 自動モードl インスタンスを表示します ## AWS アカウントの IAM エラーを表示します 1. クラウドTrail コンソールに移動します 1. 左側のナビゲーションペインで [イベント履歴] を選択します 1. 次のエラーコードフィルターを適用します： + アクセス拒否 + 不正操作 + 無効なクライアントトークンID EKS クラスターに関連するエラーを探します。エラーメッセージを使用して、EKS アクセスエントリ、クラスター IAM ロール、またはノード IAM ロールを更新します。EKS Auto Mode に対するアクセス許可が付与された状態で、これらのロールを新しいポリシーにアタッチすることが必要になる場合があります。 ## Auto Mode ノードにスケジュールできない Pod のトラブルシューティング ポッドが `Pending` 状態のままになり、Auto Mode ノードにスケジュールされない場合は、ポッドまたはデプロイマニフェストに `nodeSelector` が含まれているかどうかを確認します。`nodeSelector` が存在する場合は、EKS Auto Mode によって作成されたノードでスケジュールされる `eks.amazonaws.com/compute-type: auto` が使用されていることを確認します。EKS Auto Mode で使用されるノードラベルの詳細については、「[ワークロードが EKS Auto Mode ノードにデプロイされるかどうかを制御する](associate-workload.md)」を参照してください。 ## クラスターに参加しないノードのトラブルシューティング EKS Auto Mode は、クラスターエンドポイントやクラスター証明機関 (CA) などの、クラスターに参加するための正しい情報を使用して新しい EC2 インスタンスを自動的に設定します。しかし、それでもこれらのインスタンスがノードとして EKS クラスターに参加できない場合があります。次のコマンドを実行して、クラスターに参加しなかったインスタンスを特定します。 1. `kubectl get nodeclaim` を実行して、`NodeClaims` が `Ready = False` であるかどうかを確認します。 ``` kubectl get nodeclaim ``` 1. `kubectl describe nodeclaim ` を実行して、**[ステータス]** でノードがクラスターに参加できない問題を見つけます。 ``` kubectl describe nodeclaim ``` **一般的なエラーメッセージ：** `Error getting launch template configs` デフォルトのクラスター IAM ロールのアクセス許可を使用して `NodeClass` でカスタムタグを設定する場合、このエラーが表示されることがあります。[EKS Auto Mode での ID とアクセスについての説明](auto-learn-iam.md) を参照してください。 `Error creating fleet` EC2 API から `RunInstances` コールを呼び出すと、認可の問題が発生する可能性があります。AWS CloudTrail でエラーを確認し、必要な IAM アクセス許可については「[Amazon EKS 自動モードl クラスター IAM ロール](auto-cluster-iam-role.md)」を参照してください。 ### `VPC Reachability Analyzer` でノード接続の問題を検出する **注記** VPC Reachability Analyzer を実行する分析ごとに課金されます。料金の詳細については、「[Amazon VPC の料金](https://aws.amazon.com/vpc/pricing/)」を参照してください。 インスタンスがクラスターに参加しない理由の 1 つは、API サーバーに到達できないネットワーク接続の問題です。この問題を診断するために、[VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) を使用して、クラスターに参加できないノードと API サーバー間の接続の分析を実行することができます。次の 2 つの情報が必要になります。 + クラスターに参加できないノードの**インスタンス ID** + **Kubernetes API サーバーエンドポイント**の IP アドレス **インスタンス ID** を取得するには、クラスターにワークロードを作成して、EKS Auto Mode で EC2 インスタンスを起動する必要があります。これにより、インスタンス ID を持つ `NodeClaim` オブジェクトもクラスター内に作成されます。`kubectl get nodeclaim -o yaml` を実行して、クラスター内のすべての `NodeClaims` を出力します。各 `NodeClaim` にはインスタンス ID がフィールドとして含まれ、providerID にも再度含まれています。 ``` kubectl get nodeclaim -o yaml ``` 出力例は次のとおりです。 ``` nodeName: i-01234567890123456 providerID: aws:///us-west-2a/i-01234567890123456 ``` **Kubernetes API サーバーエンドポイント**は、`kubectl get endpoint kubernetes -o yaml` を実行して判断できます。このアドレスは addresses フィールドにあります。 ``` kubectl get endpoints kubernetes -o yaml ``` 出力例は次のとおりです。 ``` apiVersion: v1 kind: Endpoints metadata: name: kubernetes namespace: default subsets: - addresses: - ip: 10.0.143.233 - ip: 10.0.152.17 ports: - name: https port: 443 protocol: TCP ``` これら 2 つの情報を使用して分析を実行できます。まず、AWS マネジメントコンソールで VPC Reachability Analyzer に移動します。 1. [パスを作成および分析] をクリックします 1. 分析の名前を指定します (例: 「Node Join Failure」) 1. [ソースタイプ] には [インスタンス] を選択します 1. 障害が発生したノードのインスタンス ID を [ソース] として入力します 1. [パスの送信先] に [IP アドレス] を選択します 1. API サーバーの IP アドレスの 1 つを [送信先アドレス] として入力します 1. [追加のパケットヘッダーの設定セクション] を展開します 1. [送信先ポート] に 443 と入力します 1. まだ選択されていない場合は、[プロトコル] を [TCP] として選択します 1. [パスを作成および分析] をクリックします 1. 分析の完了には数分かかることがあります。分析結果で到達可能性の失敗が示された場合は、ネットワークパスのどこで障害が生じたかが示され、問題を解決することができます。 ## Pod 間でボリュームを共有する EKS Auto Mode ノードは、SELinux の強制モードで設定され、同じノードで実行されている Pod 間の分離を強化します。SELinux を有効にすると、特権のないほとんどのポッドに、独自のマルチカテゴリセキュリティ (MCS) ラベルが自動的に適用されます。この MCS ラベルは Pod ごとに一意であり、1 つの Pod のプロセスで他の Pod またはホストのプロセスを操作できないように設計されています。ラベル付き Pod がルートとして実行され、ホストファイルシステムにアクセスできる場合でも、ファイルの操作、ホストでの機密システムの呼び出し、コンテナランタイムへのアクセス、kubelet のシークレットキーマテリアルの取得を行うことはできません。 このため、Pod 間でデータを共有しようとすると問題が発生する可能性があります。例えば、アクセスモードが `ReadWriteOnce` の `PersistentVolumeClaim` でも、複数の Pod がボリュームに同時にアクセスすることはできません。 Pod 間でこの共有を有効にするには、Pod の `seLinuxOptions` を使用して、これらの Pod に同じ MCS ラベルを設定します。この例では、Pod に 3 つのカテゴリ (`c123,c456,c789`) を割り当てます。2 つのカテゴリが割り当てられるだけであるため、これによりノード上の Pod に自動的に割り当てられたカテゴリとの競合が発生することはありません。 ``` securityContext: seLinuxOptions: level: "s0:c123,c456,c789" ``` ## コントロールプレーンログで Karpenter イベントを表示する コントロールプレーンログが有効になっている EKS クラスターの場合、ログをクエリすることで Karpenter のアクションと意思決定プロセスに関するインサイトを得ることができます。これは、ノードのプロビジョニング、スケーリング、終了に関連する EKS オートモードの問題のトラブルシューティングに特に役立ちます。Karpenter 関連のイベントを表示するには、次の CloudWatch Logs Insights クエリを使用します。 ``` fields @timestamp, @message | filter @logStream like /kube-apiserver-audit/ | filter @message like 'DisruptionBlocked' or @message like 'DisruptionLaunching' or @message like 'DisruptionTerminating' or @message like 'DisruptionWaitingReadiness' or @message like 'Unconsolidatable' or @message like 'FailedScheduling' or @message like 'NoCompatibleInstanceTypes' or @message like 'NodeRepairBlocked' or @message like 'Disrupted' or @message like 'Evicted' or @message like 'FailedDraining' or @message like 'TerminationGracePeriodExpiring' or @message like 'TerminationFailed' or @message like 'FailedConsistencyCheck' or @message like 'InsufficientCapacityError' or @message like 'UnregisteredTaintMissing' or @message like 'NodeClassNotReady' | sort @timestamp desc ``` このクエリは、kube-apiserver 監査ログ内の特定の [Karpenter 関連イベント](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go)をフィルタリングします。イベントには、さまざまな中断状態、スケジュールの失敗、容量の問題、ノード関連の問題が含まれます。これらのログを分析することで、以下をよりよく理解できます。 + Karpenter が特定のアクションを実行する理由。 + ノードの適切なプロビジョニング、スケーリング、または終了を妨げる問題。 + インスタンスタイプで発生する可能性のある容量または互換性の問題。 + 中断、削除、終了などのノードのライフサイクルイベント。 このクエリを使用するには: 1. CloudWatch コンソールに移動する 1. 左のナビゲーションペインから、[Logs Insights] を選択する 1. EKS クラスターのコントロールプレーンログのロググループを選択する 1. クエリエディタにそのクエリを貼り付ける 1. 必要に応じて時間範囲を調整する 1. クエリを実行します その結果、Karpenter 関連のイベントのタイムラインが表示され、問題のトラブルシューティングやクラスター内の EKS オートモードの動作の理解に役立ちます。特定のノードで Karpenter アクションを確認するには、前述のクエリにインスタンス ID を指定する以下の行フィルターを追加できます。 ``` |filter @message like /[.replaceable]`i-12345678910123456`/ ``` **注記** このクエリを使用するには、EKS クラスターでコントロールプレーンのログ記録を有効にする必要があります。これをまだ実行していない場合は、[コントロールプレーンログを CloudWatch Logs に送信する](control-plane-logs.md) を参照してください。 ## Auto Mode に含まれているコントローラーのトラブルシューティング コントローラーに問題がある場合は以下について調べる必要があります： + そのコントローラーに関連付けられているリソースが適切にフォーマットされ、有効であるかどうか。 + AWS IAM リソースおよび Kubernetes RBAC リソースがクラスター用に適切に設定されているかどうか。詳細については、[EKS Auto Mode での ID とアクセスについての説明](auto-learn-iam.md) を参照してください。 ## 関連リソース 高度なトラブルシューティング手順については、AWS re:Post の以下の記事を参照してください。 + [EKS 自動モードでよくあるスケールの問題をトラブルシューティングするにはどうすればよいか](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ) + [Amazon EKS 自動モードでカスタムノードプールとノードクラスのプロビジョニングに関する問題をトラブルシューティングするにはどうすればよいか](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ) + [EKS 自動モードに組み込みのノードプールでステータスが不明になる問題をトラブルシューティングするにはどうすればよいか](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)