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}を使用して、レプリケーションコントローラーに関連するイベントを調べることもできます。