Black lives matter.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
このページでは、PodとReplicationControllerをデバッグする方法を説明します。
Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 まだクラスターがない場合、Minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:
バージョンを確認するには次のコマンドを実行してください:kubectl version
.
Podのデバッグの最初のステップは、Podを調べることです。 次のコマンドで、Podの現在の状態と最近のイベントを確認して下さい。
kubectl describe pods ${POD_NAME}
Pod内のコンテナの状態を確認します。
コンテナはすべてRunning
状態ですか?最近再起動はしましたか?
Podの状態に応じてデバッグを続けます。
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つのチームがすべてのリソースを占有することを防ぐことができます。
PodをhostPort
にバインドすると、Podをスケジュールできる場所の数が制限されます。
ほとんどの場合、hostPort
は不要です。Serviceオブジェクトを使用してPodを公開してください。
どうしてもhostPort
が必要な場合は、コンテナクラスター内のノードと同じ数のPodのみをスケジュールできます。
PodがWaiting
状態でスタックしている場合、Podはワーカーノードにスケジュールされていますが、そのマシンでは実行できない状態です。
この場合も、kubectl describe ...
の情報が参考になるはずです。
PodがWaiting
状態となる最も一般的な原因は、イメージをプルできないことです。
確認すべき事項が3つあります。
docker pull <image>
を実行し、イメージをプルできるかどうかを確認して下さい。最初に、現在のコンテナのログを確認して下さい。
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はかなり明快です。Podを作成できるか、できないかのどちらかです。 Podを作成できない場合は、上述の手順を参照してPodをデバッグしてください。
kubectl describe rc ${CONTROLLER_NAME}
を使用して、レプリケーションコントローラーに関連するイベントを調べることもできます。