動かないPodの調べ方
動かないPodの原因は、STATUSの言葉と、kubectl describe、kubectl logs の出力から読み取れます。describe はKubernetesの側で何が起きたかを、logs はアプリが何と言ったかを教えてくれます。
同じ「動かない」でも、原因は3種類に分かれます。このレッスンでは、それぞれを本物の失敗で見ます。
このレッスンのゴール
メモ
describeとlogsを読んで、動かないPodの原因を言える。
重要な言葉
| ことば | いみ |
|---|---|
| STATUS | kubectl get pods が出す、Podの今の状態の言葉 |
| Pending | Podをまだ、どのノードにも置けていない状態 |
| ImagePullBackOff | イメージを取ってこられず、待っては試す状態 |
| CrashLoopBackOff | 始まってはすぐ終わるのを、繰り返している状態 |
| イベント | Kubernetesが出す、Podに起きたことの記録 |
| ログ | アプリが書いた、メッセージの記録 |
学生が入力するセルは、このプレビューでは空白です。
describeとlogsは、見る場所が違う
kubectl describe pod は、Podについての記録を並べます。いちばん下のイベントに、Kubernetesが何を試して、何で止まったかが出ます。
kubectl logs は、アプリが書いたメッセージを出します。アプリがまだ始まっていなければ、読むものがありません。
3つの原因と、見る場所
| STATUSの言葉 | 原因 | 見る場所 |
|---|---|---|
| ErrImagePull、ImagePullBackOff | イメージの名前が違う、取ってこられない | describe のイベント |
| Pending | 置ける場所がない（メモリの要求が大きすぎる） | describe のイベント |
| Error、CrashLoopBackOff | アプリが始まってすぐ終わる | logs |
学生が入力するセルは、このプレビューでは空白です。
イメージ名を間違えると取ってこられない
このラボのPodは、busybox:1.37.0 だけを使えます。わざと busybx と書いて、何が起きるかを見ましょう。
Podを作ってから、数秒待って get pods を打ちます。始めは ContainerCreating で、すぐ ErrImagePull に変わります。もう少しすると ImagePullBackOff になります。
名前空間を作る
kubectl create namespace cafeここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。
イメージ名が違うDeployment
kubectl create deployment typo --image=busybx:1.37.0 -n cafeここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。
数秒待ってから、Podを見る
kubectl get pods -n cafe -l app=typoここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。
イベントを読む
kubectl describe pod -n cafe -l app=typoここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。
logsには何もない
kubectl logs deployment/typo -n cafeここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。
置く場所がないPodはPendingのまま
Pendingは、Podをどのノードにも置けていない状態です。たとえば、ノードにない大きなメモリを要求したときです。
ここでは、動いているDeploymentの要求を、64Giに書き換えます。新しいPodはPendingのままですが、古いPodは、新しいPodが動くまで止められずに残ります。
まず普通のDeployment
kubectl create deployment big --image=busybox:1.37.0 -n cafe -- sleep 3600ここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。
メモリの要求を64Giにする
kubectl set resources deployment big -n cafe --requests=memory=64Giここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。
数秒待ってから、Podを見る
kubectl get pods -n cafe -l app=bigここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。
置けない理由を読む
kubectl get events -n cafe --field-selector reason=FailedSchedulingここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。
CrashLoopBackOffは始め直しの印
イメージも置き場所も正しいのに、アプリが始まってすぐ終わることがあります。Kubernetesは、終わったアプリを何度も始め直します。
回数が増えると、待つ時間も長くなります。この状態がCrashLoopBackOffです。理由は、アプリが書いたログにあります。
すぐ終わるDeployment
kubectl create deployment crashy --image=busybox:1.37.0 -n cafe -- sh -c "echo missing the setting; exit 1"ここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。
数秒待ってから、Podを見る
kubectl get pods -n cafe -l app=crashyここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。
アプリのメッセージを読む
kubectl logs deployment/crashy -n cafeここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。
よくある間違い
注意
どのPodの故障も、logs を見れば分かると思いがちです。logs が答えるのは、アプリが始まったあとだけです。イメージを取れないPodや、置けないPodには、アプリのメッセージがありません。まず describe のイベントを読みます。
名前空間を片づける
kubectl delete namespace cafeここでは表示のみで、実行されません。無料アカウントを作成すると、実行ボタンで自分のラボのターミナルに入力できます。