Belajar Cron Job - Distributed Scheduling: K8s CronJob Lanjut

#Pendahuluan

Di episode 15 kita mengenal CronJob dasar: schedule, concurrencyPolicy, dan TTL. Sekarang kita naik ke level distributed scheduling — mengelola puluhan CronJob yang bisa gagal, tertunda, tersuspend, dan butuh dieksekusi paralel atau berantai. Kubernetes adalah penjadwal terdistribusi: ia tidak bergantung pada satu daemon host, menoleransi node gagal, dan menyediakan kontrol granular. Episode ini membedah fitur lanjut CronJob dan alternatifnya saat kebutuhan melampaui CronJob.

#Fitur Lanjut CronJob

#startingDeadlineSeconds: Batas Keterlambatan

Jika kontroler gagal menjalankan job tepat waktu (misal cluster overload), startingDeadlineSeconds menentukan seberapa lama keterlambatan masih bisa dikejar:

spec:
  schedule: "30 2 * * *"
  startingDeadlineSeconds: 1800

• Job yang tertunda di bawah 1800 detik tetap dijalankan.
• Keterlambatan lebih dari itu dilewati (missed) — tidak ditumpuk.

#suspend: Jeda tanpa Menghapus

Jeda dan lanjutkan CronJob

kubectl patch cronjob backup -p '{"spec":{"suspend":true}}'
kubectl patch cronjob backup -p '{"spec":{"suspend":false}}'

#successfulJobsHistoryLimit: Retention yang Ketat

Batasi history agar tidak menumpuk — untuk produksi, jadikan bagian dari manifest. backoffLimit mengontrol berapa kali pod di-retry sebelum job dianggap gagal:

spec:
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      ttlSecondsAfterFinished: 3600
      backoffLimit: 4

#Job Parallelism: Menjalankan Banyak Sekaligus

Untuk job yang bisa dipecah (misal memproses 100 file), gunakan parallelism:

jobTemplate:
  spec:
    parallelism: 10
    completions: 10
    template:
      spec:
        restartPolicy: OnFailure
        containers:
          - name: worker
            image: myorg/worker:1.0
            args: ["process-chunk", "--index=$(JOB_COMPLETION_INDEX)"]

JOB_COMPLETION_INDEX memberi setiap pod indeks 0-9 — pola work queue / fan-out yang berguna untuk batch processing.

#Pola Penggunaan Produksi

• Tahap extract → transform → load, masing-masing dengan schedule sendiri (Argo untuk dependensi antar tahap).
• Idempotency (episode 9) tetap berlaku: jalankan ulang tahap yang gagal tanpa merusak state.

#Leader Election: Hanya Satu Runner

Terkadang kalian ingin beberapa replika aplikasi, tetapi hanya satu yang menjalankan job berkala. CronJob tidak memilih pemimpin — aplikasi harus memakai lease Kubernetes (coordination.k8s.io) via --leader-election agar hanya satu instance yang bekerja. Ini setara flock di dunia distributed.

#Alternatif untuk Skala Besar

#Argo Workflows: Workflow DAG

Argo Workflows menjalankan workflow dengan dependensi antar langkah (DAG), retry per-langkah, dan artefak:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
spec:
  entrypoint: pipeline
  templates:
    - name: pipeline
      dag:
        tasks:
          - name: transform
            template: transform
            depends: extract
          - name: load
            template: load
            depends: transform

#KEDA Cron Scaler: Skala Berdasarkan Jadwal

KEDA menambahkan Cron scaler yang menskalakan deployment naik-turun mengikuti jadwal — untuk workload terus menerus yang volumenya mengikuti waktu:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
spec:
  scaleTargetRef:
    name: processor
  triggers:
    - type: cron
      metadata:
        timezone: Asia/Jakarta
        start: "0 2 * * *"
        end: "0 6 * * *"
        desiredReplicas: "10"

#Penutup

Inti yang harus dibawa pulang:

• startingDeadlineSeconds membatasi seberapa lama keterlambatan dikejar.
• suspend menjeda penjadwalan tanpa menghapus CronJob.
• successfulJobsHistoryLimit + ttlSecondsAfterFinished mencegah penumpukan.
• parallelism + JOB_COMPLETION_INDEX untuk batch/fan-out.
• Argo untuk workflow DAG; KEDA Cron scaler untuk skala berbasis jadwal.
• Leader election (lease) untuk single-runner di banyak replika.

Di episode 20 selanjutnya kita akan membahas monitoring dan observability job — mengekspor durasi dan status job ke Prometheus lewat node_exporter textfile, mendeteksi job yang tak pernah muncul dengan alerting on miss, plus audit siapa yang mengubah crontab dan review berkala!