NamikoToriyama
99 lines
4.7 KiB
Markdown
99 lines
4.7 KiB
Markdown
---
|
|
title: PodとReplicationControllerのデバッグ
|
|
content_type: task
|
|
---
|
|
|
|
<!-- overview -->
|
|
|
|
このページでは、PodとReplicationControllerをデバッグする方法を説明します。
|
|
|
|
|
|
|
|
## {{% heading "prerequisites" %}}
|
|
|
|
|
|
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
|
|
|
* [Pod](/ja/docs/concepts/workloads/pods/pod/)と[Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)の基本を理解している必要があります。
|
|
|
|
|
|
|
|
<!-- steps -->
|
|
|
|
## Podのデバッグ
|
|
|
|
Podのデバッグの最初のステップは、Podを調べることです。
|
|
次のコマンドで、Podの現在の状態と最近のイベントを確認して下さい。
|
|
|
|
```shell
|
|
kubectl describe pods ${POD_NAME}
|
|
```
|
|
|
|
Pod内のコンテナの状態を確認します。
|
|
コンテナはすべて`Running`状態ですか？最近再起動はしましたか？
|
|
|
|
Podの状態に応じてデバッグを続けます。
|
|
|
|
### PodがPending状態にとどまっている
|
|
|
|
Podが`Pending`状態でスタックしている場合、ノードにスケジュールできていないことを意味します。
|
|
一般的に、これは、何らかのタイプのリソースが不足しており、それによってスケジューリングを妨げられているためです。
|
|
上述の`kubectl describe...`コマンドの出力を確認してください。
|
|
Podをスケジュールできない理由に関するスケジューラーからのメッセージがあるはずです。
|
|
理由としては以下のようなものがあります。
|
|
|
|
#### リソースが不十分
|
|
|
|
クラスター内のCPUまたはメモリーの供給を使い果たした可能性があります。
|
|
この場合、いくつかのことを試すことができます。
|
|
|
|
* クラスターにノードを追加します。
|
|
|
|
* [不要なPodを終了](/docs/concepts/workloads/pods/#pod-termination)して、
|
|
`Pending`状態のPodのための空きリソースを作ります。
|
|
|
|
* Podがノードよりも大きくないことを確認します。
|
|
例えば、すべてのノードのキャパシティーが`cpu: 1`の場合、`cpu: 1.1`を要求するPodは決してスケジュールされません。
|
|
|
|
`kubectl get nodes -o <format>`コマンドでノードのキャパシティーを確認できます。
|
|
必要な情報を抽出するコマンドラインの例を以下に示します。
|
|
|
|
```shell
|
|
kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:'
|
|
kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'
|
|
```
|
|
|
|
[リソースクォータ](/docs/concepts/policy/resource-quotas/)機能では、
|
|
消費できるリソースの合計量を制限するように構成できます。
|
|
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をデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/)に説明されている方法がデバッグに使用可能です。
|
|
|
|
## ReplicationControllerのデバッグ
|
|
|
|
ReplicationControllerはかなり明快です。Podを作成できるか、できないかのどちらかです。
|
|
Podを作成できない場合は、[上述の手順](#Podのデバッグ)を参照してPodをデバッグしてください。
|
|
|
|
`kubectl describe rc ${CONTROLLER_NAME}`を使用して、レプリケーションコントローラーに関連するイベントを調べることもできます。
|
|
|
|
|