Belajar Cron Job - Cron di Container & Kubernetes CronJob

#Pendahuluan

Di episode 14 kita membuat script-nya aman. Sekarang kita pindah konteks: di dalam container dan Kubernetes.

Banyak tim, ketika meng-containersisasi aplikasi, membawa semua kebiasaan lama — termasuk menjalankan crond di dalam image. Ini bekerja, tetapi menciptakan masalah yang tidak ada di mesin fisik: container yang "abadi" justru kontradiktif dengan filosofi container, dan cron di dalam container mati begitu container di-restart. Episode ini menjelaskan mengapa, dan apa penggantinya.

#Masalah Crond di Dalam Container

#Anti-Pattern: Multi-Process di Satu Container

Container idealnya menjalankan satu proses utama (PID 1). Ketika kalian menjalankan crond + aplikasi di image yang sama, kalian butuh process supervisor, konfigurasi sinyal yang rumit, dan jadwal yang mati bersama container:

• Container di-restart → jadwal hilang (state tidak persisten).
• Banyak instance container → beberapa crond menjalankan job yang sama, alias job duplikat.
• Sinyal (SIGTERM) tidak disebar ke job yang sedang berjalan → proses menggantung.

#Ganti dengan Satu Pendekatan yang Jelas

Aturan praktis modern: cron bukan tanggung jawab container; itu tanggung jawab orkestrator. Dua pengganti resmi:

1. Entrypoint loop — untuk container standalone yang berjalan lama.
2. Kubernetes CronJob — untuk workload di cluster.

#Entrypoint Loop: Cron Sederhana di Container

Untuk image yang menjalankan satu job berulang, loop dengan sleep di dalam entrypoint bisa menggantikan cron:

#!/bin/sh
set -e
 
while true; do
    /app/run-task.sh
    sleep 3600   # ekivalen jadwal setiap jam
done

Dengan pola ini:

• PID 1 adalah loop — signal handling benar.
• Tidak ada daemon tambahan.
• State jadwal sederhana, mudah dipahami.

Kekurangannya: tidak ada offset menit presisi tanpa menambahkan logika sleep. Untuk kebutuhan kompleks, langsung gunakan K8s CronJob.

#Kubernetes CronJob: batch/v1

Kubernetes menyediakan CronJob (API stabil batch/v1) yang menjadwalkan pod secara periodik — sintaks schedule-nya persis crontab.

#Manifest Dasar

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup
spec:
  schedule: "30 2 * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: backup
              image: myorg/backup-tool:1.4
              args: ["backup", "run"]

• schedule — jadwal crontab lima field (zona waktu cluster/kube-controller-manager).
• concurrencyPolicy — apa yang terjadi jika dua jadwal bertemu: Allow, Forbid, atau Replace. Forbid menggantikan flock di dunia K8s (episode 9).
• restartPolicy — pod dalam job harus OnFailure atau Never.

#Mencegah Job Menumpuk: History Limits dan TTL

Setiap eksekusi CronJob membuat Job dan Pod. Tanpa pembersihan, mereka menumpuk selamanya:

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

• successfulJobsHistoryLimit / failedJobsHistoryLimit — berapa banyak Job yang dipertahankan.
• ttlSecondsAfterFinished — Job dihapus otomatis beberapa saat setelah selesai.

#Perbandingan dengan Cron di Host

#Langkah Praktik Pertama

Terapkan dan uji CronJob

kubectl apply -f backup-cronjob.yaml
kubectl get cronjob backup
kubectl get jobs -l job-name=backup
kubectl logs job/backup-xxxxxxxx --tail=20

Untuk menguji tanpa menunggu jadwal, kita bahas cara memicu manual dan fitur lanjutan (startingDeadlineSeconds, suspend, parallelism) di episode 19.

#Penutup

Inti yang harus dibawa pulang:

• crond di dalam container adalah anti-pattern: multi-process, state hilang, job duplikat.
• Ganti dengan entrypoint loop untuk container standalone.
• K8s CronJob batch/v1 adalah pengganti modern untuk workload cluster.
• concurrencyPolicy: Forbid menggantikan flock; history limit + TTL mencegah penumpukan.
• Gunakan satu mekanisme scheduling — jangan campur crond host dan K8s untuk job yang sama.

Di episode 16 selanjutnya kita akan membahas timezone dan DST handling — CRON_TZ=Asia/Jakarta di crontab, pengaruh Daylight Saving Time pada job harian, dan praktik terbaik memakai UTC untuk infrastruktur!