Kubernetes中級(1)：Pod-Lifecycle

##Life cycle features
<img width="1253" alt="スクリーンショット 2020-07-17 13.54.51.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/519254/4223c0d6-723e-6f4a-0748-c468d687e88b.png">
Podも人間のようにLife Cycleがある。
Life Cycleは各ステップで行える行動が違う特徴がある。
Podも、そのステップに基づいて主要行動があり、ReadinessProbeやLivenessProbe、Qos、Policyなどいくつかの機能がPodの特定のステップと密接な関係があるのでLife cycleについてよく知っておく必要がある。

##Status Struct
<img width="1344" alt="スクリーンショット 2020-07-17 13.55.27.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/519254/0eeabfaa-7fb8-6221-2f09-5d10c4f38cd6.png">
Podを作成した後、作成内容を見るとStatusがある。
Statusは以下の情報(属性)がある。
・Phase：Podの全体の状態を表す
・Conditions：Podが生成され、実行されるステップがあるが、そのステップと状態を表す
・State(Container Statuses)：Podの中にはContainerがあり、ContainerごとStateがあって、Containerの状態を表す

**Phase**
まず、Podを代表するPhaseは「Pending、Running、Succeeded、Failed、Unknown」5つの状態がある。
上の図はPending状態である(phase：Pending) 

**Conditions**
Conditionsは4つの種類があり(上の図のconditionsのtype)、ReasonというConditionsの詳細を示す項目もある。
statusはTrue/Falseがあり、Falseの場合はreasonに原因が記載される。
上の図の「reason:ContainersNotReady」はContainer作業がまだ進行中であることがわかる。

**Containers**
Containerの状態を見ると、Stateとして「Wating、Running、Terminated」3つの状態がある。
Conditionsのようにreasonもある。
上の図のstate：watingは、Containerを作成しているからwatingになっている。
原因はImageIDの値がないことを見ればまだImageがDownloadされてないからwatingになっていると考えられる。
##Pod Lifecycle Overview
<img width="1344" alt="スクリーンショット 2020-07-17 13.56.10.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/519254/b114c3a9-5eab-3fa0-991a-5f3b12361c19.png">

Podのメイン状態を表すのはPhaseだが、この状態がどのように変化し、その変化に応じてPodのContainer動作がどうなるのか見てみよう。
**【initialized】**
<img width="666" alt="20200721_134801.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/519254/da02c15f-89ba-2396-d77e-576d3c438b15.png">
上の図のinitContainerというのは本Containerが起動される前に初期値を設定するContainerである。
VolumeやSecurity設定のために事前に設定が必要な場合はPodの作成内容の中にinitContainersという項目で初期化Scriptを設定することができる。
このScriptは本Containerよりも先に実行されて、作業が正常に完了した場合とそもそもScriptを設定しなかった場合は「initialized：True」になるが、失敗すると「initialized：False」になる。

**【PodScheduled】**
<img width="602" alt="2.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/519254/f80e4dd6-fb2c-b08a-a74b-69f18d276059.png">
PodがNodeに設定されると「PodScheduled：True」になる。

**【Image Download】**
<img width="611" alt="3.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/519254/3352167c-edab-e8af-e75d-f299aaaf3786.png">
ContainerにImageをDownloadする。
上記で説明した2つ(initialized, PodScheduled)のProcessが動いている間にはContainerの状態はwatingになり、
reasonはContainerCreatingになる。

**【Restart】**
<img width="607" alt="5.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/519254/a00ddb27-3d16-45aa-9071-52abc1f76844.png">
そして本格的にContainerが起動されると、PodとContainerの状態はRunningになる。
通常は正常に起動するが、1つでもContainerが起動中に問題が発生すると全てがRestartになることもある。
その場合のContainerの状態はWatingになり、reasonはCrashLoopBackOffになる。
このようなMessageはKubernetes作業をやっているうちによく目にするMessageである。
PodはContainerのこのような状態をRunningとみなすが、内部のConditionsは[ContainerReady：False]、[Ready：False]になる。

**【正常起動】**
<img width="607" alt="6.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/519254/e15681d1-e0e9-f8f8-2e4c-2dd5daefc2fd.png">
全てのContainerが正常に起動されると、Conditionsは全てTrueになる。

**【注意事項】**
サービスを維持する場合の注意すべきことは、Podの状態がRunningでも、内部のContainerがRunningではない場合があるので
Podだけでなく、Containerの状態もモニタリングする必要がある。

**【Job/CronJob】**
<img width="784" alt="7.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/519254/dc867b31-d963-a222-2f8f-dc91100d1577.png">
PodがJobやCronJobで作成された場合はJobを実行する時はRunningの状態になるが、Jobが完了したらPodの状態はFailedやSucceededになる。
もしJobを実行しているContainerが1つでも問題が発生した場合はPodの状態がFailedになる。
または全てのContainerがCompletedになるとSucceededになる。
この時、PodのConditionsの値が変更されるが、成功または失敗であっても「ContainerReady：False」、「Ready：False」になる。

**【Irregular Case】**
<img width="592" alt="8.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/519254/43cf7959-18e3-1fb9-06d5-5d0b50b79ca9.png">
Pendingt状態からFailedになるケースもある。PendingやRunning状態でネットワーク障害が発生した場合はPodはUnknown状態になるが問題が早く解決されると既存の状態に戻れるが長い時間問題が解決できなかったらFailedになる。