Wang
8.8 KiB
reviewers, title, content_type
| reviewers | title | content_type | |
|---|---|---|---|
|
アプリケーションのトラブルシューティング | concept |
このガイドは、Kubernetesにデプロイされ、正しく動作しないアプリケーションをユーザーがデバッグするためのものです。 これは、自分のクラスターをデバッグしたい人のためのガイドでは ありません。 そのためには、debug-clusterを確認する必要があります。
問題の診断
トラブルシューティングの最初のステップは切り分けです。何が問題なのでしょうか？ Podなのか、レプリケーションコントローラなのか、それともサービスなのか？
Podのデバッグ
デバッグの第一歩は、Podを見てみることです。 以下のコマンドで、Podの現在の状態や最近のイベントを確認します。
kubectl describe pods ${POD_NAME}
Pod内のコンテナの状態を見てください。
すべてRunningですか？ 最近、再起動がありましたか？
Podの状態に応じてデバッグを続けます。
PodがPendingのまま
PodがPending で止まっている場合、それはノードにスケジュールできないことを意味します。
一般に、これはある種のリソースが不十分で、スケジューリングできないことが原因です。
上のkubectl describe ...コマンドの出力を見てください。
なぜあなたのPodをスケジュールできないのか、スケジューラーからのメッセージがあるはずです。 理由は以下の通りです。
-
リソースが不足しています。 クラスタのCPUまたはメモリーを使い果たした可能性があります。Podを削除するか、リソース要求を調整するか、クラスタに新しいノードを追加する必要があります。詳しくはCompute Resources documentを参照してください。
-
**あなたが使用しているのは
hostPort**です。PodをhostPortにバインドすると、そのPodがスケジュールできる場所が限定されます。ほとんどの場合、hostPortは不要なので、Serviceオブジェクトを使ってPodを公開するようにしてください。もしhostPortが必要な場合は、Kubernetes クラスタのノード数だけ Pod をスケジュールすることができます。
Podがwaitingのまま
Podが Waiting 状態で止まっている場合、ワーカーノードにスケジュールされていますが、そのマシン上で実行することはできません。この場合も、kubectl describe ... の情報が参考になるはずです。Waiting状態のポッドの最も一般的な原因は、イメージの取り出しに失敗することです。
確認すべきことは3つあります。
- イメージの名前が正しいかどうか確認してください。
- イメージをリポジトリにプッシュしましたか？
- あなたのマシンで手動で
docker pull <image>を実行し、イメージをプルできるかどうか確認してください。
Podがクラッシュするなどの不健全な状態
Podがスケジュールされると、Debug Running Podsで説明されているメソッドがデバッグに利用できるようになります。
Podが期待する通りに動きません
Podが期待した動作をしない場合、ポッドの記述（ローカルマシンの mypod.yaml ファイルなど）に誤りがあり、ポッド作成時にその誤りが黙って無視された可能性があります。Pod記述のセクションのネストが正しくないか、キー名が間違って入力されていることがよくあり、そのため、そのキーは無視されます。たとえば、commandのスペルをcommndと間違えた場合、Podは作成されますが、あなたが意図したコマンドラインは使用されません。
まず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
次に確認することは、apiserver上のPodが、作成しようとしたPod（例えば、ローカルマシンのyamlファイル）と一致しているかどうかです。
例えば、kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml を実行して、元のポッドの説明であるmypod.yamlとapiserverから戻ってきたmypod-on-apiserver.yamlを手動で比較してみてください。
通常、"apiserver" バージョンには、元のバージョンにはない行がいくつかあります。これは予想されることです。
しかし、もし元のバージョンにある行がapiserverバージョンにない場合、これはあなたのPod specに問題があることを示している可能性があります。
レプリケーションコントローラのデバッグ
レプリケーションコントローラはかなり単純なものです。
彼らはPodを作ることができるか、できないか、どちらかです。
もしPodを作成できないのであれば、instructions aboveを参照して、Podをデバッグしてください。
また、kubectl describe rc ${CONTROLLER_NAME}を使用すると、レプリケーションコントローラに関連するイベントをイントロスペクトすることができます。
サービスのデバッグ
サービスは、ポッドのセット全体でロードバランシングを提供します。 サービスが正しく動作しない原因には、いくつかの一般的な問題があります。
以下の手順は、サービスの問題をデバッグするのに役立つはずです。
まず、サービスのエンドポイントが存在することを確認します。
全てのサービスオブジェクトに対して、apiserverは endpoints リソースを利用できるようにします。
このリソースは次のようにして見ることができます。
kubectl get endpoints ${SERVICE_NAME}
エンドポイントがサービスのメンバーとして想定されるPod数と一致していることを確認してください。 例えば、3つのレプリカを持つnginxコンテナ用のサービスであれば、サービスのエンドポイントには3つの異なるIPアドレスが表示されるはずです。
サービスにエンドポイントがありません
エンドポイントが見つからない場合は、サービスが使用しているラベルを使用してポッドをリストアップしてみてください。 ラベルがあるところにServiceがあると想像してください。
...
spec:
- selector:
name: nginx
type: frontend
セレクタに一致するPodを一覧表示するには、次のコマンドを使用します。
kubectl get pods --selector=name=nginx,type=frontend
リストがサービスを提供する予定のPodと一致することを確認します。
PodのcontainerPortがサービスのtargetPortと一致することを確認します。
ネットワークトラフィックが転送されません
詳しくはdebugging serviceを参照してください。
{{% heading "whatsnext" %}}
上記のいずれの方法でも問題が解決しない場合は、以下の手順に従ってください。
Debugging Service documentで、Service が実行されていること、Endpointsがあること、Podsが実際にサービスを提供していること、DNS が機能していること、IPtables ルールがインストールされていること、kube-proxyが誤作動を起こしていないようなことを確認してください。
トラブルシューティングドキュメント](/docs/tasks/debug-application-cluster/troubleshooting/)に詳細が記載されています。