【ITニュース解説】Part-96: ⚙️Implementing Job backoffLimit in Google Kubernetes Engine (GKE)

システムエンジニアを目指す皆さんにとって、現代のITインフラを支える技術の一つであるKubernetesは、避けて通れない重要なテーマだ。特に、一度きりの処理やバッチ処理を実行する際に利用される「Job」という機能は、多くの場面で活用される。しかし、プログラムは常に完璧に動作するとは限らない。アプリケーションにバグがあったり、設定が間違っていたり、あるいは一時的なネットワーク障害などの外部要因によって、処理が途中で失敗してしまうことは日常茶飯事だ。このような場合に、Kubernetesがどのように振る舞い、そしてその挙動をどう制御するのかを知ることは、安定したシステムを運用する上で非常に役立つ。今回の解説では、KubernetesのJobが失敗した時に何回リトライ（再試行）を行うかを制御する「backoffLimit」という設定について、具体例を交えながら詳しく見ていく。

KubernetesにおけるJobとは、指定されたタスクを一度だけ、または完了するまで実行するためのリソースだ。例えば、データベースのバックアップを取る処理や、データ分析のバッチ処理など、完了すればその役目を終えるようなワークロードに適している。Jobが実行されると、そのJobを構成する一つ以上の「Pod」という最小単位のコンテナが起動される。もし、このPodの中で実行されているアプリケーションがエラーを起こし、異常終了してしまったらどうなるだろうか。Kubernetesは賢いので、すぐにそのJobを失敗と見なすのではなく、デフォルトで最大6回まで、失敗したPodを再起動して処理をやり直させようと試みる。これは、一時的な問題であれば再試行によって解決し、無駄な手作業を減らすための非常に便利な機能である。しかし、もし根本的なエラーで何度やっても失敗する場合、無制限にリトライし続けるのは無駄なリソース消費につながる。そこで登場するのが、このリトライ回数を明示的に設定できる「backoffLimit」という機能だ。この設定を使うことで、KubernetesがJobの失敗を何回まで再試行するかを、開発者や運用者が自由に決めることができる。

今回のデモンストレーションでは、このbackoffLimitの動作を理解するために、意図的に失敗するJobを作成し、そのリトライ挙動を確認する。具体的には、backoffLimitの値を「4」に設定する。これは、Jobが失敗した場合に、最大4回まで再試行することを意味する。つまり、最初の試行と合わせて最大5つのPodが起動し、全て失敗するとJobは最終的に失敗とマークされることを期待している。

Jobの定義は、YAML形式のファイルで記述する。これを「マニフェスト」と呼ぶ。今回のデモで使用するjob2.yamlというファイルは以下のようになるだろう。

Copy
1apiVersion: batch/v1
2kind: Job
3metadata:
4  name: job2
5spec:
6  template:
7    metadata:
8      name: job2
9    spec:
10      containers:
11      - name: job2
12        image: alpine
13        command: ['sh', '-c', 'echo Kubernetes Jobs Demo - backoffLimit Test ; exit 1']
14      restartPolicy: Never
15  backoffLimit: 4

このマニフェストの内容を一つずつ見ていこう。「apiVersion: batch/v1」は、KubernetesのJobリソースのバージョンを指定している。次に「kind: Job」で、これがJobという種類のリソースであることを宣言している。「metadata.name: job2」は、このJobに「job2」という名前を付けている。

そして重要なのが「spec」セクションだ。ここにJobの具体的な動作が定義される。「template」の下には、このJobが作成するPodの定義が記述されている。Podの中には「containers」が定義されており、今回の例では「name: job2」というコンテナが一つ含まれている。「image: alpine」は、このコンテナが非常に軽量なLinuxディストリビューションであるAlpine Linuxのイメージを使うことを示している。

ここで最も注目すべきは「command」の部分だ。「command: ['sh', '-c', 'echo Kubernetes Jobs Demo - backoffLimit Test ; exit 1']」は、コンテナが起動した際に実行される命令を指定している。通常、コマンドは正常終了を示す「exit 0」で終わるが、ここでは意図的に「exit 1」という終了コードを使っている。シェルスクリプトにおいて、「exit」にゼロ以外の値が渡されると、それは「エラー」として扱われる。これにより、このコンテナは起動するたびに必ず失敗するようになっているのだ。

また、「restartPolicy: Never」という設定も重要だ。これは、コンテナが失敗してもPod内でそのコンテナを再起動しない、という意味を持つ。JobのリトライはPodレベルで行われるため、コンテナが失敗した場合は新しいPodを起動し直す。もしこの設定が「Always」などになっていると、コンテナが失敗するたびにPod内でコンテナが何度も再起動し、意図しない挙動になる可能性があるため、「Never」と設定することがJobでは一般的だ。

そして、今回の主役である「backoffLimit: 4」がJobのspec直下に設定されている。これが、このJobが失敗したPodを最大4回まで再試行するようにKubernetesに指示している部分だ。

このjob2.yamlファイルを準備したら、次はこれをKubernetesクラスターにデプロイする。GKE（Google Kubernetes Engine）のようなマネージドKubernetes環境でも、オンプレミスのKubernetesでも手順は同じだ。ターミナルを開き、「kubectl apply -f job2.yaml」というコマンドを実行する。これでJobがクラスターに作成される。

デプロイが完了したら、Jobとそれによって作成されたPodの状態を確認する。「kubectl get jobs」と実行すると、作成したJob「job2」の状態が見られるだろう。そして「kubectl get pods」と実行すると、Jobによって起動されたPodの一覧が表示される。

このコマンドの出力例を見ると、以下のような結果が表示されるはずだ。

NAME         READY   STATUS   RESTARTS   AGE
job2-c88pf   0/1     Error    0          3m14s
job2-dxlzq   0/1     Error    0          3m34s
job2-jsb6n   0/1     Error    0          2m44s
job2-pxn5t   0/1     Error    0          2m29s

このように、名前の先頭が「job2-」で始まり、ランダムな文字列が続く複数のPodが表示されているはずだ。そして、全てのPodの「STATUS」が「Error」になっていることに注目してほしい。これは、先ほど設定したcommandによって、各Podのコンテナが意図的に失敗したことを示している。表示されているPodの数は4つだ。これは、記事の例では4つのPodしか示されていないが、KubernetesがbackoffLimit: 4で設定された4回のリトライを実行した結果として、4つのエラー状態のPodが作成されたことを明確に示している。

Job全体の詳細を確認したい場合は、「kubectl describe job job2」というコマンドを使う。この出力では、Jobのステータスとして「0/1 completed」と表示されているはずだ。これは、Jobが目標とする「1つ以上のPodの正常終了」が達成されていないことを意味する。そして、「Pods Statuses」のセクションでは、「Failed: 4」と表示されていることから、4つのPodが失敗したことが確認できるだろう。これは、backoffLimit: 4の設定通り、4回のリトライが行われ、その全てが失敗した結果だ。これにより、KubernetesはこのJobを最終的に「失敗」としてマークする。

Jobの動作確認が終わったら、不要なリソースをクリーンアップすることが重要だ。今回のJobとそれに関連するすべてのPodを削除するには、「kubectl delete job job2」というシンプルなコマンドを実行すればよい。これにより、作成したJobと、それによって起動されたすべてのPodがクラスターから削除され、リソースが解放される。

今回の解説を通じて、KubernetesのJobにおけるbackoffLimitの重要性が理解できただろう。これは、Jobが永遠にリトライを繰り返してしまうのを防ぐための、非常に重要な安全機構だ。デフォルトのリトライ回数である6回という値は、多くのシナリオで十分だが、特定のワークロードではこの値を調整する必要がある場合がある。例えば、一時的なエラーは頻繁に発生するが、少数のリトライで回復する見込みが高い場合は、backoffLimitを少し高めに設定することで、Jobが自動的に成功する確率を高められる。逆に、アプリケーションのエラーがすぐに判明し、リトライしても無駄なリソース消費にしかならないような場合は、backoffLimitを低く設定したり、場合によっては0に設定したりすることで、Jobを早く失敗と見なし、無駄な計算リソースを節約することができる。このように、backoffLimitはKubernetesのJobをより効率的かつ堅牢に運用するための、強力なツールの一つだ。システムエンジニアを目指す皆さんにとって、このような設定を理解し、適切に活用することは、信頼性の高いシステムを構築・運用するために不可欠なスキルとなる。