ポッドのトラブルシューティングSOP - - Alibaba Cloud ドキュメントセンター

このトピックでは、ポッドの診断手順と、ポッドエラーのトラブルシューティング方法について説明します。このトピックでは、ポッドに関するよくある質問に対する回答も提供します。

説明

コンソールでポッドの問題をトラブルシューティングする方法については、「コンソールでのトラブルシューティング」をご参照ください。コンソールでは、ポッドのステータス、基本情報、構成、イベント、ログを表示したり、ターミナルを使用してコンテナにアクセスしたり、ポッド診断を有効にしたりできます。

診断手順

ポッドが正常に実行されない場合は、ポッドのイベント、ログ、構成を確認することで原因を特定できます。下図にプロセスを示します。

フェーズ1: スケジューリングの問題

ポッドのスケジュールに失敗しました

ポッドがPending状態のままである場合は、ポッドのスケジューリングに失敗したことを意味します。考えられる原因を次の表に示します。

エラーメッセージ	説明	推奨ソリューション
`ポッドをスケジュールするノードがありません。`	クラスターには、ポッドスケジューリングに使用できるノードがありません。	クラスター内のノードがNotReady状態であるかどうかを確認します。ノードがNotReady状態の場合は、そのノードのトラブルシューティングと修復を行います。ノードセレクタ、ノードアフィニティルール、またはテイント許容範囲がポッドに設定されているかどうかを確認します。ポッドにアフィニティルールが設定されていない場合は、ノードプール内のノード数を増やします。
`0/xノードが使用可能です: x不十分なcpu。` `0/xノードが使用可能です: xメモリ不足。`	クラスターには、ポッドのCPUまたはメモリ要求を実行できるノードがありません。	[ノード] ページで、ポッド、CPU、およびメモリ使用率を表示し、クラスターリソース使用率を確認します。説明ノードのCPUとメモリの使用率が低いレベルに維持されている場合、ノードへの新しいポッドのスケジューリングはノードリソースを使い果たしません。ただし、スケジューラは、ピーク時に新しいポッドでノードリソースが不足するかどうかを確認し、不適切なリソーススケジューリングを回避しようとします。クラスタ内のCPUまたはメモリリソースが使い果たされた場合、次の方法を使用します。不要なポッドを削除します。詳細については、「ポッドの管理」をご参照ください。ポッドのリソース構成を変更します。詳細については、「ポッドのCPUおよびメモリリソースの上限と下限の変更」をご参照ください。リソースプロファイリングを有効にして、コンテナーの推奨リソースリクエストと制限を取得します。ポッドのアフィニティルールに基づいてクラスターにノードを追加します。詳細については、「ノードプールの作成」をご参照ください。ノードのアップグレード詳細については、「ワーカーノードの設定のアップグレード」をご参照ください。
`xノードがノードセレクターと一致しませんでした。` `xノードは、ポッドのアフィニティ /アンチアフィニティと一致しませんでした。`	クラスターには、ポッドのノードアフィニティルール (nodeSelector) またはアフィニティとアンチアフィニティルール (podAffinityおよびpodAnitiAffinity) に一致するノードがありません。	ノードラベル、nodeSelector、nodeAffinity、taints、tolerationsなど、ポッドのノードアフィニティルールを確認して変更します。ポッドのポッドアフィニティルールを確認して変更します。ノードがポッドアフィニティ規則に一致できるかどうかを評価します。 podAffinityが設定されている場合は、目的のノードのpodAffinityに一致するポッドを確認します。 podAntiAffinityが設定されている場合は、目的のノードでpodAntiAffinityと一致するポッドを確認します。
`0/xノードが利用可能である: xノードは、ボリュームノードアフィニティ競合を有する。`	ディスクボリュームをゾーン間でマウントできないため、ポッドで使用されるボリュームでノードアフィニティの競合が発生します。その結果、ポッドのスケジュールに失敗しました。	ポッドが静的にプロビジョニングされた永続ボリューム (PV) を使用し、PVのゾーン内のノードにポッドをスケジュールする場合は、ポッドのノードアフィニティ規則を設定する必要があります。ポッドが動的にプロビジョニングされたPVを使用する場合、ディスクボリュームのStorageClassのvolumeBindingModeをWaitForFirstConsumerに設定する必要があります。この方法では、ポッドがノードにスケジュールされた後にのみボリュームが作成されます。これにより、ポッドをホストするノードのゾーンにボリュームが確実に存在します。
`InvalidInstanceType.NotSupportDiskCategory`	ディスクタイプはElastic Compute Service (ECS) インスタンスでサポートされていません。	「インスタンスファミリーの概要」を参照し、ECSインスタンスでサポートされているディスクタイプを確認します。 ECSインスタンスでサポートされているディスクをポッドにマウントします。
`0/xノードが使用可能です: xノードには、ポッドが許容しなかった汚染がありました。`	ノードにtaintがあるため、ポッドを目的のノードにスケジュールできませんでした。	テイントが手動で追加された場合は、テイントを削除します。テイントを保持する必要がある場合は、ポッドに許容範囲を追加できます。詳細については、「テイントと許容範囲」および「テイントの管理」をご参照ください。システムによってテイントが追加された場合は、次のソリューションを参照し、スケジューラがポッドのスケジュールを変更するのを待ちます。システムによって追加されたテイントの表示 `node.kubernetes.io/not-ready`: ノードはNotReady状態です。 `node.kubernetes.io/unreachable`: ノードコントローラーがノードへのアクセスに失敗しました。ノードの`Ready`フィールドの値は`Unknown`です。 `node.kubernetes.io/memory-pressure`: ノードに十分なメモリリソースがありません。 `node.kubernetes.io/disk-pressure`: ノードに十分なディスク容量がありません。 `node.kubernetes.io/pid-pressure`: ノードに十分なプロセスID (pid) がありません。 `node.kubernetes.io/network-unavailable`: ノードのネットワークが利用できません。 `node.kubernetes.io/unschedulable`: ノードはUnschedulable状態です。
`0/xノードが使用可能です: xエフェメラルストレージが不十分です。`	ノードに十分な一時的なストレージスペースがありません。	ポッドYAMLファイルの`spec.containers.resources.request.ephemeral-storage`で指定されているエフェメラルボリュームに制限があるかどうかを確認します。値がノードの一時的なストレージ容量を超える場合、ポッドのスケジュールに失敗しました。 `kubectl describe node \| grep -A10 Capacity`コマンドを実行して、すべてのノードの一時的なストレージ容量の合計を表示します。ストレージ容量が要件を満たしていない場合は、ノードのディスクを拡張するか、ノードを追加します。
`0/xノードが利用可能です: ポッドにバインド解除されたPersistentVolumeClaimesがあります。`	永続ボリューム要求 (PVC) がポッドにバインドできませんでした。	ポッドに指定されたPVCまたはPVが作成されているかどうかを確認します。 `kubectl describe pvc <pvc-name>` または`kubectl describe pv <pv-name>` コマンドを実行して、PVCまたはPVのイベントを表示できます。詳細については、「」をご参照ください。ポッドに対して「0/xノードが利用可能: x pod has unbound immediate PersistentVolumeClaims」イベントが生成されるのはなぜですか?

ポッドはすでにノードにスケジュールされています

ポッドがすでにノードにスケジュールされているが、Pending状態のままである場合は、次のソリューションを参照してください。

ポッドがhostPortで構成されているかどうかを確認します。ポッドがhostPortで構成されている場合、各ノードでhostPortを使用するポッドは1つだけ実行できます。したがって、DeploymentまたはReplicationControllerのReplicasの値は、クラスター内のノード数を超えてはなりません。ノードのホストポートが他のアプリケーションによって使用されている場合、ポッドはノードにスケジュールされませんでした。
hostPortを設定すると、ポッドの管理とスケジューリングが複雑になります。サービスを使用してポッドにアクセスすることを推奨します。詳細については、「サービス」をご参照ください。
ポッドにhostPortが設定されていない場合は、次の手順を実行します。
1. kubectl describe pod <pod-name> コマンドを実行して、ポッドのイベントを表示し、問題のトラブルシューティングを行います。イベントには、イメージプルの失敗、リソースの不足、セキュリティポリシーによる制限、構成エラーなど、ポッドの起動失敗の原因が表示される場合があります。
2. イベントの原因を特定できなかった場合は、ノードのkubeletのログを確認してください。 grep -i <pod name> /var/log/messages * | lessコマンドを実行して、システムログファイル (/var/log/messages *) 内のポッド名を含むログエントリを確認できます。

フェーズ2: 画像のプルの問題

エラーメッセージ	説明	推奨ソリューション
`Failed to pull image "xxx": rpc error: code = Unknown desc=デーモンからのエラー応答: Get xxx: denied:`	`imagePullSecret`がポッドに設定されていないため、イメージリポジトリへのアクセスは拒否されます。	ポッドYAMLファイルの`spec.template.imagePullSecrets`パラメーターに指定されたシークレットが存在するかどうかを確認します。 Container Registryを使用する場合は、aliyun-acr-credential-helperコンポーネントを使用して、パスワードなしで画像をプルできます。詳細については、「aliyun-acr-credential-helperコンポーネントを使用して、シークレットを使用せずにイメージをプルする」をご参照ください。
`イメージ "xxxx:xxx" のプルに失敗しました: rpc error: code = Unknown desc=デーモンからのエラー応答: Get https:// xxxxxx/xxxxx/: dial tcp: lookup xxxxxxx.xxxxx: no such host`	指定されたイメージリポジトリからHTTP経由でイメージをプルするときに、イメージアドレスの解析に失敗しました。	ポッドYAMLファイルの`spec.containers.image`パラメーターで指定されたイメージリポジトリのアドレスが正しいかどうかを確認します。そうでない場合は、イメージリポジトリのアドレスを修正します。アドレスが正しい場合は、ポッドのノードがイメージリポジトリのネットワークに接続されているかどうかを確認します。「ECSインスタンスへの接続方法」を参照してポッドのノードにログインし、`curl -kv https:// xxxxxx/xxxxx/` コマンドを実行して、ノードがイメージリポジトリにアクセスできるかどうかを確認します。エラーがスローされた場合は、ネットワークアクセスの問題について、ネットワーク構成、ファイアウォールルール、およびDNS構成を確認します。
`Failed create pod sandbox: rpc error: code = Unknown desc=pod "xxxxxxxxx" のサンドボックスの作成に失敗しました: デーモンからのエラー応答: mkdir xxxxx: デバイスにスペースが残っていません`	ノードに十分なディスク容量がありません。	「ECSインスタンスへの接続方法」を参照してポッドのノードにログインし、`df -h`コマンドを実行してディスク容量を表示します。ディスク容量がなくなった場合は、ディスクを拡張してください。詳細については、「手順1: ディスクのサイズを変更してディスクの容量を拡張する」をご参照ください。
`Failed to pull image "xxx": rpc error: code = Unknown desc = error pulling image configuration: xxx x509: certificate signed by unknown authority`	サードパーティのイメージリポジトリは、未知または信頼できない認証局によって署名および発行された証明書を使用します。	信頼できる認証局によって署名および発行された証明書を使用することを推奨します。イメージがプライベートイメージリポジトリから取得されているかどうかを確認します。詳細については、「プライベートイメージリポジトリからのアプリケーションの作成」をご参照ください。イメージリポジトリを変更できない場合は、次の手順を参照して、信頼できない証明書を使用してイメージリポジトリからイメージをプルし、イメージリポジトリにイメージをプッシュするようにノードを設定します。この方法はノード上の他のポッドに影響を与える可能性があるため、ステージング環境でこの方法を使用することを推奨します。プロシージャの表示 containerdの証明書ディレクトリを作成して、イメージリポジトリに関連する証明書構成ファイルを格納します。 `$ mkdir -p /etc/containerd/cert.d/xxxxx` イメージリポジトリを信頼するようにcontainerdを設定します。 `$ cat << EOF > /etc/containerd/cert.d/xxxxx/hosts.toml server = "https://harbor.test-cri.com" [host."https://harbor.test-cri.com"] capabilities = ["pull", "resolve", "push"] skip_verify = true # ca = "/opt/ssl/ca.crt" # You can also upload a CA certificate. EOF` 信頼できないイメージリポジトリをDockerデーモン設定に追加します。 `vi /etc/docker/daemon.json` 次の内容を追加します。 `-insecure-registry`を信頼できないイメージリポジトリのアドレスに置き換えます。 `{ "insecure-registries": ["your-insecure-registry"] }` 変更が有効になるようにサービスを再起動します。 `systemctl restart systemd systemctl restart docker`
`Failed to pull image "XXX": rpc error: code = Unknown desc = context canceled`	イメージファイルが大きすぎるため、操作がキャンセルされます。 Kubernetesには、イメージプルのデフォルトのタイムアウト期間があります。イメージプルの進行状況が特定の期間内に更新されなかった場合、Kubernetesはエラーが発生した、または応答が返されなかったと見なし、操作をキャンセルします。	ポッドYAMLファイルの`imagePullPolicy`パラメーターが`IfNotPresent`に設定されているかどうかを確認します。 [ECSインスタンスへの接続方法] を参照してポッドのノードにログインし、`docker pull`または`ctr images pull`コマンドを実行して、イメージが正常にプルできるかどうかを確認します。
`イメージ "xxxxx" のプルに失敗しました: rpc error: code = Unknown desc=デーモンからのエラー応答: Get https:// xxxxxxx: xxxxx/http: リクエストは接続待機中にキャンセルされました (クライアント。ヘッダーを待機中にタイムアウトを超えました)`	イメージリポジトリへの接続に失敗しました。	[ECSインスタンスへの接続方法] を参照してポッドのノードにログインし、`curl https:// xxxxxx/xxxxx/` コマンドを実行して、イメージリポジトリのアドレスにアクセスできるかどうかを確認します。エラーがスローされた場合は、ネットワークアクセスの問題について、ネットワーク構成、ファイアウォールルール、およびDNS構成を確認します。ノードのインターネットアクセスポリシーが期待どおりに設定されているかどうかを確認します。たとえば、送信元ネットワークアドレス変換 (SNAT) エントリとEIPを確認します。
`多すぎるリクエスト。`	DockerHubは、イメージプルリクエストにレート制限を設定します。	イメージをContainer Registryにアップロードし、Container Registryからイメージを取得します。
`プル画像`が常に表示されます	kubeletを使用することによる画像引き込みの上限に達することがある。	「ノードプールのkubeletパラメーターのカスタマイズ」を参照し、最大イメージリポジトリQPS (registryPullQPS) とイメージプルのバーストの最大サイズ (registryBurst) を変更します。

フェーズ3: スタートアップの問題

ポッドがInit状態

エラーメッセージ	説明	推奨ソリューション
ポッドは`Init:N/M`状態のままです。	ポッドにはM個のInitコンテナが含まれています。 N個のコンテナが開始されました。 M-N Initコンテナーが開始されていません。	`kubectl describe pod -n <ns> <pod name>` コマンドを実行して、ポッドのイベントを表示します。開始していないInitコンテナで異常が発生しないことを確認します。 `kubectl logs -n <ns> <pod name> -c <container name>` コマンドを実行して、ポッドで開始されていないInitコンテナのログを表示し、ログデータに基づいてエラーをトラブルシューティングします。ポッド構成のInitコンテナー構成にヘルスチェック構成などのエラーが含まれているかどうかを確認します。 initコンテナーの詳細については、「initコンテナーのデバッグ」をご参照ください。
ポッドは`Init:Error`状態のままです。	ポッド内のInitコンテナーの起動に失敗しました。
ポッドは`Init:CrashLoopBackOff`状態のままです。	ポッド内のInitコンテナーの起動に失敗し、繰り返し再起動しました。

ポッドが作成中 (作成中)

エラーメッセージ	説明	推奨ソリューション
`範囲0の割り当てに失敗しました: 範囲セットで使用可能なIPアドレスがありません: xx.xxx.xx.xx-xx.xx.xx.xx`	このエラーは、Flannelネットワークプラグインの設計が原因で予想されます。	フランネルをv0.15.1.11-7e95fe23-aliyun以降に更新します。詳細については、「フランネル」をご参照ください。
	クラスターが1.20より前のバージョンのKubernetesを実行し、ポッドが繰り返し再起動するか、CronJobによって作成されたポッドがタスクを完了し、短時間で終了すると、IPリークが発生する可能性があります。	クラスターのKubernetesバージョンを1.20以降に更新します。最新バージョンに更新することを推奨します。詳細については、「手動でACKクラスターをアップグレード」をご参照ください。
	containerdとrunCには欠陥があります。	詳細については、「」をご参照ください。ポッドの起動に失敗し、「範囲内で使用可能なIPアドレスはありません」というエラーメッセージが表示された場合はどうすればよいですか?
`エラー解析設定、can't found dev by mac 00:16:3e:01:c2:e8: not found`	Terwayによって維持され、ポッドのノードでelastic network Interface (ENI) を追跡および管理するために使用される内部データベースのステータスが、実際のネットワークデバイス構成と一致していません。その結果、ENIの割り当てに失敗した。	ENIは非同期にロードされます。 CNIを設定すると、システムはまだENIをロードしている可能性があります。これにより、CNIはENIの割り当てを再試行できます。これは最終的なENI割り当て結果には影響しません。ポッドの最終状態に基づいて、操作が成功したかどうかを判断できます。ポッドの作成に長時間失敗し、前述のエラーがスローされた場合、高レベルメモリが不足しているため、ENIのアタッチ中にドライバをロードできませんでした。この問題に対処するには、対応するECSインスタンスを再起動します。詳細は、「インスタンスの再起動」をご参照ください。
`cmdAdd: エラーalloc ip rpcエラー: code = DeadlineExceeded desc=コンテキストの期限を超えました` `cmdAdd: error alloc ip rpc error: code = Unknown desc = error wait pod eni info, timed out waiting for the condition`	TerwayはvSwitchからIPアドレスを要求できませんでした。	ポッドをホストするノードでTerwayポッドのコンテナログを表示し、ENIの割り当てプロセスを確認します。 `kubectl logs -n kube-system <terwayPodName > -c terway \| grep <podName>` コマンドを実行し、TerwayポッドのENI情報を表示します。 IPアドレスを要求するために実行される操作の要求IDと、APIによって返されるエラーメッセージを取得します。リクエストIDとエラーメッセージに基づいて原因を特定します。

ポッドの起動に失敗しました (CrashLoopBackOff)

エラーメッセージ	説明	推奨ソリューション
ログに`exit (0)` が表示されます。		異常なワークロードがデプロイされているノードにログインします。 `docker ps -a \| grep $podName`コマンドを実行します。ポッドに永続プロセスが存在しない場合、`exit (0)` が表示されます。
イベント情報には、`Liveness probe failed: Get http…` が表示されます。	ヘルスチェックに失敗しました。	ポッドのlivenessプローブポリシーを確認します。 livenessプローブの結果が、ポッドのコンテナーで実行されているアプリケーションの実際のステータスを示すことができることを確認します。
ポッドログには`左スペースなし`が表示されます。	ディスク容量が不足しています。	手順1: ディスクのサイズを変更してディスクの容量を拡張するを参照してください。未使用のイメージを削除してディスク領域を解放し、imageGCHighThresholdPercentを設定して、ノードでイメージガベージコレクションをトリガーするためのしきい値を調整します。
ポッドの起動に失敗し、イベントが生成されません	ポッドのリソース制限は、ポッドによって要求されたリソースよりも低くなっています。その結果、ポッド内のコンテナは起動できませんでした。	ポッドのリソース設定を確認します。リソースプロファイリングを有効にして、推奨リソースリクエストとリソース制限を取得できます。
ポッドログに `[アドレスは既に使用中]` が表示されます。	ポッド内のコンテナがポート競合に遭遇します。	`hostNetwork: true`がポッドに設定されているかどうかを確認します。存在する場合、ポッド内のコンテナはホストとENIとポートを共有します。ホストネットワークを使用しない場合は、`hostNetwork: false`を指定します。 `hostNetwork: true`が設定されている場合、同じレプリカセットのポッドが同じノードにスケジュールされないように、ポッドアンチアフィニティ規則を設定します。同じポートを使用するポッドが同じノードにスケジュールされていないことを確認してください。
ポッドログには、`container init caused \"setenv: invalid argument\": unknown`が表示されます。	ワークロードはシークレットでマウントされます。 Secretのキー値はBase64を使用してエンコードされません。	コンソールで作成されたSecretsのキー値は、Base64を使用して自動的にエンコードされます。詳細については、「シークレットの管理」をご参照ください。 YAMLを使用してシークレットを作成し、`echo -n "xxxxx" \| base64`コマンドを実行して、base64を使用してキー値を暗号化します。
ビジネス上の問題が存在します。		ポッドログに基づいて原因を特定します。

フェーズ4: ポッド操作の問題

OOM

クラスター内のコンテナのメモリ使用量が指定されたメモリ制限を超えると、コンテナが終了し、OOMイベントがトリガーされ、コンテナが終了します。 OOMイベントの詳細については、「コンテナーとポッドへのメモリリソースの割り当て」をご参照ください。

プロセスの終了によりコンテナがスタックした場合、コンテナは再起動することができる。
OOMエラーが発生した場合は、コンソールにログインしてポッドの詳細ページに移動します。 [イベント] タブでは、次のOOMイベントを表示できます。pod was OOM killed.
クラスターにコンテナーレプリカ例外のアラートルールが設定されている場合、OOMイベントが発生するとアラートが受信されます。詳細については、「アラート管理」をご参照ください。

OOMレベル	説明	推奨ソリューション
OSレベル	ポッドをホストするノードのカーネルログ (`/var/log/messages`) には、killedプロセスが表示されますが、cgroupログは生成されません。これは、OOMエラーがOSレベルであることを意味します。	考えられる原因は、メモリ断片化中のシステムグローバルメモリ不足、ノードメモリ不足、またはバディシステムメモリ不足です。メモリ不足の原因の詳細については、「考えられる原因」をご参照ください。ソリューションの詳細については、「ソリューション」をご参照ください。
cgroupレベル	ポッドをホストするノードのカーネルログ (`/var/log/messages`) には、次のようなエラーメッセージが表示されます。`Task in /kubepods.slice/xxxxx kill after of limit of /kubepods.slice/xxxx` これは、OOMエラーがcgroupレベルであることを意味します。	プロセスが通常どおりに実行される場合は、それに応じてポッドのメモリ制限を増やします。ポッドの実際のメモリ使用量がメモリ制限の80% を超えないようにしてください。詳細については、「ポッドのCPUおよびメモリリソースの上限と下限の変更」をご参照ください。リソースプロファイリングを有効にして、コンテナーの推奨リソースリクエストとリソース制限を取得できます。

終了

考えられる原因	説明	推奨ソリューション
ノードが異常で、NotReady状態です。		NotReadyノードは、回復後に自動的に削除されます。
ファイナライザーはポッド用に設定されています。	ポッドにファイナライザーが設定されている場合、Kubernetesはポッドを削除する前にファイナライザーによって指定されたクリーンアップ操作を実行します。クリーンアップ操作に対して応答が返されない場合、ポッドは終了状態のままです。	`kubectl get pod -n <ns> <pod name> -o yaml`コマンドを実行して、ポッドのファイナライザー設定を表示し、原因を特定します。
ポッドのpreStopフックが無効です。	preStopフックがポッドに設定されている場合、Kubernetesはポッドを終了する前にpreStopフックで指定された操作を実行します。ポッドはpreStop段階にあり、終了状態になります。	`kubectl get pod -n <ns> <pod name> -o yaml`コマンドを実行して、ポッドのpreStop設定を表示し、原因を特定します。
ポッドは、グレースフルシャットダウン期間で設定されています。	ポッドにグレースフルシャットダウン期間 (`terminationGracePeriodSeconds`) が設定されている場合、`kubectl delete pod <pod_name>` などの終了コマンドを受信すると、ポッドは終了状態になります。 Kubernetesは、グレースフルシャットダウン期間 (`terminationGracePeriodSeconds`) が終了した後にポッドが終了するか、グレースフルシャットダウン期間が終了する前にポッド内のすべてのコンテナが終了すると見なします。	コンテナーが正常に終了すると、Kubernetesはポッドを削除します。
コンテナは応答しません。	ポッドを終了または削除するリクエストを開始すると、Kubernetesは`SIGTERM`シグナルをポッド内のコンテナーに送信します。コンテナが`SIGTERM`信号に応答しない場合、ポッドは終了状態のままになります。	`kubectl delete pod <pod-name> -- grace-period=0 -- force`コマンドを実行して、ポッドを強制的に削除します。ポッドをホストするノードのcontainerdまたはDockerログを確認し、原因を特定します。

立ち退きました

考えられる原因	説明	推奨ソリューション
ノードにメモリやディスク領域のリソースなどの十分なリソースがありません。その結果、kubeletはノード上の1つ以上のポッドを追い出し、リソースを再利用します。	ノードに十分なメモリ、ディスク容量、またはPIDがない場合があります。 `kubectl describe node <node name> \| grep Taints`コマンドを実行して、ノードテイントを照会します。メモリ不足: ノードに`node.kubernetes.io/memory-pressure`テイントがあります。ディスク容量が不足: ノードに`node.kubernetes.io/disk-pressure`テイントがあります。 pidが不十分: ノードに`node.kubernetes.io/pid-pressure`のテイントがあります。	メモリ不足: ポッドのリソース設定を調整します。詳細については、「ポッドの管理」をご参照ください。ノードをアップグレードします。詳細については、「ワーカーノードの設定のアップグレード」をご参照ください。ディスク容量不足: ノード上のアプリケーションポッドのログを定期的に削除します。ノードのディスクを展開します。詳細については、「手順1: ディスクのサイズを変更してディスクの容量を拡張する」をご参照ください。 PIDが不十分: ポッドのリソース設定を変更します。詳細については、「プロセスIDの制限と予約」をご参照ください。
予期しない立ち退きが発生します。	ポッドをホストするノードにNoExecute taintがあります。その結果、予期しない追い出しが起こる。	`kubectl describe node <node name> \| grep Taints`コマンドを実行し、ノードにNoExecuteテイントがあるかどうかを確認します。はいの場合、テイントを削除します。
ポッドは予想どおりに追い出されません。	`-- pod-eviction-timeout`: ポッドの削除タイムアウト期間。ノードのダウンタイムが指定されたタイムアウト期間を超えると、ポッドはノードから追い出されます。デフォルトのタイムアウト時間は5分です。 `-- node-eviction-rate`: 1秒あたりに追い出されるポッドの数。デフォルトは0.1です。つまり、10秒ごとにノードから少なくとも1つのポッドが削除されます。 `-- secondary-node-eviction-rate`: セカンダリポッドの削除率。過剰な数のノードがダウンしている場合、ポッドの削除はセカンダリレートに調整されます。デフォルト値は0.01です。 `-- unhealthy-zone-threshold`: 不健全なゾーンのしきい値。デフォルト値は0.55です。失敗したノードの数がノードの総数の55% を超えると、ゾーンは異常と見なされます。 `-- large-cluster-size-threshold`: 大きいクラスターのしきい値。デフォルト値は50です。クラスターノードの数が50を超えると、クラスターは大規模クラスターと見なされます。	50ノード以下の小さなクラスターでは、55% を超えるノードがダウンしている場合、ポッドの削除が停止されます。詳細については、「立ち退きのレート制限」をご参照ください。
ポッドは予想どおりに追い出されません。		50を超えるノードを含む大規模なクラスターでは、異常なノードとノードの合計の比率が `-- unhealthy-zone-threshold`の値を超える場合 (デフォルトは0.55) 、削除率は `-- secondary-node-eviction-rate`の値に設定されます。このパラメータは、1分あたりに追い出されるポッドの最大割合を指定します。デフォルト値は0.01です。詳細については、「立ち退きのレート制限」をご参照ください。
ポッドは、追い出された後も、元のノードに頻繁にスケジュールされます。	ポッドは、ノードのリソース使用量に基づいてノードから追い出される。ポッドスケジューリングルールは、ノードに割り当てられたリソースに依存します。追い出されたポッドは、元のノードに再びスケジュールされ得る。	ノードの割り当て可能なリソースに基づいて、ポッドのリソース要求が適切に構成されているかどうかを確認します。詳細については、「ポッドのCPUおよびメモリリソースの上限と下限の変更」をご参照ください。リソースプロファイリングを有効にして、コンテナーの推奨リソースリクエストとリソース制限を取得できます。

完了しました

ポッドが [完了] 状態になると、ポッド内のすべてのコンテナーが開始され、コンテナー内のすべてのプロセスが正常に終了します。完了状態は通常、JobコンテナとInitコンテナに適しています。

その他のよくある質問

ポッドは実行中の状態のままですが、通常どおり実行されません

ポッドYAMLファイルにエラーが含まれている場合、ポッドは実行状態のままである可能性がありますが、通常どおり実行されません。この問題に対処するには、次の手順を実行します。

ポッドの構成を検査し、ポッド内のコンテナが期待どおりに構成されているかどうかを確認します。
次の方法を使用して、環境変数のキーにスペルミスが含まれているかどうかを確認します。
環境変数のキーにスペルミスが含まれている場合 (たとえば、commandのスペルがcommndとなっている場合) 、クラスターはスペルミスを無視し、YAMLファイルに基づいてポッドを作成できます。ただし、コンテナーはYAMLファイルで指定されたコマンドを実行できません。
次の例では、commandをcommndと綴った場合にスペルミスを識別する方法を説明します。
1. kubectl apply -fコマンドの前に -- validateを追加し、kubectl apply -- validate -f XXX.yamlコマンドを実行します。
  スペルエラーが存在する場合、XXX] unknownフィールド: commnd XXX] これは誤ったアラームである可能性があります。https:// gXXXb.XXX/6842pods/testメッセージが表示されます。
2. 次のコマンドを実行して、チェックしたpod.yamlファイルをポッドの作成に使用したYAMLファイルと比較します。
  説明
  [$Pod] を異常ポッドの名前に置き換えます。 kubectl get podsコマンドを実行して名前を取得します。
```
  kubectl get pods [$Pod] -o yaml > pod.yaml
```
  - pod.yamlファイルに、ポッドの作成に使用された元のYAMLファイルよりも多くの行が含まれている場合は、ポッドが期待どおりに作成されます。
  - ポッドを作成するためのYAMLコマンドラインがpod.yamlファイルにない場合、元のYAMLファイルにスペルミスが含まれていることを意味します。
ポッドのログを確認し、ログデータに基づいて問題をトラブルシューティングします。
ターミナルを使用してポッドのコンテナにログインし、コンテナ内のローカルファイルを確認できます。

ポッドがデータベースにアクセスすると、ネットワーク切断の問題が発生することがあります

ACKクラスターのポッドがデータベースにアクセスしたときにネットワーク切断の問題が発生する場合は、次の操作を実行して問題のトラブルシューティングを行うことができます。

1. ポッドの確認

ポッドのイベントを表示し、ネットワーク例外、再起動、リソース不足に関連するイベントなど、不安定な接続イベントを確認します。
ポッドのログを表示し、接続タイムアウト、認証失敗、再接続などのデータベース接続エラーを確認します。
ポッドのCPUおよびメモリ使用率を表示します。リソース不足のため、アプリケーションまたはデータベースドライバーが例外的に終了しないようにしてください。
ポッドのリソース要求と制限を表示します。ポッドに十分なCPUおよびメモリリソースがあることを確認してください。

2. ノードの確認

ノードのリソース使用量を確認し、メモリやディスクリソースなどのリソースが十分であることを確認します。詳細については、「ノードの監視」をご参照ください。
ノードとデータベース間でネットワークの切断が時折発生するかどうかをテストします。

3. データベースの確認

データベースのステータスとパフォーマンスメトリックを確認して、再起動やパフォーマンスのボトルネックが存在しないことを確認します。
異常な接続の数を表示し、タイムアウト期間の設定を確認し、ビジネス要件に基づいて設定を変更します。
データベースからの切断に関連するデータベースログを分析します。

4。クラスタコンポーネントのステータスを確認する

クラスターコンポーネントの例外は、クラスター内のポッドと他のコンポーネント間の通信に影響します。次のコマンドを実行して、ACKクラスター内のコンポーネントのステータスを確認します。

kubectl get pod -n kube-system  # View the component status.

ネットワークコンポーネントを確認します。

CoreDNS: コンポーネントのステータスとログを確認します。ポッドがデータベースサービスのアドレスを解析できることを確認します。
フランネル: kube-Flannelのステータスとログを確認します。
Terway: terway-eniipのステータスとログを確認します。

5。ネットワークトラフィックの分析

tcpdumpを使用してパケットをキャプチャし、ネットワークトラフィックを分析して原因を特定できます。

次のコマンドを実行して、データベースの切断の問題が発生したポッドとノードを特定します。
```
kubectl  get pod -n [namespace] -o wide 
```
ノードにログインします。詳細については、「ECSインスタンスへの接続方法」をご参照ください。
次のコマンドを実行して、異なるKubernetesバージョンに基づいてコンテナーPIDを照会します。
containerd (1.22以降のKubernetesバージョン)
1. 次のコマンドを実行して、コンテナを表示します。
```
crictl ps |grep <Pod name keyword>
```
  期待される出力:
```
CONTAINER           IMAGE               CREATED             STATE                      
a1a214d2*****       35d28df4*****       2 days ago          Running
```
2. CONTAINER IDパラメーターを指定し、次のコマンドを実行してコンテナーPIDを表示します。
```
crictl inspect  a1a214d2***** |grep -i PID
```
  期待される出力:
```
"pid": 2309838, # The PID of the container. 
            "pid": 1
            "type": "pid"
```
Docker (Kubernetes 1.22以前)
1. 次のコマンドを実行して、コンテナIDを表示します。
```
docker ps | grep <Pod name or keyword>
```
  期待される出力:
```
CONTAINER ID        IMAGE                  COMMAND     
a1a214d2*****       35d28df4*****          "/nginx
```
2. CONTAINER IDパラメーターを指定し、次のコマンドを実行してコンテナーのPIDを表示します。
```
docker inspect  a1a214d2***** |grep -i PID
```
  期待される出力:
```
"Pid": 2309838, # The PID of the container. 
            "PidMode": "",
            "PidsLimit": null,
```
packet captureコマンドを実行します。
コンテナーPIDに基づいて次のコマンドを実行し、ポッドとデータベース間で送信されるパケットをキャプチャします。
```
nsenter -t <Container PID> tcpdump -i any -n -s 0 tcp and host <IP address of the database>
```
コンテナーPIDに基づいて次のコマンドを実行し、ポッドとホスト間で送信されるパケットをキャプチャします。
```
nsenter -t <Container PID> tcpdump -i any -n -s 0 tcp and host <IP address of the node>
```
次のコマンドを実行して、ホストとデータベース間で送信されるパケットをキャプチャします。
```
tcpdump -i any -n -s 0 tcp and host <IP address of the database>
```

6. アプリケーションの最適化

自動再接続メカニズムをサポートするようにアプリケーションを構成し、データベースの変更や移行時にアプリケーションが手動操作なしで接続を自動的に復元できるようにします。
データベースとの通信には、短期間の接続ではなく永続的な接続を使用します。パーシステント接続は、パフォーマンス損失およびリソース消費を大幅に低減し、システム全体の効率を高めることができる。

コンソールでのトラブルシューティング

ACKコンソールにログインし、クラスターの詳細ページに移動して、異常なポッドのトラブルシューティングを行います。

API 操作	レイアウトのコンソール
ポッドのステータスを確認する	[クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[ワークロード] > [ポッド] を選択します。 [ポッド] ページの左上隅で、ポッドが属する名前空間を選択し、ポッドのステータスを確認します。ポッドが [実行中] 状態の場合、ポッドは期待どおりに実行されます。ポッドが [実行中] 状態でない場合、ポッドは異常です。問題をトラブルシューティングするには、このトピックをお読みください。
ポッドの基本情報を確認する	[クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[ワークロード] > [ポッド] を選択します。 [ポッド] ページの左上隅で、ポッドが属する名前空間を選択します。ポッドのリストでポッドを見つけ、ポッドの名前をクリックするか、[操作] 列の [詳細の表示] をクリックして、ポッドに関する情報を表示します。ポッドとポッドをホストするノードの名前、イメージ、IPアドレスを表示できます。
ポッドの構成を確認する	[クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[ワークロード] > [ポッド] を選択します。 [ポッド] ページの左上隅で、ポッドが属する名前空間を選択します。ポッドのリストでポッドを見つけ、ポッドの名前をクリックするか、[操作] 列の [詳細の表示] をクリックします。ポッドの詳細ページの右上隅にある [編集] をクリックして、YAMLファイルとポッドの構成を表示します。
ポッドのイベントを確認する	[クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[ワークロード] > [ポッド] を選択します。 [ポッド] ページの左上隅で、ポッドが属する名前空間を選択します。ポッドのリストでポッドを見つけ、ポッドの名前をクリックするか、[操作] 列の [詳細の表示] をクリックします。ポッドの詳細ページの下部にある [イベント] タブをクリックして、ポッドのイベントを表示します。説明デフォルトでは、Kubernetesは過去1時間以内に発生したイベントを保持します。より長い期間内に発生したイベントを保持する場合は、「イベントセンターの作成と使用」をご参照ください。
ポッドのログを確認する	[クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[ワークロード] > [ポッド] を選択します。 [ポッド] ページの左上隅で、ポッドが属する名前空間を選択します。ポッドのリストでポッドを見つけ、ポッドの名前をクリックするか、[操作] 列の [詳細の表示] をクリックします。ポッドの詳細ページの下部にある [ログ] タブをクリックして、ポッドのログデータを表示します。説明 ACKクラスターはSimple Log Serviceとインターフェイスします。クラスターでSimple Log Serviceを有効にして、コンテナログをすばやく収集できます。詳細については、「DaemonSetモードでのKubernetesコンテナーからのテキストログの収集」をご参照ください。
ポッドのモニタリング情報を確認する	[クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[操作] > [Prometheusモニタリング] を選択します。 [Prometheusモニタリング] ページで、[クラスターの概要] タブをクリックして、ポッドに関する次のモニタリング情報 (CPU使用率、メモリ使用率、ネットワークI/O) を表示します。説明 ACKクラスターは、PrometheusのManaged Serviceとインターフェイスします。 ACKクラスターのManaged Service for Prometheusを有効にして、クラスターとクラスター内のコンテナーをリアルタイムで監視できます。 Managed Service for Prometheusを有効にすると、Grafanaダッシュボードに表示されるメトリックを表示できます。詳細については、「Prometheusのマネージドサービス」をご参照ください。
ターミナルを使用してポッドのコンテナにログオンし、コンテナ内のローカルファイルを表示する	[クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[ワークロード] > [ポッド] を選択します。 [ポッド] ページで、管理するポッドを見つけ、[操作] 列の [ターミナル] をクリックします。
ポッド診断の有効化	[クラスター] ページで、管理するクラスターの名前をクリックします。左側のウィンドウで、[ワークロード] > [ポッド] を選択します。 [ポッド] ページで、診断するポッドを見つけて、[操作] 列の [診断] をクリックします。説明 Container Intelligent Serviceはクラスター診断機能を提供し、ポッド、サービス、およびIngressをワンクリックで診断し、原因を特定するのに役立ちます。詳細については、「クラスター診断の操作」をご参照ください。