Cron → K8s CronJob
Kubernetes DevOps & Cloud-Native Batch Generator

Cron zu Kubernetes CronJob YAML-Konverter & Spezifikations-Generator Entwicklerhandbuch

Konvertieren Sie Standard-Crontab-Ausdrücke in produktionsreife Kubernetes CronJob-Manifeste mit deklarativer restartPolicy, concurrencyPolicy, Ressourcenlimits und Zeitzonenunterstützung.

POSIX Crontab ↔ batch/v1 CronJob & Helm
Vorlagen:
Parallelitätsrichtlinie:
Neustartrichtlinie:
CPU:/
Mem:/
Crontab-Zeitplan & BefehlPOSIX Standard
Enter 5-part cron or full crontab command line:[min] [hour] [dom] [mon] [dow] [cmd?]
Quick Chips:
Container Command / Exec Script:
|
Evaluierter Kubernetes-Zeitplanspec.schedule
schedule: "0 2 * * *"
5-Part Schedule Breakdown & Semanticsbatch/v1 Spec
Min 0At min 0
Hour 2At hour 2:00
DOM *Every day
Mon *Every month
DOW *Any weekday
Schedule Cadence:At 2:00 AM (02:00), every day.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
apiVersion: batch/v1
kind: CronJob
metadata:
  name: pg-nightly-backup
  namespace: default
  labels:
    app.kubernetes.io/name: pg-nightly-backup
    app.kubernetes.io/managed-by: toolsaa
spec:
  schedule: "0 2 * * *"
  timeZone: "UTC"
  concurrencyPolicy: Forbid
  suspend: false
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  startingDeadlineSeconds: 120
  jobTemplate:
    spec:
      backoffLimit: 3
      activeDeadlineSeconds: 3600
      template:
        metadata:
          labels:
            app.kubernetes.io/name: pg-nightly-backup
        spec:
          restartPolicy: OnFailure
          containers:
          - name: pg-nightly-backup
            image: postgres:16-alpine
            imagePullPolicy: IfNotPresent
        command:
        - /bin/sh
        - -c
        args:
        - "pg_dumpall -h postgres.database.svc.cluster.local -U postgres | gzip > /tmp/backup.sql.gz"
            resources:
              requests:
                cpu: "100m"
                memory: "128Mi"
              limits:
                cpu: "500m"
                memory: "512Mi"
            securityContext:
              allowPrivilegeEscalation: false
              runAsNonRoot: true
              readOnlyRootFilesystem: false
Syntax-Konformität
VALID (batch/v1 Compliant)
Tested against POSIX crontab & Go-cron spec
CronJob-Zeilen
Forbid • OnFailure
TZ: UTC (backoff: 3)
Manifest-Dateigröße
46 lines • 1253 bytes
Resource limits: 500m / 512Mi

100% Client-seitige Privatsphäre

Keine Server-Uploads oder Telemetrie. Alle Cron-Ausdrücke und Kubernetes-Spezifikationen werden rein lokal in Ihrem Browser verarbeitet.

Kubernetes batch/v1 Konformität

Erzeugt standardkonforme YAML-Manifeste gemäß batch/v1 Spezifikation und RFC 1123 Namenskonventionen.

Enterprise Cloud-Native Scheduling

Umfasst Concurrency-Policies (Forbid/Allow/Replace), Restart-Policies (OnFailure/Never), CPU/RAM-Limits und kubectl-Befehle.

Technische Referenz & Architektur-Leitfaden

Cron zu Kubernetes CronJob YAML-Konverter & Spezifikations-Generator Entwicklerhandbuch — Referenz-Leitfaden

Konvertieren Sie Standard-Crontab-Ausdrücke in produktionsreife Kubernetes CronJob-Manifeste mit deklarativer restartPolicy, concurrencyPolicy, Ressourcenlimits und Zeitzonenunterstützung.

Wichtige Parameter & Steuerelemente

spec.schedulestring

Standardmäßiger 5-Felder-Cron-Ausdruck (Minute, Stunde, Tag des Monats, Monat, Wochentag) zur Festlegung des Ausführungsintervalls.

Standard: 0 0 * * *
spec.concurrencyPolicystring ('Allow' | 'Forbid' | 'Replace')

Definiert das Verhalten, wenn ein neuer Job geplant wird, während eine vorherige Instanz noch aktiv ausgeführt wird.

Standard: Allow
spec.jobTemplate.spec.template.spec.restartPolicystring ('OnFailure' | 'Never')

Neustartrichtlinie für Container im Pod. Batch-Jobs erfordern einen finalen Abschlusszustand; 'Always' ist in Kubernetes unzulässig.

Standard: OnFailure
spec.startingDeadlineSecondsinteger (Sekunden)

Optionales Zeitfenster in Sekunden, innerhalb dessen ein verpasster Job nach Cluster-Wartungen noch gestartet werden darf.

Standard: Keine Angabe (optional)
spec.successfulJobsHistoryLimitinteger

Anzahl erfolgreich abgeschlossener Job-Pods, die zu Audit- und Protokollzwecken aufbewahrt werden.

Standard: 3
spec.failedJobsHistoryLimitinteger

Anzahl fehlgeschlagener Job-Pods, die zur Ursachenanalyse und Fehlerbehebung gespeichert bleiben.

Standard: 1

Profi-Tipps & Best Practices

'concurrencyPolicy: Forbid' für langlaufende Stapelverarbeitungen erzwingen

Wenn Datenbank-Backups oder ETL-Prozesse länger dauern als das geplante Intervall, verhindert 'Forbid' parallele Überlappungen, Deadlocks und Ressourcenerschöpfung im Cluster.

Hängende Jobs mit 'activeDeadlineSeconds' automatisch abbrechen

Definieren Sie stets 'spec.jobTemplate.spec.activeDeadlineSeconds'. Sollte ein Batch-Pod bei Netzwerk-Timeouts hängenbleiben, beendet Kubernetes den Job nach Ablauf dieser Frist zuverlässig.

Native Zeitzonenunterstützung in Kubernetes 1.27+ nutzen

Konfigurieren Sie 'spec.timeZone: "Europe/Berlin"' oder '"UTC"' direkt im Manifest, um Sommer-/Winterzeit-Umstellungen unabhängig von der Host-Knotenuhr fehlerfrei abzubilden.

'backoffLimit' reduzieren, um endlose Neustartkaskaden zu vermeiden

Setzen Sie 'spec.jobTemplate.spec.backoffLimit: 2' oder '3' statt des Standardwerts 6, um bei dauerhaften Anwendungsfehlern eine Flut unnötiger Pod-Erstellungen zu unterbinden.

Häufige Fallstricke & Fehlerbehebung

Ungültige restartPolicy: 'Pod template restart policy Always is not allowed'

Ändern Sie 'spec.jobTemplate.spec.template.spec.restartPolicy' von 'Always' auf 'OnFailure' oder 'Never'. Batch-Jobs müssen terminieren können.

CronJob startet nicht mehr: 'Cannot determine if job needs to be started: too many missed start time (> 100)'

Wenn ein CronJob mehr als 100 Startzeitpunkte verpasst, stellt der Controller die Planung ein. Setzen Sie 'spec.startingDeadlineSeconds: 200' und erstellen Sie den CronJob per kubectl neu.

Gleichzeitige Job-Ausführungen führen zu Dateninkonsistenzen

Ändern Sie 'spec.concurrencyPolicy' von 'Allow' auf 'Forbid'. Nachfolgende Ausführungen werden übersprungen, solange der Vorgänger noch aktiv läuft.

Häufig gestellte Fragen (FAQ)

Welche API-Version sollte für Kubernetes CronJobs verwendet werden?▼

Verwenden Sie stets 'apiVersion: batch/v1'. Die veraltete Version 'batch/v1beta1' wurde mit Kubernetes v1.21 als veraltet markiert und in Version v1.25 endgültig entfernt.

Worin unterscheidet sich ein Kubernetes CronJob vom klassischen Linux-Crontab?▼

Linux-Crontabs führen Skripte direkt auf einem lokalen Betriebssystem unter einem Benutzerkonto aus. Kubernetes CronJobs koordinieren isolierte Container-Pods über einen gesamten Cluster hinweg mit deklarativen Quoten, Secrets und automatischen Wiederholungen.

Kann ein Kubernetes CronJob sofort manuell ausgelöst werden?▼

Ja, mit dem Befehl 'kubectl create job <name> --from=cronjob/<cronjob-name> -n <namespace>' können Sie unmittelbar einen einmaligen Testlauf auf Basis der Vorlage ausführen.

Was ist der Unterschied zwischen restartPolicy 'OnFailure' und 'Never'?▼

Bei 'OnFailure' startet Kubernetes den abgestürzten Container innerhalb desselben Pods auf demselben Knoten neu. Bei 'Never' wird der Pod als fehlerhaft belassen und ein neuer Pod gemäß 'backoffLimit' auf einem gesunden Knoten erzeugt.

Welche Rolle spielen Ressourcenanforderungen (requests und limits)?▼

'resources.requests' stellt sicher, dass der Scheduler den Batch-Pod nur auf Knoten mit ausreichender Kapazität platziert. 'resources.limits' verhindert, dass speicherhungrige Jobs andere produktive Workloads gefährden.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →