現在表示しているのは、次のバージョン向けのドキュメントです。Kubernetesバージョン: v1.21
Kubernetes v1.21 のドキュメントは積極的にメンテナンスされていません。現在表示されているバージョンはスナップショットです。最新のドキュメントはこちらです: 最新バージョン
PodとReplicationControllerのデバッグ
このページでは、PodとReplicationControllerをデバッグする方法を説明します。
始める前に
Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、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状態
Podがスケジュールされると、動作中のPodをデバッグするに説明されている方法がデバッグに使用可能です。
ReplicationControllerのデバッグ
ReplicationControllerはかなり明快です。Podを作成できるか、できないかのどちらかです。 Podを作成できない場合は、上述の手順を参照してPodをデバッグしてください。
kubectl describe rc ${CONTROLLER_NAME}
を使用して、レプリケーションコントローラーに関連するイベントを調べることもできます。