PodとReplicationControllerのデバッグ
このページでは、PodとReplicationControllerをデバッグする方法を説明します。
始める前に
Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 まだクラスターがない場合、Minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:
バージョンを確認するには次のコマンドを実行してください: kubectl version
.
- PodとPodのライフサイクルの基本を理解している必要があります。
Podのデバッグ
Podのデバッグの最初のステップは、Podを調べることです。 次のコマンドで、Podの現在の状態と最近のイベントを確認して下さい。
kubectl describe pods ${POD_NAME}
Pod内のコンテナの状態を確認します。
コンテナはすべてRunning
状態ですか?最近再起動はしましたか?
Podの状態に応じてデバッグを続けます。
PodがPending状態にとどまっている
PodがPending
状態でスタックしている場合、ノードにスケジュールできていないことを意味します。
一般的に、これは、何らかのタイプのリソースが不足しており、それによってスケジューリングを妨げられているためです。
上述のkubectl describe...
コマンドの出力を確認してください。
Podをスケジュールできない理由に関するスケジューラーからのメッセージがあるはずです。
理由としては以下のようなものがあります。
リソースが不十分
クラスター内のCPUまたはメモリーの供給を使い果たした可能性があります。 この場合、いくつかのことを試すことができます。
クラスターにノードを追加します。
不要なPodを終了して、
Pending
状態のPodのための空きリソースを作ります。Podがノードよりも大きくないことを確認します。 例えば、すべてのノードのキャパシティーが
cpu: 1
の場合、cpu: 1.1
を要求するPodは決してスケジュールされません。kubectl get nodes -o <format>
コマンドでノードのキャパシティーを確認できます。 必要な情報を抽出するコマンドラインの例を以下に示します。kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:' kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
リソースクォータ機能では、 消費できるリソースの合計量を制限するように構成できます。 Namespaceと組み合わせて使用すると、1つのチームがすべてのリソースを占有することを防ぐことができます。
hostPortの使用
PodをhostPort
にバインドすると、Podをスケジュールできる場所の数が制限されます。
ほとんどの場合、hostPort
は不要です。Serviceオブジェクトを使用してPodを公開してください。
どうしてもhostPort
が必要な場合は、コンテナクラスター内のノードと同じ数のPodのみをスケジュールできます。
PodがWaiting状態にとどまっている
PodがWaiting
状態でスタックしている場合、Podはワーカーノードにスケジュールされていますが、そのマシンでは実行できない状態です。
この場合も、kubectl describe ...
の情報が参考になるはずです。
PodがWaiting
状態となる最も一般的な原因は、イメージをプルできないことです。
確認すべき事項が3つあります。
- イメージの名前が正しいことを確認して下さい。
- イメージはリポジトリーにプッシュしましたか?
- マシンで手動で
docker pull <image>
を実行し、イメージをプルできるかどうかを確認して下さい。
Podがクラッシュする、あるいはUnhealthy状態
最初に、現在のコンテナのログを確認して下さい。
kubectl logs ${POD_NAME} ${CONTAINER_NAME}
以前にコンテナがクラッシュした場合、次のコマンドで以前のコンテナのクラッシュログにアクセスできます。
kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
別の方法として、exec
を使用してそのコンテナ内でコマンドを実行できます。
kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
備考:-c ${CONTAINER_NAME}
はオプションです。単一のコンテナのみを含むPodの場合は省略できます。
例えば、実行中のCassandra Podのログを確認するには、次のコマンドを実行します。
kubectl exec cassandra -- cat /var/log/cassandra/system.log
これらのアプローチがいずれも機能しない場合、Podが実行されているホストマシンを見つけて、そのホストにSSH接続することができます。
ReplicationControllerのデバッグ
ReplicationControllerはかなり明快です。Podを作成できるか、できないかのどちらかです。 Podを作成できない場合は、上述の手順を参照してPodをデバッグしてください。
kubectl describe rc ${CONTROLLER_NAME}
を使用して、レプリケーションコントローラーに関連するイベントを調べることもできます。
フィードバック
このページは役に立ちましたか?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to 問題を報告する or 改善を提案.