サービスの問題のトラブルシューティング
サービスを実行しようとすると、デプロイメントポートやロードバランサーの問題など、デプロイメントの問題に起因するエラーメッセージが返されることがあります。
デプロイメントの準備ができていない
デプロイメントの準備ができていないか、またはインストールを完了してサービスを実行しようとしたときにデプロイメントでエラーが発生することがあります。
原因
この問題の原因はいくつか考えられます。
診断
この問題を診断する手順は、次のとおりです。
-
デプロイメントの状況を確認します。
$ kubectl -n namespace get deployments準備完了を示す列に M/N (M < N) と示されます。
-
影響を受けているポッドの状況を確認します。
$ kubectl -n namespace get pods
解決策
この問題を解決する手順は、次のとおりです。
-
診断結果に応じて次のいずれかのアクションを実行します。
-
ErrImagePull または ImagePullBackOffイメージを取り込めません。デプロイメント仕様またはポッドのイメージ値が有効なリポジトリまたはイメージ名を参照していることを確認します。
-
Pendingポッドに必要なリソースが割り当てられていることを確認します。デプロイメントを編集して CPU とメモリの要求量を減らすか、またはクラスターを拡張してください。
-
CrashLoopBackOffポッドの状態の確認を要求して、エラーの詳細を入手します。
$ kubectl -n namespace describe pod pod-name
-
-
description コマンドからの出力のイベントセクションで、デプロイメントの状況 (live または ready) を示すログがないか確認します。
-
デプロイメントの存在と準備完了のプローブが正しく設定されていて、アプリケーションの既存エンドポイントと一致することを確認します。
-
初期遅延または期間を延長し、ポッドで応答とログを手動で確認します。
$ kubectl -n namespace logs pod-name
-
イメージポートがデプロイメントポートと一致しない
原因
特定のポートに対する要求がエラーとなる原因はいくつか考えられます。
診断
問題を診断するには、次のコマンドを実行します。
$ kubectl -n namespace get deployments
準備完了を示す列に M/N (100% ready) と示されます。ただし、宣言されたポートに対する要求が、アプリケーションとは無関係な理由 (「upstream connect error (上流接続エラー) や「disconnect or reset before headers (ヘッダー前の切断またはリセット)」など) で失敗します。
解決策
この問題を解決する手順は、次のとおりです。
-
要求がデプロイメントポートのいずれかを対象としていることを確認します。
-
デプロイメントポートがイメージの Dockerfile で公開されていることを確認します。
サービスがロードバランサーとして公開されない
外部からサービスにアクセスできるようにするには、作成するときにサービスを公開する
必要があります。
サービスを公開することで、外部からアクセスできる IP アドレスが用意され、この IP アドレスを使用してクラスターノードの正しいポートにトラフィックを送信することができます。ただし、クラスターがサポート対象の環境で動作していて、正しいクラウドロードバランサープロバイダーパッケージで設定されている必要があります。
サービスの公開に失敗すると、サービスの IP アドレスに対するすべての要求は無応答状態となります。
原因
この問題は、サービスをロードバランサーとして公開しなかった場合に発生します。
診断
サービスの問題を診断します。
$ kubectl -n namespace get service
結果の Type 列には「LoadBalancer」、External-IP 列には「<none>」と表示されます。
解決策
この問題を解決するには、サービス仕様を確認します。サービスを公開して使用できるようにするには、サービス仕様をロードバランサーとして設定する必要があります。
サービスを公開しない場合は、エンドポイントをクラスター内から使用するか、または次のコマンドでクラスター外からエンドポイントにアクセスする必要があります。
$ kubectl port-forward or kubectl proxy