Skip to Content

Kubernetes 入門 #2 ハンズオン補足

概要

Kubernetes 入門 #2 を実際に進める。
詰まったところや、わからなかったことをまとめる。

アプリケーションを動かす!

STEP.2

EXTERNAL-IPを確認
34.74.200.22 の部分

> kubectl get svc
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)           AGE
greet        LoadBalancer   10.23.246.22   34.74.200.22   30000:32658/TCP   7m58s
kubernetes   ClusterIP      10.23.240.1    <none>         443/TCP           25h

IPが振られる前だと”pending”表示だった。
少し時間をおいてから確認する必要がある。

kubectl get svc
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)           AGE
greet        LoadBalancer   10.23.246.22   <pending>     30000:32658/TCP   30s
kubernetes   ClusterIP      10.23.240.1    <none>        443/TCP           25h

STEP.5

コンテナとストレージの関係性をちょっと見てみましょう。

1個目のコマンドが通らない
そして、よくわからない

> kubectl exec -it greet-d5c8fc9dd-j2wjz -c greet -- /bin/sh

OCI runtime exec failed: exec failed: container_linux.go:345: starting container process caused "exec: \"/bin/sh\": stat /bin/sh: no such file or directory": unknown
command terminated with exit code 126

> kubectl exec -it greet-d5c8fc9dd-j2wjz -c dummy -- ls -l /share/
total 20
-rw-r--r--    1 root     root            18 Jun  2 01:47 app.log
drwx------    2 root     root         16384 Jun  2 01:16 lost+found

アプリケーションを変更する!

STEP.7

describeでeventを確認しましょう。

describeで必要なPodの名前を確認方法
greet-744c887865-nx9lm の部分

> kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
greet-744c887865-nx9lm   1/2     Running   0          25s
greet-7bc485bfc5-j429p   2/2     Running   0          5m10s
greet-7bc485bfc5-vtx2m   2/2     Running   0          5m5s

> kubectl describe pod greet-744c887865-nx9lm

STEP.8

readinessProbeではなく、livenessProbeのパスを変更してみましょう。

  • readinessProbeを元の/healthに戻す
  • livenessProbeを/readに変更
> vi Step1-ApplicationDeployment/deployments/020-deployments.yaml 

“kubectl get pod -w”の結果(ログ)が荒ぶっているけど、これで良いのか…

greet-7bc485bfc5-j429p   0/2     Terminating         0          10m
greet-66b6b94c97-gn85k   1/2     Running             1          42s
greet-66b6b94c97-gn85k   2/2     Running             1          45s
greet-66b6b94c97-wdv84   1/2     Running             1          37s
greet-66b6b94c97-wdv84   2/2     Running             1          39s
greet-66b6b94c97-gn85k   1/2     Running             2          68s
greet-66b6b94c97-gn85k   2/2     Running             2          70s
greet-66b6b94c97-wdv84   1/2     Running             2          67s
greet-66b6b94c97-wdv84   2/2     Running             2          69s
greet-66b6b94c97-gn85k   1/2     Running             3          93s
greet-66b6b94c97-gn85k   2/2     Running             3          95s
greet-66b6b94c97-wdv84   1/2     Running             3          96s
greet-66b6b94c97-wdv84   2/2     Running             3          99s
greet-66b6b94c97-gn85k   1/2     Running             4          118s
greet-66b6b94c97-gn85k   2/2     Running             4          2m
greet-66b6b94c97-wdv84   1/2     Running             4          2m6s
greet-66b6b94c97-gn85k   1/2     CrashLoopBackOff    4          2m22s
greet-66b6b94c97-wdv84   2/2     Running             4          2m9s
greet-66b6b94c97-wdv84   1/2     CrashLoopBackOff    4          2m36s
greet-66b6b94c97-gn85k   1/2     Running             5          3m4s
greet-66b6b94c97-gn85k   2/2     Running             5          3m5s
greet-66b6b94c97-gn85k   1/2     CrashLoopBackOff    5          3m33s
greet-66b6b94c97-wdv84   1/2     Running             5          3m21s
greet-66b6b94c97-wdv84   2/2     Running             5          3m24s
greet-66b6b94c97-wdv84   1/2     CrashLoopBackOff    5          3m46s
CrashLoopBackOff を調べる

原因
コンテナ内のプロセスの終了を検知してコンテナの再起動を繰り返している。

解決
コンテナで終了するプロセスを動かしていないだろうか?
コンテナが正常に稼動しているかはプロセスが落ちていないかで判断するので、
プロセスが正常終了した場合であっても「あっプロセスが落ちてる」となって再起動される。
そのようなコンテナは再起動したところで再びプロセスが正常終了するだろう。
つまり、無限に起動し続けるということになる。

確かに落ちては上がっていう動きをしている。
この状態を作るための設定変更だったのだろう。

参考
https://qiita.com/minodisk/items/547741b73763f2bab6b8

“LivenessProbe”, “ReadinessProbe”とは?

Kubernetesのヘルスチェック方法

LivenessProbe

LivenessProbeはコンテナが生存しているかをチェックする。
例えばアプリケーションが応答できなくなった際などを想定している。
このLivenessProbeが通らなくなった場合、コンテナは再作成される。

STEP.8
落ちては上がってという動きはこの働きだった。

ReadinessProbe

ReadinessProbeはコンテナが準備できている(Ready)状態になっているかチェックする。
例えば初期のロード処理や重いリクエストの処理中で別のリクエストが返せない場合などを想定している。
このReadinessProbeが通らなくなった場合、Serviceからのルーティングの対象から外される。

STEP.7
kuberctl get pod -w の READYが 1/2だったのはこの働きだった。

参考
説明の図が大変わかり易い
https://cstoku.dev/posts/2018/k8sdojo-10/