#はじめに
今回はJobのパラメータの一つの「restartPolicy」の動作を確認します。
設定値は以下の2つです。2つのうちのどちらかを指定する必要があります。

設定値	概要
Never	Pod障害時に新しいPodを作成してリトライする
OnFailure	Pod障害時に同じPodでリトライする

なお、前回説明した「spec.backoffLimit」パラメータの値を0にしていると、一回障害が起きた時点でJobの終了条件を満たしてしまいますので、リトライさせる場合には、「spec.backoffLimit」の値を1以上にする必要があります。

#Never
まずはNeverの動作を確認してみます。
これは前回でも設定していましたので、同じ動作になります。

こちらのyamlファイルで動作を確認します。

sampleJob-back.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: sample-job-back
spec:
  completions: 5
  parallelism: 1
  backoffLimit: 3
  template:
    spec:
      containers:
      - name: sample-job1
        image: centos:latest
        command: ["sh", "-c"]
        args: ["ls; exit 1"]
      restartPolicy: Never

このファイルをapplyする前に、別ターミナルで「kubectl get pod -w」でPodの状態を監視しておきます。-wオプションを付けると、tailコマンドの-fオプションのような動作になります。
kubectl get pod -wを動かしながらapplyします。

$ kubectl apply -f sampleJob-back.yaml
job.batch/sample-job-back created

Podの状態を確認します。

$ kubectl get pod -w
NAME                    READY   STATUS    RESTARTS   AGE
sample-job-back-l79vh   0/1     Pending   0          0s
sample-job-back-l79vh   0/1     Pending   0          0s
sample-job-back-l79vh   0/1     ContainerCreating   0          0s
sample-job-back-l79vh   0/1     ContainerCreating   0          2s
sample-job-back-l79vh   1/1     Running             0          6s
sample-job-back-l79vh   0/1     Error               0          7s
sample-job-back-cj2h6   0/1     Pending             0          0s
sample-job-back-cj2h6   0/1     Pending             0          0s
sample-job-back-cj2h6   0/1     ContainerCreating   0          0s
sample-job-back-cj2h6   0/1     ContainerCreating   0          1s
sample-job-back-cj2h6   0/1     Error               0          5s
sample-job-back-5fsc5   0/1     Pending             0          0s
sample-job-back-5fsc5   0/1     Pending             0          0s
sample-job-back-5fsc5   0/1     ContainerCreating   0          0s
sample-job-back-5fsc5   0/1     ContainerCreating   0          1s
sample-job-back-5fsc5   0/1     Error               0          5s

Podの作成 -> Error -> 新しいPodの作成
の順にPodを3つ（backoffLimitの値）作成して終了していることがわかりますね。

JobとPodの状態を確認しておきます。

$ kubectl get job
NAME              COMPLETIONS   DURATION   AGE
sample-job-back   0/5           41s        41s
$ kubectl get pod
NAME                    READY   STATUS   RESTARTS   AGE
sample-job-back-5fsc5   0/1     Error    0          18s
sample-job-back-cj2h6   0/1     Error    0          28s
sample-job-back-l79vh   0/1     Error    0          35s
$ kubectl describe job sample-job-back
Name:           sample-job-back
・・・
Events:
  Type     Reason                Age   From            Message
  ----     ------                ----  ----            -------
  Normal   SuccessfulCreate      50s   job-controller  Created pod: sample-job-back-l79vh
  Normal   SuccessfulCreate      43s   job-controller  Created pod: sample-job-back-cj2h6
  Normal   SuccessfulCreate      33s   job-controller  Created pod: sample-job-back-5fsc5
  Warning  BackoffLimitExceeded  13s   job-controller  Job has reached the specified backoff limit

#OnFailure
次にOnFailureの動作を確認してみます。
以下のyamlファイルをapplyします。

sampleJob-rp.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: sample-job-rp
spec:
  completions: 5
  parallelism: 1
  backoffLimit: 3
  template:
    spec:
      containers:
      - name: sample-job1
        image: centos:latest
        command: ["sh", "-c"]
        args: ["ls; exit 1"]
      restartPolicy: OnFailure

$ kubectl apply -f sampleJob-rp.yaml
job.batch/sample-job-rp created

同様にPodの状態を確認します。

$ kubectl get pod -w
NAME                  READY   STATUS    RESTARTS   AGE
sample-job-rp-jcff5   0/1     Pending   0          0s
sample-job-rp-jcff5   0/1     Pending   0          0s
sample-job-rp-jcff5   0/1     ContainerCreating   0          0s
sample-job-rp-jcff5   0/1     ContainerCreating   0          1s
sample-job-rp-jcff5   0/1     Error               0          5s
sample-job-rp-jcff5   0/1     Error               1          10s
sample-job-rp-jcff5   0/1     CrashLoopBackOff    1          11s
sample-job-rp-jcff5   0/1     Error               2          28s
sample-job-rp-jcff5   0/1     CrashLoopBackOff    2          42s
sample-job-rp-jcff5   0/1     Error               3          61s
sample-job-rp-jcff5   0/1     Terminating         3          61s
sample-job-rp-jcff5   0/1     Terminating         3          61s
sample-job-rp-jcff5   0/1     Terminating         3          71s
sample-job-rp-jcff5   0/1     Terminating         3          71s

Neverと違って、同じPodで3回リトライしてますね。リトライするたびに「RESTARTS」の値が増えています。
また、PodがErrorで終わるのではなく、Terminatingの状態で終わっています。

JobとPodの状態を確認します。

$ kubectl get job
NAME            COMPLETIONS   DURATION   AGE
sample-job-rp   0/5           2m57s      2m57s
$ kubectl get pod
No resources found in default namespace.
$ kubectl describe job sample-job-rp
Name:           sample-job-rp
・・・
Events:
  Type     Reason                Age                    From            Message
  ----     ------                ----                   ----            -------
  Normal   SuccessfulCreate      10m                    job-controller  Created pod: sample-job-rp-628ps
  Normal   SuccessfulDelete      9m49s                  job-controller  Deleted pod: sample-job-rp-628ps
  Warning  BackoffLimitExceeded  9m49s (x2 over 9m49s)  job-controller  Job has reached the specified backoff limit

こちらもNeverとは違って、Jobは残っていますが、Podは削除された状態で終わってますね。

#まとめ
今回はrestartPolicyの動作を確認しました。
動作は理解しましたが、どういう場合にどちらを選ぶかが思いつきません。アプリの作り次第なのかなと思いますが、実際に選択する機会が出てきたら、アプリの担当に聞いてみよう。