1. デバッグポッド
ポッドをデバッグする最初のステップは、ポッド情報を表示することです。次のコマンドを使用して、ポッドの現在のステータスと最近のイベントを表示します。
kubectl describe pods ${POD_NAME}
ポッド内のコンテナの状態を見てください。これらのコンテナのステータスはすべて同じですか Running ? 最近再起動しましたか?
その後のデバッグは、Pod のステータスに応じて行われます。
ポッドが保留状態でスタックする
ポッドがスタック状態になっている場合は Pending 、そのポッドがノード上でスケジュールされていないことを意味します。通常、これは、スケジューリングを妨げる何らかのリソースの不足が原因です。上記のコマンドの出力を見ると kubectl describe ... 、スケジュールされなかった理由が示されているはずです。一般的な理由は次のとおりです。
-
リソースが不十分です: クラスター上のすべての CPU またはメモリが使い果たされている可能性があります。この時点で、ポッドを削除するか、リソース要求を調整するか、クラスターにノードを追加する必要があります。
-
Used
hostPort: Pod が にバインドされている場合hostPort、Pod を実行できるノードは制限されます。ほとんどの場合、hostPortこれは必要ありませんが、Pod を公開するには Service オブジェクトを使用する必要があります。本当に使用する必要がある場合はhostPort、クラスター内のノードの数が、作成できる Pod の数の上限になります。
ポッドが待機状態でスタックする
ポッドがスタック Waiting 状態になっている場合は、ポッドがワーカー ノードにスケジュールされているものの、そのノードでは実行できないことを意味します。また、kubectl describe ... コマンドの出力も役立つ場合があります。 Waiting このステータスの最も一般的な理由は、イメージのプルが失敗したことです。チェックする領域は 3 つあります。
- イメージ名のスペルが正しいことを確認してください。
- イメージがレジストリにプッシュされていることを確認してください。
- 手動でイメージを取得できるかどうかを試してください。たとえば、PC で Docker を使用している場合は、 を実行します
docker pull <镜像>。
ポッドがクラッシュしているか、異常です
ポッドがスケジュールされると、「実行中のポッドのデバッグ」で説明されているように、さらにデバッグできます。
ポッドは実行状態ですが、正しく動作していません
mypod.yamlポッドが期待どおりに動作しない場合は、ポッドの説明 (ローカル マシンなど) に問題があり、ポッドの作成時にエラーが報告されずにエラーが無視された可能性があります。 通常、Pod 定義内のセクション領域の入れ子関係が間違っており、フィールド名のスペルミスにより、対応する内容が無視されます。たとえば、誤って と command 記述し た場合commnd、Pod は作成されますが、実行されると予想されるコマンド ラインは実行されません。
最初にできることは、ポッドを削除し、 --validate オプションを使用して再作成を試みることです。たとえば、 を実行します kubectl apply --validate -f mypod.yaml。command スペルが間違っている 場合は commnd、次のエラー メッセージが表示されます。
I0805 10:43:25.129850 46757 schema.go:126] unknown field: commnd
I0805 10:43:25.129973 46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842
pods/mypod
次に確認する必要があるのは、API サーバー上のポッドが、作成する予定のものと一致しているかどうかです (たとえば、最初にローカル マシン上の YAML ファイルを使用してポッドを作成したなど)。たとえば、 を実行した後 kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml、 mypod.yaml API サーバーから取得したポッドの説明と手動で比較します。API サーバーから取得した YAML に、ポッドの作成に使用された YAML に存在しない行が含まれていることは通常のことです。ただし、ソースファイルの一部の行が API サーバー版に存在しない場合は、Pod の仕様に問題があることを意味します。
レプリカ コントローラーのデバッグ
レプリカ コントローラーは比較的シンプルで簡単です。ポッドを作成できるか、作成できないかのどちらかです。ポッドを作成できない場合は、上記の手順を参照してポッドをデバッグしてください。
kubectl describe rc ${CONTROLLER_NAME} コマンドを使用して、レプリカ コントローラーに関連するイベントを表示することもできます 。
デバッグサービス
サービスは、複数のポッドにわたる負荷分散をサポートします。サービスの適切な動作を妨げる可能性のある一般的な問題がいくつかあります。次の手順は、サービスに関する問題のデバッグに役立ちます。
まず、サービスにエンドポイントがあることを確認します。各 Service オブジェクトに対して、API サーバーは対応する endpoints リソースを提供します。
エンドポイント リソースは、次のコマンドで表示できます。
kubectl get endpoints ${SERVICE_NAME}
エンドポイントの数がサービス メンバーのポッドの数と一致していることを確認してください。たとえば、サービスが nginx コンテナの 3 つのレプリカを実行するために使用されている場合、サービスのエンドポイントに 3 つの異なる IP アドレスが表示されるはずです。
サービスにエンドポイントがありません
エンドポイントがない場合は、サービスで使用されるラベルを持つポッドをリストしてみてください。サービスに次のタグ セレクターが含まれているとします。
...
spec:
- selector:
name: nginx
type: frontend
次のコマンドを使用して、セレクターに一致するポッドをリストし、それらが作成されたサービスに属していることを確認できます。
kubectl get pods --selector=name=nginx,type=frontend
ポッドが containerPort サービスの と targetPort 一致することを確認します。