きっかけ
podを作成する際、コマンドラインとマニフェストファイルのどちらを使ったとしてもrestart
やrestartPolicy
を使うことが多々ある。
よくよく調べてみると納得感があり、深淵なk8sへの理解に近づいたと感じたため記事にまとめてみる。
ちなみにkubectlではrestartを、マニフェストファイルではrestartPolicyを用いる。
公式ドキュメントを見てみる
kubectl runのコマンドによると
The restart policy for this Pod. Legal values [Always, OnFailure, Never]. If set to 'Always' a deployment is created, if set to 'OnFailure' a job is created, if set to 'Never', a regular pod is created. For the latter two --replicas must be 1. Default 'Always', for CronJobs Never.
ざっくり翻訳してみると
- kebectl runによってpodを作成する時のrestart policy
- 引数はAlways, OnFailure, Neverの3つ
-
--restart=Always
ならDeploymentが作成される -
--restart=OnFailure
ならJobがが作成される -
--restart=Never
なら通常のpodが作成される - デフォルト値はAlwaysである
- CronJobsを作成する時は
--restart=Never
とする - OnFailureかNeverを選択した場合は、kubectl run
replicas=1
とする必要がある
やってみる
試しにコマンドで操作してみる。
まずはAlwaysを渡す。
$ kubectl run --restart=Always always-pod --image=nginx:alpine
deployment.apps/always-pod created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
always-pod-55b8f9df58-hwz2q 1/1 Running 0 2m1s
$ kubectl get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
always-pod 1/1 1 1 3m5s
確かにDeploymentとして作成された。
次にOnFailureを渡す。
$ kubectl run --restart=OnFailure onfailure-pod --image=nginx:alpine
job.batch/onfailure-pod created
$ kubectl get pods
onfailure-pod-75jd8 1/1 Running 0 29s
$ kubectl get job
NAME COMPLETIONS DURATION AGE
onfailure-pod 0/1 58s 58s
これもJobが作成された。
次にNeverを渡す。
$ kubectl run --restart=Never never-pod --image=nginx:alpine
pod/never-pod created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
never-pod 1/1 Running 0 17s
普通のpodが作成された。
考察
なぜAlways, OnFailure, Neverという名前によってpod(の起動方法)が変わるのか考察する。
kubernetesの公式ドキュメントによると以下のように書かれている。
PodSpecには、Always、OnFailure、またはNeverのいずれかの値を持つrestartPolicyフィールドがあります。 デフォルト値はAlwaysです。restartPolicyは、Pod内のすべてのコンテナに適用されます。 restartPolicyは、同じNode上のkubeletによるコンテナの再起動のみを参照します。
他のドキュメントと突き合わせて考えると、
- 各ノードに存在するkubelet(ノードエージェント)がpodを定期的に監視する
- kubeletは、podのspecに記述されているコンテナが正常に実行されている状態に保つ
- その際にkebeletが読み取る情報の1つがpodのrestart policy
となる。
Alwaysであれば、kubeletは「podが常に動き続けている状態」を保証しようと振る舞うので、Deployment
OnFailureであれば、kubeletは「podに障害が発生した時や障害が発生した時に新しいpodを開始させる」ように振る舞うので、Job
Neverであれば、特にrestartする必要がないので通常のpodとなる