16 Einführung in Jobs in Kubernetes

Run Jobs

Jobs in Kubernetes orchestrieren die Ausführung temporärer Pods, die mit dem vollständigen Abarbeiten einer Aufgabe terminieren. Sie unterscheiden sich von Deployments oder StatefulSets, die kontinuierlich laufende Pods sicherstellen. Jobs sind besonders nützlich für einmalige Prozesse oder Batch-Jobs, da sie die Fertigstellung der Aufgabe garantieren und parallel ausgeführt werden können.

16.1 Grundlegende Eigenschaften

• Vollständigkeit: Ein Job stellt sicher, dass die zugewiesene Aufgabe abgeschlossen wird.
• Parallelität: Ein Job kann mehrere Instanzen eines Pods parallel ausführen.
• Wiederholungen: Ein Job wird so oft wiederholt, bis die Aufgabe erfolgreich abgeschlossen ist.

16.1.1 Job-Spezifikation

Ein einfaches Job-Manifest könnte so aussehen:

apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      containers:
      - name: my-container
        image: my-image
      restartPolicy: Never

16.1.2 Wichtige Felder

• apiVersion: Gibt die API-Version an, in diesem Fall batch/v1.
• kind: Der Ressourcentyp, in diesem Fall Job.
• metadata: Metadaten wie der Name des Jobs.
• spec: Die Spezifikation des Jobs, einschließlich des Pod-Templates.
• restartPolicy: Muss auf Never oder OnFailure gesetzt sein.

16.1.3 Parallelität und Abschluss

Jobs können so konfiguriert werden, dass sie eine bestimmte Anzahl von Pods parallel ausführen und eine bestimmte Anzahl von erfolgreichen Abschlüssen erreichen. Dies wird durch die Felder completions und parallelism gesteuert.

spec:
  completions: 5
  parallelism: 2

16.1.4 Job-Status

Der Status eines Jobs kann mit dem Befehl kubectl describe job <job-name> abgefragt werden. Hier werden wichtige Informationen wie die Anzahl der erfolgreichen Abschlüsse und der Status der Pods angezeigt.

16.1.5 activeDeadlineSeconds

In Kubernetes gibt es ein Feld in Job-Ressourcen namens activeDeadlineSeconds. Dieses Feld definiert die maximale Laufzeit (in Sekunden), die für die Ausführung der Pods innerhalb des Jobs erlaubt ist. Wenn die aktive Deadline erreicht wird, wird der Job von Kubernetes als fehlgeschlagen markiert, und die Pods innerhalb des Jobs werden beendet.

Hier ist eine Erklärung dazu:

• activeDeadlineSeconds: Dieses Feld legt fest, wie lange die Pods innerhalb des Jobs aktiv sein dürfen. Es ist wichtig zu beachten, dass es sich hierbei um die tatsächliche Laufzeit der Pods handelt, nicht um die Gesamtdauer, die der Job benötigt, um abzuschließen. Wenn die aktive Deadline überschritten wird, werden die Pods beendet, unabhängig davon, ob sie bereits abgeschlossen haben oder nicht.

Die Verwendung von activeDeadlineSeconds kann nützlich sein, um sicherzustellen, dass Jobs nicht zu lange laufen und Ressourcen nicht unnötig blockieren. Es kann auch dazu beitragen, unendliche Schleifen oder blockierte Jobs zu verhindern. Wenn die Pods die aktive Deadline überschreiten, wird der Job in einem fehlgeschlagenen Zustand beendet, und Sie können entsprechende Maßnahmen ergreifen, um das Problem zu untersuchen und zu beheben.

Hier ist ein Beispiel einer Job-Definition mit activeDeadlineSeconds:

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  activeDeadlineSeconds: 3600 # Der Job wird nach einer Stunde (3600 Sekunden) beendet.
  template:
    spec:
      containers:
        - name: example-container
          image: busybox
          command: ["sleep", "600"] # Der Container schläft für 10 Minuten.
      restartPolicy: Never

In diesem Beispiel wird der Job nach einer Stunde beendet, unabhängig davon, ob der Container bereits abgeschlossen hat oder nicht.

16.1.6 ttlSecondsAfterFinished

In Kubernetes gibt es das Feld ttlSecondsAfterFinished, das in der Spezifikation von Jobs und CronJobs verwendet wird. Dieses Feld legt fest, wie lange (in Sekunden) die abgeschlossenen Pods nach Beendigung des Jobs oder CronJobs aufbewahrt werden sollen, bevor sie vom Kubernetes-System automatisch gelöscht werden. Es ist eine nützliche Funktion, um abgeschlossene Pods und Ressourcen zu bereinigen und Speicherplatz freizugeben.

Hier ist eine Erklärung dazu:

• ttlSecondsAfterFinished: Dieses Feld gibt an, wie lange abgeschlossene Pods nach Beendigung des Jobs oder CronJobs aufbewahrt werden sollen. Wenn dieses Feld auf einen Wert größer als 0 gesetzt ist, werden die Pods nach diesem Zeitraum automatisch gelöscht.

Die Verwendung von ttlSecondsAfterFinished hilft dabei, abgeschlossene Pods und ihre Ressourcen (z. B. Speicherplatz) effizient zu verwalten und zu bereinigen, insbesondere in Umgebungen mit vielen Jobs oder CronJobs. Wenn Sie beispielsweise Jobs haben, die regelmäßig laufen und abgeschlossen werden, können die alten Pods automatisch entfernt werden, um die Clusterressourcen sauber zu halten.

Hier ist ein Beispiel einer Job-Definition mit ttlSecondsAfterFinished:

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  ttlSecondsAfterFinished: 3600 # Abgeschlossene Pods werden nach einer Stunde gelöscht.
  template:
    spec:
      containers:
        - name: example-container
          image: busybox
          command: ["sleep", "600"] # Der Container schläft für 10 Minuten.
      restartPolicy: Never

In diesem Beispiel werden die abgeschlossenen Pods des Jobs nach einer Stunde automatisch gelöscht, nachdem der Job seinerseits abgeschlossen wurde.

16.1.7 PODS

Sowohl Jobs als auch CronJobs in Kubernetes erzeugen temporäre Pods für ihre Ausführung. Ein Job erzeugt einen oder mehrere Pods und stellt sicher, dass eine bestimmte Anzahl von ihnen erfolgreich abschließt. Ein CronJob ist im Grunde ein Job, der nach einem festgelegten Zeitplan ausgeführt wird.

16.1.8 Restart Policy

Die restartPolicy in einem Job-Manifest gibt an, wie Kubernetes mit Pod-Fehlern umgehen soll. Die Optionen sind:

• Never: Der Pod wird nicht neu gestartet, wenn er fehlschlägt.
• OnFailure: Der Pod wird nur dann neu gestartet, wenn er mit einem Fehler (nicht null Exit-Status) beendet wird.

Für Jobs ist die restartPolicy standardmäßig auf OnFailure gesetzt. Das ermöglicht eine Wiederholung der Aufgabe innerhalb des gleichen Pods bei vorübergehenden Fehlern. Bei permanenten Fehlern kann eine manuelle Intervention erforderlich sein.

Dies ist nützlich, um Ressourcen effizient zu nutzen und den Overhead der Pod-Erstellung zu minimieren. Es ermöglicht auch die Nutzung von persistentem Speicher, der an den ursprünglichen Pod gebunden ist.

16.2 Beendete Jobs aufräumen

Um Jobs im Status Completed zu entfernen, können Sie den folgenden kubectl Befehl verwenden:

kubectl delete jobs --selector=<Ihr-Label-Selector> --namespace=<Ihr-Namespace> --field-selector=status.successful=1

Um Pods im Status Completed zu entfernen:

kubectl delete pods --selector=<Ihr-Label-Selector> --namespace=<Ihr-Namespace> --field-selector=status.phase==Succeeded

Ersetzen Sie <Ihr-Label-Selector> und <Ihr-Namespace> entsprechend Ihren Anforderungen. Ohne Angabe eines Namespace werden die Befehle im default Namespace ausgeführt.

16.3 Einführung in CronJobs in Kubernetes

Cronjobs

CronJobs in Kubernetes automatisieren wiederkehrende Aufgaben durch die zeitgesteuerte Ausführung von Containern, ähnlich dem UNIX-Cron-Daemon, und vereinen die Flexibilität von Jobs mit planmäßiger Auslösung.

16.3.1 Grundlegende Eigenschaften

• Zeitplanung: CronJobs ermöglichen die Ausführung von Jobs zu festgelegten Zeiten oder Intervallen.
• Fehlertoleranz: Sie können konfiguriert werden, um bei Fehlern erneut zu starten.
• Parallelität: Wie bei Jobs können auch CronJobs parallel ausgeführt werden.

16.3.2 CronJob-Spezifikation

Ein einfaches CronJob-Manifest könnte so aussehen:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: my-cronjob
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-container
            image: my-image
          restartPolicy: OnFailure

16.3.3 Wichtige Felder

• apiVersion: Gibt die API-Version an, in diesem Fall batch/v1beta1.
• kind: Der Ressourcentyp, in diesem Fall CronJob.
• metadata: Metadaten wie der Name des CronJobs.
• spec: Die Spezifikation des CronJobs.
• schedule: Der Ausführungszeitplan im Cron-Format.
• jobTemplate: Das Template für den Job, der ausgeführt werden soll.

16.3.4 Zeitplanung und Ausführung

Das Feld schedule verwendet die Cron-Syntax, um den Ausführungszeitpunkt zu definieren. Zum Beispiel führt "*/1 * * * *" den Job jede Minute aus.

16.3.5 Überlappung und Parallelität

Mit den Feldern concurrencyPolicy und startingDeadlineSeconds können Sie steuern, wie CronJobs sich bei Überlappungen oder Verzögerungen verhalten.

16.3.6 Job-Historie

CronJobs erstellen für jede Ausführung einen Job. Die Anzahl der beizubehaltenden erfolgreichen und fehlgeschlagenen Jobs kann mit successfulJobsHistoryLimit und failedJobsHistoryLimit gesteuert werden.