Unterbrechungen von GKE-Knoten verwalten, die nicht live migriert werden

Während des Lebenszyklus eines lang laufenden GKE-Cluster kommt es aufgrund von Infrastrukturunterbrechungen, die von ausgegeben werden, zu regelmäßigen Störungen bei Arbeitslasten. Google Cloud Diese automatischen Ereignisse können als Reaktion auf Planungsentscheidungen (Ereignisse zum vorzeitigen Beenden) oder Knotenupdates auftreten, einschließlich automatischer Knotenupgrades in GKE (Wartungsereignisse) oder der Behebung erkannter Probleme (Beendigungsereignisse).

In diesem Dokument erfahren Sie, was Knotenunterbrechungen in GKE bedeuten, wie Sie Compute Engine-Wartungsbenachrichtigungen beobachten und wie Sie die Auswirkungen von Unterbrechungen auf Ihre GKE-Knoten minimieren.

Dieses Dokument gilt für die folgenden Maschinentypen:

Dieses Dokument richtet sich an Plattformadministratoren und ‑Betreiber, die den Lebenszyklus der zugrunde liegenden technischen Infrastruktur verwalten. Weitere Informationen zu gängigen Rollen und Beispiel aufgaben, auf die wir in Google Cloud Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Was bedeutet Infrastrukturunterbrechung in GKE?

Ihre GKE-Cluster verwalten den Lebenszyklus der GKE-Knoten. Diese Knoten werden auf Compute Engine-VMs bereitgestellt, bei denen es regelmäßig zu den folgenden Unterbrechungen kommt:

  • Behebung erkannter Probleme (TerminationEvent): Diese Ereignisse treten auf, weil Google Cloud ein Problem erkennt und Ihre Cluster infrastruktur unterbricht. TerminationEvent-Ereignisse unterstützen keine ordnungsgemäße Beendigung. TerminationEvent-Ereignisse werden durch die folgenden Probleme ausgelöst:

    • Die automatische Reparatur erfolgt, wenn GKE einen Knoten nach wiederholten fehlgeschlagenen Systemdiagnosen repariert.
    • HostError tritt auf, wenn ein Hardware- oder Softwarefehler auf der physischen Maschine dazu führt, dass die VM beendet wird.

  • Wartungs- oder Upgradeereignisse (MaintenanceEvent): Diese Ereignisse treten auf, wenn Google Cloud eine VM unterbrochen werden muss, um Wartungsarbeiten durchzuführen. MaintenanceEvent-Ereignisse werden durch die folgenden Wartungsaufgaben ausgelöst:

    • Wartungs ereignisse treten auf, wenn Google Cloud den zugrunde liegenden Host aktualisiert.
    • Knotenupdates, einschließlich automatischer Knotenupgrades, treten auf, wenn GKE die Konfiguration des Knotens aktualisiert, z. B. die GKE-Version.

    Weitere Informationen dazu, wie Sie und GKE Änderungen während des Lebenszyklus eines Clusters verwalten, finden Sie unter Arten von Änderungen.

  • Reaktion auf Planungsentscheidungen (PreemptionEvent): treten auf, wenn Google Cloud VMs vorzeitig beendet werden müssen, um Kapazität für Ressourcen mit höherer Priorität freizugeben. PreemptionEvent -Ereignisse können Folgendes sein:

    • Bereinigung:tritt auf, wenn eine vorzeitig beendbare oder Spot-Infrastruktur vorzeitig beendet wird, um eine VM mit höherer Priorität aufzunehmen.
    • Defragmentierung:tritt auf, wenn GKE einen kleineren TPU-Slice vorzeitig beendet, um einen größeren TPU-Slice aufzunehmen. Die Defragmentierung erfolgt nur bei TPU-Slices.

Während des Lebenszyklus eines lang laufenden GKE-Cluster kann es bei den Knoten zu regelmäßigen Störungen bei Arbeitslasten kommen. Wenn diese Störungen die GKE-Knoten betreffen, auf denen Ihre Arbeitslasten ausgeführt werden, muss GKE sowohl die laufenden Arbeitslasten als auch den zugrunde liegenden Knoten neu starten.

Warum Knoten ohne Live-Migration eine Störungsverwaltung erfordern

Bei den meisten Compute Engine-VMs ist die Hostwartungsrichtlinie auf Live-Migration festgelegt. Das bedeutet, dass laufende Arbeitslasten nur selten oder gar nicht unterbrochen werden. Bestimmte VM-Klassen unterstützen jedoch keine Live-Migration, einschließlich VMs mit angehängten GPUs und TPUs, Z3-Maschinentypen mit mehr als 18 TiB SSD, H4D-Maschinentypen und dem Maschinentyp c4a-highmem-96-metal (Vorschau). Wenn beispielsweise ein Hostereignis für die VM in einem TPU-Slice auftritt, wird der gesamte Slice unterbrochen und dann neu geplant, da alle Wartungsereignisse auf Slice-Ebene koordiniert werden. Wenn Sie also einen TPU-Slice mit Hunderten von VMs erstellen, erhalten alle diese VMs denselben Wartungsereigniszeitplan.

Wenn ein Hostereignis eintritt, beendet GKE den Knoten und seine Pods. Wenn die Pods als Teil einer größeren Arbeitslast wie eines Jobs oder Deployments, bereitgestellt werden, startet GKE die Pods auf dem betroffenen Knoten neu.

Es liegt an Ihnen oder den von Ihnen verwendeten Frameworks, die Arbeitslastkonfiguration so zu verwalten, dass Sie angemessen auf Wartungsereignisse reagieren können. So können Sie beispielsweise den Status Ihres KI-Trainingsjobs speichern, um Datenverluste zu reduzieren.

So verwalten Sie Unterbrechungen bei Ihren Arbeitslasten:

Knotenunterbrechungen beobachten

Der folgende GKE-Systemmesswert gibt die Anzahl der Unterbrechungen für einen GKE-Knoten seit der letzten Stichprobe an (der Messwert wird alle 60 Sekunden abgerufen):

  • kubernetes.io/node/interruption_count

Die Felder interruption_type (z. B. TerminationEvent, MaintenanceEvent oder PreemptionEvent) und interruption_reason (z. B. HostError, Eviction oder AutoRepair) können Aufschluss darüber geben, warum ein Knoten unterbrochen wurde.

Verwenden Sie die folgende PromQL-Abfrage, um eine Aufschlüsselung der Unterbrechungen und ihrer Ursachen in TPU-Knoten in den Clustern Ihres Projekts zu erhalten:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

Wenn Sie nur die Hostwartungsereignisse sehen möchten, aktualisieren Sie die Abfrage, um den HW/SW Maintenance Wert für die interruption_reason zu filtern. Verwenden Sie die folgende PromQL-Abfrage:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

Verwenden Sie die folgende PromQL-Abfrage, um die Anzahl der Unterbrechungen nach Knotenpool aggregiert zu sehen:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

Wartungsbenachrichtigungen beobachten

Compute Engine issues Benachrichtigungen aus, wenn Knoten und die zugrunde liegenden VMs für störende Hostereignisse, geplant sind und wenn diese Ereignisse aktiv werden. Die Benachrichtigungen enthalten Informationen zur geplanten Startzeit, zum Ereignistyp und weitere Details.

In GKE-Version 1.31.1-gke.2008000 und höher können Sie bevorstehende Wartungsereignisse beobachten, einschließlich der in diesem Abschnitt beschriebenen Ereignisse.

Sie können bevorstehende Ereignisse mit den folgenden Maschinentypen und GKE-Versionen beobachten:

  • Für Maschinentypen mit angehängten GPUs oder TPUs: 1.31.1-gke.2008000 oder höher
  • Für Z3-Maschinentypen mit mehr als 18 TiB SSD: 1.32.4-gke.1376000 oder höher
  • Für H4D-Maschinentypen: 1.32.6-gke.1060000 oder höher
  • Für c4a-highmem-96-metal (Vorschau): 1.35.0-gke.2232000 oder höher

Bevorstehende Wartung ist geplant, aber nicht aktiv

Bevor ein Wartungsereignis für eine VM geplant ist, sendet Compute Engine Benachrichtigungen an alle VMs. In diesen Benachrichtigungen wird der Beginn des Compute Engine-Wartungsfensters gemeldet. Wenn eine bevorstehende Wartung von der VM geplant, aber nicht aktiv ist, fügt GKE dem Knotenlabel scheduled-maintenance-time hinzu.

Führen Sie den folgenden Befehl aus, um diese Benachrichtigungen auf Knotenebene abzufragen:

kubectl get nodes -l cloud.google.com/scheduled-maintenance-time \
    -L cloud.google.com/scheduled-maintenance-time

Die Ausgabe sieht etwa so aus:

NAME                         STATUS    SCHEDULED-MAINTENANCE-TIME
<gke-accelerator-node-name>  Ready     1733083200
<gke-accelerator-node-name>  Ready     1733083200
[...]

Die Spalte SCHEDULED-MAINTENANCE-TIME steht für Sekunden, die im Unix-Epochenzeitformat angezeigt werden.

Wenn Sie diese Benachrichtigungen auf der Ebene der Knotenmetadaten abfragen möchten, suchen Sie in den Instanzen nach einer Benachrichtigung über ein Wartungsereignis benachrichtigung.

Für beschleunigungsoptimierte Maschinenfamilien, die erweiterte Wartungunterstützen, können Sie auf den upcoming-maintenance Endpunkt zugreifen, der Informationen zu geplanten und gestarteten Wartungsereignissen enthält.

Auswirkungen von Unterbrechungen minimieren

Compute Engine gibt Benachrichtigungen über bevorstehende Wartungsereignisse aus und plant ein Wartungsfenster. Zwischen dem Zeitpunkt der Benachrichtigung und dem Beginn des Wartungsfensters haben Sie folgende Möglichkeiten:

  • Hostwartungsereignis manuell starten
  • Compute Engine das Wartungsereignis planmäßig starten lassen

GKE unterstützt die ordnungsgemäße Beendigung von Pods während Hostwartungsereignissen. In den neuesten Versionen von GKE ist diese Funktion standardmäßig deaktiviert. Wenn Sie diese Funktion verwenden möchten, müssen Sie die Störungsbehandlung manuell aktivieren. Weitere Informationen finden Sie unter Störungsbehandlung aktivieren.

Hostwartungsereignis manuell starten

Sie können die neu planbare Wartung manuell starten, wenn es in Ihren Zeitplan passt, z. B. in Zeiten geringer Aktivität. Wenden Sie dazu das Label cloud.google.com/perform-maintenance=true an, wenn die folgenden Bedingungen erfüllt sind:

  • Compute Engine gibt eine Benachrichtigung über ein geplantes Wartungsereignis aus.
  • Das zugrunde liegende Compute Engine-Wartungsereignis kann neu geplant werden. Ob das Ereignis neu geplant werden kann, erkennen Sie an der can_reschedule=TRUE Benachrichtigung in den Ereignismetadaten. Wenn das Ereignis nicht neu geplant werden kann, hat das Festlegen des Labels cloud.google.com/perform-maintenance=true keine Auswirkungen und die Wartung erfolgt zum ursprünglich geplanten Zeitpunkt.

Wenn die oben genannten Bedingungen erfüllt sind, legen Sie für einen Knoten im Knotenpool das Knotenlabel cloud.google.com/perform-maintenance auf true fest. Beispiel:

kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true

Wenn Sie ein Wartungsereignis starten, führt GKE die folgenden Vorgänge aus:

  1. Der Knoten wird markiert.
  2. Pods werden ordnungsgemäß entfernt.
  3. Compute Engine wird aufgefordert, das Wartungsereignis sofort zu starten, anstatt auf den geplanten Zeitpunkt zu warten.

Compute Engine startet das Wartungsereignis planmäßig

Wenn Sie kein Hostwartungsereignis starten, startet Compute Engine das geplante Wartungsereignis selbst. Ab GKE-Version 1.33 wird der Knoten nicht markiert und Pods werden nicht entfernt, wenn das Wartungsfenster beginnt.

Wenn das Wartungsereignis beginnt, kann ein Knoten ein- oder mehrmals mit einer kurzen Benachrichtigungszeit vor der bevorstehenden Beendigung heruntergefahren werden. In diesen Fällen unternimmt GKE alles, um Arbeitslasten zu beenden und ordnungsgemäß Pods zu entfernen.

Geplante Wartung beginnt

Wenn die geplante Wartung beginnt, aktualisiert Compute Engine die Metadaten im Verzeichnis http://metadata.google.internal/computeMetadata/v1/instance/attributes/. Compute Engine aktualisiert die Metadatenlabels so:

  • maintenance-event wird auf TERMINATE_ON_HOST_MAINTENANCE festgelegt.
  • In upcoming-maintenance wird maintenance_status auf ONGOING festgelegt.

GKE erkennt und verarbeitet das geplante Hostwartungsereignis, unabhängig davon, ob Sie es manuell auslösen oder GKE automatisch vorgehen lassen.

Störungsbehandlung aktivieren

apiVersion: v1
kind: ConfigMap
metadata:
  name: gke-disruption-handling
  namespace: kube-system
data:
  maintenance-experience.yaml: |
    gracefulTermination: true

Erstellen Sie eine Datei mit dem Namen maintenance-config.yaml mit dieser ConfigMap, um die Störungsbehandlung zu aktivieren. Wenden Sie die ConfigMap mit dem folgenden Befehl auf den Cluster an: 

kubectl apply -f my-configmap.yaml

GKE so konfigurieren, dass Arbeitslasten ordnungsgemäß beendet werden

In diesem Abschnitt konfigurieren Sie GKE, um den Anwendungslebenszyklus zu verwalten und Störungen Ihrer Arbeitslast zu minimieren. Wenn Sie keinen Kulanzzeitraum konfigurieren, wird standardmäßig ein Kulanzzeitraum von 30 Sekunden verwendet.

GKE unternimmt alles, um diese Pods ordnungsgemäß zu beenden und die von Ihnen definierte Beendigungsaktion auszuführen, z. B. das Speichern eines Trainingsstatus. GKE sendet zu Beginn des Kulanzzeitraums ein SIGTERM-Signal an Pods. Wenn Pods nicht bis zum Ende des Kulanzzeitraums beendet werden, sendet GKE ein weiteres SIGKILL-Signal an alle Prozesse, die noch in einem Container im Pod ausgeführt werden.

Legen Sie den Kulanzzeitraum für die Beendigung (in Sekunden) im Feld spec.terminationGracePeriodSeconds Ihres Pod-Manifests fest, um den Zeitraum für die ordnungsgemäße Beendigung zu konfigurieren. Wenn Sie beispielsweise eine Benachrichtigungszeit von 10 Minuten erhalten möchten, legen Sie in Ihrem Pod-Manifest das Feld spec.terminationGracePeriodSeconds so auf 600 Sekunden fest:

    spec:
      terminationGracePeriodSeconds: 600

Wir empfehlen, einen Kulanzzeitraum für die Kündigung festzulegen, der lang genug ist, damit alle laufenden Aufgaben innerhalb des Benachrichtigungszeitraums abgeschlossen werden können. Wenn Ihre Arbeitslast ein ML-Framework wie MaxText, Pax oder JAX mit Orbax verwendet, können die Arbeitslasten das Herunterfahren SIGTERM Signal erfassen und einen Prüfpunktprozess initiieren. Weitere Informationen finden Sie unter TPU-Autoprüfpunkt.

Prozess der ordnungsgemäßen Beendigung

Wenn ein manuell gestartetes Wartungsereignis beginnt, signalisiert Compute Engine das bevorstehende Herunterfahren der Maschine, indem der Metadatenschlüssel maintenance-event aktualisiert wird. GKE startet die ordnungsgemäße Beendigung.

Der folgende Workflow zeigt, wie GKE die ordnungsgemäße Knotenbeendigung ausführt, wenn ein bevorstehendes Herunterfahren des Knotens ansteht:

  1. Innerhalb von 60 Sekunden geschieht Folgendes:
    1. Die Systemkomponenten wenden das Knotenlabel cloud.google.com/active-node-maintenance mit dem Wert ONGOING an, um anzugeben, dass Arbeitslasten beendet werden.
    2. GKE wendet die Knotenmarkierung an, um zu verhindern, dass neue Pods auf dem Knoten geplant werden. Die Markierung hat den Schlüssel cloud.google.com/impending-node-termination:NoSchedule. Wir empfehlen , Ihre Arbeitslasten nicht so zu ändern, dass sie diese Markierung aufgrund der bekannten Beendigung tolerieren.
  2. Die Komponente für die Wartungsbehandlung beginnt, Pods zu entfernen. Zuerst werden Arbeitslast-Pods und dann System-Pods entfernt (z. B. kube-system).
  3. GKE sendet ein SIGTERM-Shutdown-Signal an Arbeitslast-Pods, die auf dem Knoten ausgeführt werden, um sie über ein bevorstehendes Herunterfahren zu informieren. Pods können mit dieser Benachrichtigung alle laufenden Aufgaben durchführen. GKE unternimmt alles, um diese Pods ordnungsgemäß zu beenden.
  4. Nach Abschluss der Bereinigung aktualisiert GKE den Wert des Labels cloud.google.com/active-node-maintenance auf terminating, um anzugeben, dass der Knoten bereit ist, beendet zu werden.

Anschließend wird der Knoten beendet und ein Ersatzknoten zugewiesen. GKE löscht die Labels und Markierungen, wenn der Vorgang abgeschlossen ist. Führen Sie die Schritte im Abschnitt Hostwartungsereignis manuell starten aus, um das Beendigungsfenster für Ihre Arbeitslasten mit GPUs oder TPUs zu erhöhen.

Fortschritt einer aktiven ordnungsgemäßen Beendigung beobachten

Sie können die GKE-Logs nach den folgenden Ereignissen für die ordnungsgemäße Beendigung filtern:

  • Wenn die VM eine Störung aufgrund einer bevorstehenden Knotenbeendigung erkennt, z. B. ein Compute Engine-Hostwartungsereignis, legt GKE cloud.google.com/active-node-maintenance auf ONGOING fest, wenn Arbeitslasten beendet werden, und auf terminating, wenn die Arbeitslasten beendet sind und der Knoten bereit ist, beendet zu werden.
  • Wenn die Planung neuer Arbeitslasten eingeschränkt wird, wendet GKE die Markierung cloud.google.com/impending-node-termination:NoSchedule an.

Unterbrechungen laufender Arbeitslasten mit opportunistischer Wartung minimieren

Sie können die Unterbrechung laufender Arbeitslasten minimieren, indem Sie die Wartung automatisch auslösen, wenn GKE erkennt, dass Knoten mit GPUs oder TPUs im Leerlauf sind. Erstellen Sie einen neuen Knotenpool, um diese Funktion zu aktivieren. Die opportunistische Wartung kann nicht für einen vorhandenen Knotenpool aktiviert werden.

Neuen Knotenpool mit opportunistischer Wartung erstellen

Der folgende Befehl zeigt, wie Sie einen Knotenpool mit aktivierter opportunistischer Wartung erstellen:

gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --accelerator ACCELERATOR_ARG \
    --machine-type MACHINE_TYPE \
    --num-nodes NODE_COUNT \
    --zone ZONE \
    --project=PROJECT_ID \
    --opportunistic-maintenance=node-idle-time=NODE_IDLE_TIME,min-nodes=MIN_NODES,window=WINDOW

Ersetzen Sie die folgenden Werte:

  • NODE_POOL_NAME: der Name Ihres GKE-Knotenpools.
  • CLUSTER_NAME : der Name Ihres GKE-Cluster.
  • NODE_IDLE_TIME : die Zeit, die ein Knoten im Leerlauf bleiben kann (d. h. es werden keine Arbeitslasten ausgeführt, die Beschleuniger verwenden), bevor die Wartung ausgelöst wird. Der Wert stellt die Dauer in Sekunden mit bis zu neun Nachkommastellen dar und endet mit dem s Zeichen, z. B. 80000s.
  • MIN_NODES : die Mindestanzahl von Knoten, die in einem Knotenpool verfügbar sein müssen. Diese Option blockiert die Wartung, wenn dadurch die Anzahl der ausgeführten Knoten unter diesen Wert sinkt, z. B. 10.
  • WINDOW : das Zeitfenster in Sekunden, in dem die opportunistische Wartung ausgeführt werden kann. Der Wert endet mit dem Zeichen s. Ein Wert von 14 Tagen oder 1209600s bedeutet beispielsweise, dass die opportunistische Wartung nur in den zwei Wochen vor dem geplanten Wartungstermin ausgeführt werden kann. Ein Wert von 28 Tagen oder 2419200s ermöglicht die Ausführung der opportunistischen Wartung jederzeit während des geplanten Wartungsfensters. Dieses Fenster für die Compute Engine-Hostwartung unterscheidet sich von den GKE-Wartungsfenstern, die festlegen, wann die GKE-Clusterwartung erfolgen kann, und separat konfiguriert werden.

Beispielkonfiguration für die opportunistische Wartung

Dazu ein Beispiel: Sie haben einen Knotenpool mit vier Knoten und die Konfiguration für die opportunistische Wartung ist auf --opportunistic-maintenance=node-idle-time=600s,window=2419200s,min-nodes=3 festgelegt. In diesem Szenario geschieht Folgendes:

  • Auf node1 wird eine GPU-Arbeitslast ausgeführt. Dieser Knoten ist nicht im Leerlauf und wird daher übersprungen.
  • node2 ist seit 60 Sekunden im Leerlauf. Dieser Knoten ist nicht lange genug im Leerlauf und wird daher übersprungen.
  • node3 ist seit 600 Sekunden im Leerlauf. Dieser Knoten erfüllt die Anforderung für den Leerlauf.
  • node4 ist seit 600 Sekunden im Leerlauf. Dieser Knoten erfüllt die Anforderung für den Leerlauf.

Sowohl node3 als auch node4 erfüllen die Anforderung für den Leerlauf. Allerdings löst nur einer dieser Knoten die opportunistische Wartung aus, da der Wert der Option min-nodes auf 3 festgelegt ist.

Konfiguration und Status von Knoten mit opportunistischer Wartung prüfen

Prüfen Sie mit dem folgenden Befehl, ob die opportunistische Wartung für einen Knoten konfiguriert ist:

kubectl describe node NODE_NAME | grep node.gke.io/opportunistic-config

Ersetzen Sie NODE_NAME durch den Namen des Knotens, den Sie prüfen möchten.

Prüfen Sie, ob ein Knoten, der mit opportunistischer Wartung konfiguriert ist, derzeit gewartet wird:

kubectl describe node NODE_NAME | grep node.gke.io/maintenance-state

Wenn der Knoten durch die opportunistische Wartung ausgelöst wird, wird in der Annotation maintenance-state für opportunistic-triggered der Wert true angezeigt.

Beschränkungen

Beachten Sie die folgenden Einschränkungen der opportunistischen Wartung:

  • Diese Funktion kann nur mit GPU- und TPU-Knotenpools verwendet werden.
  • Die opportunistische Wartung ist nicht mit dem Cluster Autoscaler kompatibel, da der Cluster Autoscaler bereits im Leerlauf befindliche Knoten herunterskaliert.
  • Bei TPU-Knotenpools mit mehreren Hosts muss der Wert der Einstellung min-nodes-per-pool 0 sein, da diese Knotenpools atomar sind.
  • Die mindestens unterstützte GKE-Version ist 1.33.3-gke.1118000.
  • Es wird nur die geplante Wartung unterstützt, die die can_reschedule=TRUE Benachrichtigung enthält.
  • Wenn Sie diese Funktion deaktivieren möchten, müssen Sie den Knotenpool ohne die entsprechenden Flags neu erstellen. Alternativ können Sie die Funktion mit cloud.google.com/opportunistic-disable=true manuell auf bestimmten Knoten deaktivieren.
  • In seltenen Fällen kann die Wartung auf einem Knoten länger dauern. Kunden, die diese Funktion verwenden, haben möglicherweise für einen bestimmten Zeitraum weniger verfügbare Knoten, bis hin zum Wert der Einstellung min-nodes-per-pool.

Nächste Schritte