Deployment・Job・StatefulSet — 処理とデータの寿命で選ぶ
ワークロードは名前で選ぶものではありません。処理が常駐か、完了したら終わりか、識別子と保存領域を保つ必要があるかで選びます。
TL;DR
- 常駐するAPIはDeployment、完了を目指す処理はJob、定期実行はCronJob。
- 安定した名前や専用ストレージが必要なものはStatefulSet。
- 本番のDB配置は可用性・バックアップまで含めて別途設計する。
01常駐か、完了か
Deployment・Job・CronJobを処理の寿命で並べる
Deploymentは継続稼働するPod群に向きます。Jobは成功して完了する処理を表し、CronJobはスケジュールに従ってJobを作ります。DBマイグレーションのような単発処理をDeploymentに混ぜないのが重要です。
押さえること：常駐するAPIはDeployment、完了を目指す処理はJob、定期実行はCronJob。
02StatefulSetが守るもの
StatefulSetのpod-0/pod-1とPVCの対応を示す
StatefulSetは各Podに安定した識別子を与え、Podごとにストレージ要求を持てます。Podが作り直されても、対応するデータを再接続したい場合のための仕組みです。
押さえること：安定した名前や専用ストレージが必要なものはStatefulSet。
03PVとPVCは役割を分ける
PVC要求→StorageClass→PV→Podの接続
PVは実体のストレージ、PVCは利用者側の要求です。StorageClassを使えばPVCの要求に応じてストレージを動的に用意できます。アプリはストレージ実装の詳細より、必要な容量やアクセス条件を宣言します。
押さえること：本番のDB配置は可用性・バックアップまで含めて別途設計する。
結論
- 常駐するAPIはDeployment、完了を目指す処理はJob、定期実行はCronJob。
- 安定した名前や専用ストレージが必要なものはStatefulSet。
- 本番のDB配置は可用性・バックアップまで含めて別途設計する。