Zum Hauptinhalt springen
Version: Nächste

Planungsregeln definieren

Inoffizielle Beta-Übersetzung

Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →

Übersicht über Zeitpläne​

Dieses Dokument erklärt, wie Sie mit Chaos Mesh geplante Aufgaben erstellen, die automatisch Chaos-Experimente zu festgelegten Zeiten (oder in festen Intervallen) durchführen.

In Kubernetes verwendet Chaos Mesh Schedule, um geplante Aufgaben zu beschreiben.

Hinweis

Der Name eines Schedule-Objekts darf maximal 57 Zeichen umfassen, da das erstellte Chaos-Experiment 6 zusätzliche Zeichen am Namenende hinzufügt. Bei Schedule-Objekten mit Workflow darf der Name maximal 51 Zeichen betragen, da Workflow 6 zusätzliche Zeichen anhängt.

Planungsregeln mit kubectl über YAML-Dateien erstellen​

Um beispielsweise in der fünften Minute jeder Stunde eine 100-Millisekunden-Verzögerung für 12 Sekunden anzuwenden, konfigurieren Sie die YAML-Datei wie folgt:

apiVersion: chaos-mesh.org/v1alpha1
kind: Schedule
metadata:
  name: schedule-delay-example
spec:
  schedule: '5 * * * *'
  historyLimit: 2
  concurrencyPolicy: 'Allow'
  type: 'NetworkChaos'
  networkChaos:
    action: delay
    mode: one
    selector:
      namespaces:
        - default
      labelSelectors:
        'app': 'web-show'
    delay:
      latency: '10ms'
      correlation: '100'
      jitter: '0ms'
    duration: '12s'

Speichern Sie diese YAML-Datei als schedule-networkchaos.yaml und führen Sie kubectl apply -f ./schedule-networkchaos.yaml aus.

Basierend auf dieser Konfiguration erstellt Chaos Mesh in der fünften Minute jeder Stunde (z.B. 0:05, 1:05) folgendes NetworkChaos-Objekt:

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: schedule-delay-example-xxxxx
spec:
  action: delay
  mode: one
  selector:
    namespaces:
      - default
    labelSelectors:
      'app': 'web-show'
  delay:
    latency: '10ms'
    correlation: '100'
    jitter: '0ms'
  duration: '12s'

Die Felder in Schedule werden unten beschrieben und ähneln weitgehend denen in Kubernetes CronJob. Weitere Informationen finden Sie in der Kubernetes CronJob-Dokumentation.

Hinweis

Die Zeitzone im schedule-Feld orientiert sich an der Zeitzone des chaos-controller-manager.

schedule-Feld​

Das schedule-Feld legt den Zeitpunkt für die Experimentausführung fest. Ein Zeitplan entspricht somit einem Cron-Job:

# ┌───────────── minute (0 - 59)
# │ ┌───────────── hour (0 - 23)
# │ │ ┌───────────── day of the month (1 - 31)
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday; 7 is also Sunday on some systems)
# │ │ │ │ │
# │ │ │ │ │
# │ │ │ │ │
# * * * * * <command to execute>

Dieses Diagramm stammt von https://en.wikipedia.org/wiki/Cron.

Chaos Mesh nutzt intern robfig/cron/v3, um das schedule-Feld in einen Cron-Ausdruck umzuwandeln.

Tipp

Zur Generierung von Zeitplänen können Web-Tools wie crontab.guru verwendet werden.

Vordefinierte Zeitpläne​

Zusätzlich zur Standardsyntax stehen mehrere vordefinierte Zeitpläne zur Verfügung, die anstelle von Cron-Ausdrücken genutzt werden können:

EntryDescriptionEquivalent To
@yearly (or @annually)Run once a year, midnight, Jan. 1st0 0 1 1 *
@monthlyRun once a month, midnight, first of month0 0 1 * *
@weeklyRun once a week, midnight between Sat/Sun0 0 * * 0
@daily (or @midnight)Run once a day, midnight0 0 * * *
@hourlyRun once an hour, beginning of hour0 * * * *

Diese Tabelle stammt von https://pkg.go.dev/github.com/robfig/cron/v3#hdr-Predefined_schedules.

Intervalle​

Aufgaben können auch in festen Intervallen ausgeführt werden, beginnend zum Zeitpunkt der Erstellung oder Cron-Ausführung. Dies wird durch folgende Cron-Spezifikation ermöglicht:

@every <duration>

Beispielsweise gibt @every 1h30m10s einen Zeitplan an, der nach 1 Stunde, 30 Minuten und 10 Sekunden startet und danach in diesem Intervall wiederholt.

Hinweis

Der Inhalt zu Intervals stammt von https://pkg.go.dev/github.com/robfig/cron/v3#hdr-Intervals. Weitere Details finden Sie in der offiziellen Dokumentation.

historyLimit-Feld​

Nach Experimentende wird der Verlauf nicht gelöscht, sodass Ergebnisse bei Fehlern einfach abrufbar sind. historyLimit definiert die Anzahl beizubehaltender Tasks, einschließlich laufender Aufgaben. Chaos Mesh löscht keine aktiven Tasks.

Bei mehr Tasks als historyLimit löscht Chaos Mesh älteste Tasks chronologisch. Laufende Tasks werden übersprungen und nicht entfernt.

concurrencyPolicy-Feld​

Die möglichen Werte für dieses Feld sind "Forbid", "Allow" und "".

Dieses Feld legt fest, ob dieses Schedule-Objekt mehrere gleichzeitige Experimente erstellen darf. Beispiel: Mit der Konfiguration schedule: * * * * * wird jede Minute ein Experiment erstellt. Wenn die duration des Experiments auf 70 Sekunden eingestellt ist, werden mehrere Experimente gleichzeitig erstellt.

Standardmäßig ist das Feld concurrencyPolicy auf Forbid gesetzt, was bedeutet, dass mehrere Experimente nicht gleichzeitig erstellt werden dürfen. Wenn Sie den Wert des Felds concurrencyPolicy auf Allow setzen, dürfen mehrere Experimente gleichzeitig erstellt werden.

Die folgende Konfiguration verwendet weiterhin das Verzögerungsexperiment als Beispiel:

spec:
  schedule: '* * * * *'
  type: 'NetworkChaos'
  networkChaos:
    action: delay
    mode: one
    selector:
      namespaces:
        - default
      labelSelectors:
        'app': 'web-show'
    delay:
      latency: '10ms'
    duration: '70s'

Basierend auf dieser Konfiguration: Wenn Sie concurrencyPolicy: "Allow" setzen, gibt es in 10 Sekunden jeder Minute eine Verzögerung von 20 Millisekunden. In den restlichen 50 Sekunden gibt es eine Verzögerung von 10 Millisekunden. Wenn Sie concurrencyPolicy: "Forbid" setzen, gibt es durchgehend eine Verzögerung von 10 Millisekunden.

Hinweis

Nicht alle Experimenttypen unterstützen mehrere Experimente auf demselben Pod. Einzelheiten entnehmen Sie bitte der Dokumentation der jeweiligen Experimenttypen.

startingDeadlineSeconds-Feld​

Der Standardwert von startingDeadlineSeconds ist nil.

Wenn startingDeadlineSeconds auf nil gesetzt ist, prüft Chaos Mesh, ob seit der letzten Planung bis jetzt Experimente verpasst wurden (dies kann passieren, wenn Sie Chaos Mesh schließen, den Zeitplan lange anhalten oder concurrencyPolicy auf Forbid setzen).

Wenn startingDeadlineSeconds gesetzt ist und größer als 0, prüft Chaos Mesh, ob in den letzten startingDeadlineSeconds Sekunden ab dem aktuellen Zeitpunkt Experimente verpasst wurden. Wenn der Wert von startingDeadlineSeconds zu klein ist, können einige Experimente verpasst werden. Beispiel:

spec:
  schedule: '* * * * *'
  type: 'NetworkChaos'
  networkChaos:
    action: delay
    mode: one
    selector:
      namespaces:
        - default
      labelSelectors:
        'app': 'web-show'
    startingDeadlineSeconds: 5
    delay:
      latency: '10ms'
    duration: '70s'

Im obigen Beispiel ist, weil concurrencyPolicy auf Forbid gesetzt ist, die Erstellung neuer Aufgaben zu Beginn der Minute verboten. Und in der zehnten Sekunde dieser Minute ist das zuletzt erstellte Chaos-Experiment beendet. Aufgrund der Grenzen von startingDeadlineSeconds und der Einstellung von concurrencyPolicy werden die verpassten Ereignisse nicht nachgeholt und es werden keine Chaos-Experimente erstellt. Ein neues Chaos-Experiment wird erst zu Beginn der nächsten Minute erstellt.

Wenn startingDeadlineSeconds nicht gesetzt ist (oder auf nil gesetzt), gibt es durchgehend eine Verzögerung von 10 Millisekunden. Das liegt daran, dass Chaos Mesh nach Abschluss der laufenden Aufgabe eine zuvor verpasste Aufgabe findet (weil concurrencyPolicy auf Forbid gesetzt ist) und sofort eine neue Aufgabe erstellt.

Weitere Beispiele und ähnliche Erklärungen zu diesem Feld finden Sie in der Dokumentation zu Kubernetes CronJob.

Experimente definieren​

Um den spezifischen Inhalt des Experiments zu definieren, müssen Sie zwei Felder in Schedule angeben: type und *Chaos. Das Feld type legt den Typ eines Experiments fest, und das Feld *Chaos beschreibt den Inhalt des Experiments. Normalerweise verwendet der Inhalt des type-Felds Upper Camel Case, zum Beispiel: NetworkChaos, PodChaos, IOChaos. Der Schlüssel für *Chaos verwendet dagegen Lower Camel Case, wie networkChaos, podChaos und ioChaos. Der Schlüssel *Chaos ist die spec des entsprechenden Experimenttyps. Einzelheiten entnehmen Sie bitte der Dokumentation der jeweiligen Experimenttypen.

Planungsregeln mit Chaos Dashboard erstellen​

  1. Öffnen Sie Chaos Dashboard und klicken Sie auf der Seite auf NEW EXPERIMENT, um ein neues Experiment zu erstellen.

    Plan erstellen
    Plan erstellen

  2. Wählen Sie die spezifischen Details des Experiments aus und füllen Sie sie aus.

    Auswahl und Eingabe der Details
    Auswahl und Eingabe der Details

  3. Tragen Sie Informationen wie den Planungszyklus und die Parallelisierungsstrategie ein.

    Planungsregeln festlegen
    Planungsregeln festlegen

  4. Übermitteln Sie die Experimentinformationen.

Geplante Aufgabe pausieren​

Im Gegensatz zu CronJob unterbricht das Pausieren von Schedule nicht nur die Erstellung neuer Experimente, sondern hält auch bereits erstellte Experimente an.

Wenn Sie vorübergehend kein Chaos-Experiment als geplante Aufgabe erstellen möchten, müssen Sie die Annotation experiment.chaos-mesh.org/pause=true zum Schedule-Objekt hinzufügen. Dies können Sie mit dem kubectl-Befehl erreichen:

kubectl annotate -n $NAMESPACE schedule $NAME experiment.chaos-mesh.org/pause=true

Hierbei ist $NAMESPACE der Namespace und $NAME der Name des Schedule-Objekts. Bei Erfolg wird folgendes Ergebnis zurückgegeben:

schedule/$NAME annotated

Um die Pausierung aufzuheben, können Sie die Annotation mit diesem Befehl entfernen:

kubectl annotate -n $NAMESPACE schedule $NAME experiment.chaos-mesh.org/pause-

Hierbei ist $NAMESPACE der Namespace und $NAME der Name des Schedule-Objekts. Bei Erfolg wird folgendes Ergebnis zurückgegeben:

schedule/$NAME annotated