Freigeben über

Anwendungsbereitstellungen mit GitOps (Flux v2) für AKS und Azure Arc-fähiges Kubernetes

  • Artikel

Azure bietet eine Funktion zur automatisierten Anwendungsbereitstellung mit GitOps, die mit Azure Kubernetes Service (AKS) und Kubernetes-Clustern mit Azure Arc-Unterstützung arbeitet. Zu den wichtigsten Vorteilen des Einsatzes von GitOps für die Bereitstellung von Anwendungen in Kubernetes-Clustern gehören:

  • Kontinuierlicher Einblick in den Status von Anwendungen, die auf Clustern laufen.
  • Trennung der Belange von Anwendungsentwicklungsteams und Infrastrukturteams. Anwendungsteams müssen keine Erfahrung mit Kubernetes-Bereitstellungen haben. Plattformentwicklungsteams schaffen in der Regel ein Selbstbedienungsmodell für Anwendungsteams, das ihnen die Möglichkeit gibt, Implementierungen mit größerer Sicherheit durchzuführen.
  • Möglichkeit der Wiederherstellung von Clustern mit demselben gewünschten Zustand im Falle eines Absturzes oder zur Skalierung.

Mit GitOps deklarieren Sie den gewünschten Zustand Ihrer Kubernetes-Cluster in Dateien in Git-Repositorys. Die Git-Repositorys können die folgenden Dateien enthalten:

Da diese Dateien in einem Git-Repository gespeichert werden, werden sie mit Versionsinformationen verwaltet, und Änderungen zwischen Versionen können leicht nachverfolgt werden. Kubernetes-Controller werden in den Clustern ausgeführt und stimmen den Clusterzustand kontinuierlich mit dem gewünschten Zustand ab, der im Git-Repository deklariert ist. Diese Operatoren ruft die Dateien aus den Git-Repositorys ab und wenden den gewünschten Zustand auf die Cluster an. Die Operatoren stellen außerdem kontinuierlich sicher, dass sich der Cluster im gewünschten Zustand befindet.

GitOps auf Azure Arc aktivierten Kubernetes oder Azure Kubernetes Service verwendet Flux, ein beliebtes Open-Source-Toolset. Flux bietet Unterstützung für gängige Dateiquellen (Git- und Helm-Repositorys, Buckets, Azure Blob Storage) und Vorlagentypen (YAML, Helm und Kustomize). Flux unterstützt unter anderem auch die Mehrmandanz- und Bereitstellungsabhängigkeitsverwaltung.

Flux wird direkt auf dem Cluster eingesetzt, und die Steuerungsebene der einzelnen Cluster ist logisch getrennt. Daher kann es gut auf Hunderten und Tausenden von Clustern skaliert werden. Flux ermöglicht rein Pull-basierte GitOps-Anwendungsbereitstellungen. Weder das Quell-Repository noch ein anderes Cluster benötigt Zugriff auf die Cluster.

Flux-Clustererweiterung

GitOps wird in einem Azure Arc-fähigen Kubernetes- oder AKS-Cluster als Microsoft.KubernetesConfiguration/extensions/microsoft.flux-Clustererweiterungsressource aktiviert. Die microsoft.flux Erweiterung muss im Cluster installiert werden, bevor eine oder mehrere fluxConfigurations erstellt werden können. Die Erweiterung wird automatisch installiert, wenn Sie die ersten Microsoft.KubernetesConfiguration/fluxConfigurations in einem Cluster erstellen. Alternativ können Sie sie manuell über das Portal, die Azure CLI (az k8s-extension create --extensionType=microsoft.flux), eine ARM-Vorlage oder REST-API installieren.

Controller

Standardmäßig installiert die microsoft.flux-Erweiterung die Flux-Controller (Source, Kustomize, Helm, Notification) und die FluxConfig Custom Resource Definition (CRD), fluxconfig-agent und fluxconfig-controller. Optional können Sie auch den Flux image-automation- und image-reflector-Controller installieren, die Funktionen zum Aktualisieren und Abrufen von Docker-Images bereitstellen.

  • Flux-Quellcodeverwaltung: Überwacht die source.toolkit.fluxcd.io benutzerdefinierten Ressourcen. Übernimmt die Synchronisierung zwischen den Git-Repositorys, Helm-Repositorys, Buckets und Azure Blob Storage. Behandelt die Autorisierung mit der Quelle für private Git- und Helm-Repositorys und Azure Blob Storage-Konten. Gibt die neuesten Änderungen an der Quelle über eine TAR-Archivdatei an.

  • Flux Kustomize-Controller: Überwacht die kustomization.toolkit.fluxcd.io benutzerdefinierten Ressourcen. Wendet Kustomize- oder unformatierte YAML-Dateien aus der Quelle auf den Cluster an.

  • Flux Helm-Controller: Überwacht die helm.toolkit.fluxcd.io benutzerdefinierten Ressourcen. Ruft das zugeordnete Diagramm aus der Helm-Repositoryquelle ab, die vom Quellcontroller angezeigt wird. Erstellt die HelmChart benutzerdefinierte Ressource und wendet die HelmRelease mit der angegebenen Version, dem angegebenen Namen und den vom Kunden definierten Werten auf den Cluster an.

  • Flux Notification-Controller: Überwacht die notification.toolkit.fluxcd.io benutzerdefinierten Ressourcen. Empfängt Benachrichtigungen von allen Flux-Controllern. Pushbenachrichtigungen an benutzerdefinierte Webhookendpunkte.

  • Flux Benutzerdefinierte Ressourcendefinitionen:

    • kustomizations.kustomize.toolkit.fluxcd.io
    • imagepolicies.image.toolkit.fluxcd.io
    • imagerepositories.image.toolkit.fluxcd.io
    • imageupdateautomations.image.toolkit.fluxcd.io
    • alerts.notification.toolkit.fluxcd.io
    • providers.notification.toolkit.fluxcd.io
    • receivers.notification.toolkit.fluxcd.io
    • buckets.source.toolkit.fluxcd.io
    • gitrepositories.source.toolkit.fluxcd.io
    • helmcharts.source.toolkit.fluxcd.io
    • helmrepositories.source.toolkit.fluxcd.io
    • helmreleases.helm.toolkit.fluxcd.io
    • fluxconfigs.clusterconfig.azure.com

  • FluxConfig CRD: Benutzerdefinierte Ressourcendefinition für fluxconfigs.clusterconfig.azure.com benutzerdefinierte Ressourcen, die FluxConfig Kubernetes-Objekte definieren.

  • fluxconfig-agent: Zuständig für die Azure-Suche nach neuen oder aktualisierten fluxConfigurations Ressourcen und für das Starten der zugeordneten Flux-Konfiguration im Cluster. Außerdem ist dafür verantwortlich, Flux-Statusänderungen im Cluster für jede fluxConfigurations Ressource zurück an Azure zu pushen.

  • fluxconfig-controller: Überwacht die fluxconfigs.clusterconfig.azure.com benutzerdefinierten Ressourcen und reagiert auf Änderungen mit einer neuen oder aktualisierten Konfiguration von GitOps-Maschinen im Cluster.

Hinweis

Die microsoft.flux Erweiterung wird im flux-system-Namespace installiert und verfügt über einen clusterweiten Umfang. Sie können diese Erweiterung nicht im Namespacebereich installieren.

Flux-Konfigurationen

Das Diagramm zeigt die Installation einer Flux-Konfiguration in einem Azure Arc aktivierten Kubernetes- oder AKS.

Sie erstellen Flux-Konfigurationsressourcen (Microsoft.KubernetesConfiguration/fluxConfigurations), um die GitOps-Verwaltung des Clusters aus Ihren Git-Repositorys, Bucketquellen oder Azure Blob Storage zu ermöglichen. Wenn Sie eine fluxConfigurations Ressource erstellen, werden die Werte, die Sie für die Parameter bereitstellen, z. B. das Git-Ziel-Repository, verwendet, um die Kubernetes-Objekte zu erstellen und zu konfigurieren, die den GitOps-Prozess in diesem Cluster ermöglichen. Um die Datensicherheit zu gewährleisten, werden die fluxConfigurations Ressourcendaten verschlüsselt im Ruhezustand vom Cluster-Konfigurationsdienst in einer Azure Cosmos DB-Datenbank gespeichert.

Die fluxconfig-agent und fluxconfig-controller Agents, die mit der Erweiterung microsoft.flux installiert wurden, verwalten den GitOps-Konfigurationsprozess.

fluxconfig-agent ist für folgende Aufgaben verantwortlich:

  • Fragt den Kubernetes Configuration-Datenebenendienst nach neuen oder aktualisierten fluxConfigurations Ressourcen ab.
  • Erstellt oder aktualisiert FluxConfig benutzerdefinierte Ressourcen im Cluster mit den Konfigurationsinformationen.
  • Überwacht FluxConfig benutzerdefinierte Ressourcen und pusht Statusänderungen zurück an die zugeordneten Azure fluxConfiguration-Ressourcen.

fluxconfig-controller ist für folgende Aufgaben verantwortlich:

  • Überwacht Statusaktualisierungen der von der verwalteten erstellten benutzerdefinierten fluxConfigurations Flux-Ressourcen.
  • Erstellt ein privates/öffentliches Schlüsselpaar, das für die Lebensdauer von fluxConfigurations vorhanden ist. Dieser Schlüssel wird für die Authentifizierung verwendet, wenn die URL SSH-basiert ist und der Benutzer während der Erstellung der Konfiguration keinen eigenen privaten Schlüssel bereitstellt.
  • Erstellt ein benutzerdefiniertes Authentifizierungsgeheimnis basierend auf vom Benutzer bereitgestellten Daten vom Datentyp private-key/http basic-auth/known-hosts/no-auth.
  • Richtet die rollenbasierte Zugriffssteuerung ein (Dienstkonto bereitgestellt, Rollenbindung erstellt/zugewiesen, Rolle erstellt/zugewiesen).
  • Erstellt benutzerdefinierte GitRepository- oder Bucket-Ressourcen und benutzerdefinierte Kustomization-Ressourcen aus den Informationen in der benutzerdefinierten FluxConfig-Ressource.

Jede fluxConfigurations-Ressource in Azure wird benutzerdefinierten Flux-Ressource GitRepository oder Bucket und mindestens einer benutzerdefinierten Kustomization-Ressource in einem Kubernetes-Cluster zugeordnet. Wenn Sie eine fluxConfigurations-Ressource erstellen, geben Sie die URL zur Quelle (Git-Repository, Bucket oder Azure Blob Storage) und das Synchronisierungsziel in der Quelle für jede Kustomization-Ressource an. Sie können Abhängigkeiten zwischen Kustomization benutzerdefinierten Ressourcen konfigurieren, um die Bereitstellungssequenzierung zu steuern. Außerdem können Sie mehrere fluxConfigurations-Ressourcen mit Namespaceumfang im selben Cluster für verschiedene Anwendungen und App-Teams erstellen.

Hinweis

fluxconfig-agent überwacht neue oder aktualisierte fluxConfiguration-Ressourcen in Azure. Für den Agent ist eine Verbindung mit Azure erforderlich, damit der gewünschte Zustand des fluxConfiguration auf den Cluster angewendet werden kann. Wenn der Agent keine Verbindung mit Azure herstellen kann, warten Änderungen im Cluster, bis der Agent eine Verbindung herstellen kann. Wenn das Cluster mehr als 48 Stunden lang von Azure getrennt ist, tritt bei der Anforderung an das Cluster ein Timeout auf, und die Änderungen müssen in Azure erneut angewendet werden.

Vertrauliche Kundeneingaben wie private Schlüssel und das Token/Kennwort werden nicht länger als 48 Stunden im Kubernetes Konfigurationsdienst gespeichert. Wenn Sie einen dieser Werte in Azure aktualisieren, stellen Sie sicher, dass Ihre Cluster innerhalb von 48 Stunden eine Verbindung mit Azure herstellen.

Sie können den Status und die Einhaltung der Flux-Konfiguration im Azure-Portal überwachen oder Dashboards verwenden, um den Status, die Einhaltung, den Ressourcenverbrauch und die Abgleichsaktivitäten zu überwachen. Weitere Informationen finden Sie unter Überwachen des Status und er Aktivität von GitOps (Flux v2).

Versionsunterstützung

Die neueste Version der Flux v2-Erweiterung (microsoft.flux) und die beiden vorherigen Versionen (N-2) werden unterstützt. Im Allgemeinen wird empfohlen, die neueste Version der Erweiterung zu verwenden. Ab microsoft.flux Version 1.7.0 werden ARM64-basierte Cluster unterstützt.

Hinweis

Wenn Sie Flux v1 verwendet haben, empfehlen wir, so schnell wie möglich zu Flux v2 zu migrieren.

Die Unterstützung für Flux v1-basierte Clusterkonfigurationsressourcen, die vor dem 1. Januar 2024 erstellt wurden, endet am 24. Mai 2025. Ab dem 1. Januar 2024 können Sie keine neuen Flux v1-basierten Clusterkonfigurationsressourcen mehr erstellen.

Wenn Sie Unterstützung für einen privaten Link zu einem Azure Arc-fähigen Kubernetes-Cluster hinzugefügt haben, funktioniert die microsoft.flux-Erweiterung ohne weitere Konfiguration mit Rückkommunikation zu Azure. Für Verbindungen mit Ihrem Git-Repository, Helm-Repository oder anderen Endpunkten, die zum Bereitstellen Ihrer Kubernetes-Manifeste erforderlich sind, müssen Sie diese Endpunkte hinter Ihrer Firewall bereitstellen oder in Ihrer Firewall auflisten, damit der Flux-Quellcontroller sie erfolgreich erreichen kann.

Datenresidenz

Der Azure GitOps-Dienst (Azure Kubernetes-Konfigurationsverwaltung) speichert/verarbeitet Kundendaten. Standardmäßig werden Kundendaten in die gekoppelte Region repliziert. Für die Regionen „Singapur“, „Asien, Osten“ und „Brasilien, Süden“ werden alle Kundendaten in der Region gespeichert und verarbeitet.

Anwenden von Flux-Konfigurationen im großen Stil

Da Azure Resource Manager Ihre Konfigurationen verwaltet, können Sie mithilfe von Azure Policy im Rahmen eines Abonnements oder einer Ressourcengruppe automatisch dieselbe Konfiguration für alle Azure Kubernetes Service- und Azure Arc-fähigen Kubernetes-Ressourcen erstellen. Diese Erzwingung im großen Stil stellt sicher, dass bestimmte Konfigurationen in ganzen Gruppen von Clustern konsistent angewendet werden.

Weitere Informationen finden Sie unter Konsistentes Bereitstellen von Anwendungen im großen Stil mithilfe von Flux v2-Konfigurationen und Azure Policy.

Parameter

Alle Parameter, die von Flux v2 in Azure unterstützt werden, finden Sie in der az k8s-configuration Dokumentation. Die Azure-Implementierung unterstützt derzeit nicht jeden Parameter, den Flux unterstützt.

Informationen zu verfügbaren Parametern und deren Verwendung finden Sie unter GitOps (Flux v2) unterstützte Parameter.

Mehrinstanzenfähigkeit

Flux v2 unterstützt mehrinstanzenfähige Mandanten ab Version 0.26. Diese Funktion ist in Flux v2 in Azure integriert.

Hinweis

Für die Mehrinstanzenfähigkeit müssen Sie wissen, ob Ihre Manifeste über eine namespaceübergreifende sourceRef für HelmRelease, Kustomization, ImagePolicy oder andere Objekte verfügen, oder ob Sie eine niedrigere Kubernetes-Version als 1.20.6 verwenden. So bereiten Sie sich vor:

  • Führen Sie ein Upgrade auf Kubernetes Version 1.20.6 oder höher durch.
  • Stellen Sie in Ihren Kubernetes-Manifesten sicher, dass alle Quellverweise (sourceRef) für Objekte innerhalb desselben Namespace festgelegt sind, in dem sich auch die GitOps-Konfiguration befindet.
    • Wenn Sie Zeit benötigen, um Ihre Manifeste zu aktualisieren, können Sie die Mehrinstanzenfähigkeit deaktivieren. Sie müssen jedoch weiterhin ein Upgrade Ihrer Kubernetes-Version durchführen.

Aktualisieren von Manifesten für Mehrinstanzenfähigkeit

Angenommen, Sie stellen eine Flux-Konfiguration (fluxConfiguration) in einem Kubernetes-Cluster im Namespace cluster-config mit Clusterbereich bereit. Sie konfigurieren die Quelle für die Synchronisierung des Repositorys https://github.com/fluxcd/flux2-kustomize-helm-example. Dies ist dasselbe Beispiel-Git-Repository, das im Tutorial „Bereitstellen von Anwendungen mithilfe von GitOps mit Flux v2“ verwendet wird.

Nachdem Flux das Projektarchiv synchronisiert hat, stellt es die in den Manifesten (YAML-Dateien) beschriebenen Ressourcen bereit. Zwei der Manifeste beschreiben HelmRelease- und HelmRepository-Objekte.

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx
  namespace: nginx
spec:
  releaseName: nginx-ingress-controller
  chart:
    spec:
      chart: nginx-ingress-controller
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: flux-system
      version: "5.6.14"
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  # Default values
  # https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
  values:
    service:
      type: NodePort

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: flux-system
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami

Standardmäßig stellt die Flux-Erweiterung die fluxConfigurations-Identität des flux-applier-Dienstkontos bereit, das nur im cluster-config-Namespace bereitgestellt wird. Bei Verwendung der oben genannten Manifeste würde HelmRelease bei aktivierter Mehrinstanzenfähigkeit blockiert werden. Dies liegt daran, dass sich die HelmRelease im nginx-Namespace befindet, aber sie verweist auf ein HelmRepository im flux-system-Namespace. Außerdem kann der Flux helm-controller HelmRelease nicht anwenden, da es kein flux-applier-Dienstkonto im nginx-Namespace gibt.

Der richtige Ansatz zur Verwendung von Mehrinstanzenfähigkeit besteht in der Bereitstellung aller Flux-Objekte im gleichen Namespace, in dem sich auch fluxConfigurations befindet. Dadurch wird das Problem mit dem namespaceübergreifenden Verweis vermieden, und die Flux-Controller können die Berechtigungen zum Anwenden der Objekte erhalten. Für eine GitOps-Konfiguration, die im Namespace cluster-config erstellt wurde, würden sich die Beispielmanifeste wie folgt ändern:

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx
  namespace: cluster-config 
spec:
  releaseName: nginx-ingress-controller
  targetNamespace: nginx
  chart:
    spec:
      chart: nginx-ingress-controller
      sourceRef:
        kind: HelmRepository
        name: bitnami
        namespace: cluster-config
      version: "5.6.14"
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  # Default values
  # https://github.com/bitnami/charts/blob/master/bitnami/nginx-ingress-controller/values.yaml
  values:
    service:
      type: NodePort

apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: HelmRepository
metadata:
  name: bitnami
  namespace: cluster-config
spec:
  interval: 30m
  url: https://charts.bitnami.com/bitnami

Deaktivieren der Mehrinstanzenfähigkeit

Wenn die microsoft.flux-Erweiterung installiert ist, ist der mehrinstanzenfähige Mandanten standardmäßig aktiviert. Wenn Sie mehrere Mandanten deaktivieren müssen, können Sie die microsoft.flux-Erweiterung in Ihren Clustern erstellen oder mit --configuration-settings multiTenancy.enforce=false aktualisieren, wie in den folgenden Beispielbefehlen gezeigt:

az k8s-extension create --extension-type microsoft.flux --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>

az k8s-extension update --configuration-settings multiTenancy.enforce=false -c CLUSTER_NAME -g RESOURCE_GROUP -n flux -t <managedClusters or connectedClusters>

Migrieren von Flux v1

Wenn Sie noch Flux v1 verwenden, empfehlen wir Ihnen, so bald wie möglich auf Flux v2 zu migrieren.

Um auf die Verwendung von Flux v2 in denselben Clustern umzusteigen, in denen Sie bisher Flux v1 verwendet haben, müssen Sie zunächst alle Flux v1 sourceControlConfigurations aus den Clustern löschen. Da Flux v2 eine grundlegend andere Architektur hat, kann die microsoft.flux-Cluster-Erweiterung nicht installiert werden, wenn Flux v1 sourceControlConfigurations-Ressourcen in einem Cluster vorhanden sind. Das Entfernen von Flux v1-Konfigurationen und die Bereitstellung von Flux v2-Konfigurationen sollte nicht länger als 30 Minuten dauern.

Das Entfernen von Flux v1 sourceControlConfigurations stoppt keine Anwendungen, die auf den Clustern laufen. Während des Zeitraums, in dem die Flux v1-Konfiguration entfernt wird und die Flux v2-Erweiterung noch nicht vollständig implementiert ist:

  • Wenn es neue Änderungen in den Anwendungsmanifesten gibt, die in einem Git-Repository gespeichert sind, werden diese Änderungen während der Migration nicht übernommen, und die auf dem Cluster bereitgestellte Anwendungsversion ist veraltet.
  • Wenn sich der Zustand des Clusters unbeabsichtigt ändert und von dem im Git-Quellcoderepository angegebenen gewünschten Zustand abweicht, kann sich der Cluster nicht selbst reparieren.

Wir empfehlen, Ihr Migrationsszenario in einer Entwicklungsumgebung zu testen, bevor Sie Ihre Produktionsumgebung migrieren.

Anzeigen und Löschen von Flux v1-Konfigurationen

Verwenden Sie die folgenden Azure CLI-Befehle, um vorhandene sourceControlConfigurations-Ressourcen in einem Cluster zu suchen und dann zu löschen:

az k8s-configuration list --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>
az k8s-configuration delete --name <configuration name> --cluster-name <cluster name> --cluster-type <connectedClusters or managedClusters> --resource-group <resource group name>

Sie können auch bestehende GitOps-Konfigurationen für einen Cluster im Azure-Portal finden und löschen. Navigieren Sie hierzu zu dem Cluster, in dem die Konfiguration erstellt wurde, und wählen Sie im linken Bereich GitOps aus. Wählen Sie die Konfiguration und dann Löschen aus.

Bereitstellen von Flux v2-Konfigurationen

Verwenden Sie das Azure-Portal oder Azure CLI, um Flux v2-Konfigurationen auf Ihre Cluster anzuwenden.

Informationen zur Ausmusterung von Flux v1

Das Open-Source-Projekt Flux v1 wurde archiviert, und die Entwicklung von Funktionen wurde auf unbestimmte Zeit eingestellt.

Flux v2 wurde als erweitertes Open-Source-Projekt von Flux gestartet. Es hat eine neue Architektur und unterstützt mehr GitOps-Anwendungsfälle. Microsoft brachte im Mai 2022 eine Version einer Erweiterung mit Flux v2 auf den Markt. Seitdem wurde den Kunden empfohlen, innerhalb von drei Jahren auf Flux v2 umzusteigen, da der Support für Flux v1 im Mai 2025 ausläuft.

Die wichtigsten neuen Funktionen der GitOps-Erweiterung für Flux v2:

  • Flux v1 ist ein monolithischer Allrounder. Flux v2 unterteilt die Funktionalitäten in spezialisierte Steuerelemente (Source Controller, Kustomize Controller, Helm Controller und Notification Controller).
  • Unterstützt die Synchronisierung mit mehreren Quellrepositorys.
  • Unterstützt die Mehrinstanzenfähigkeit, d. h., jedes Quellrepository verfügt über einen eigenen Satz von Berechtigungen.
  • Ermöglicht betriebliche Einblicke durch Überprüfungen, Ereignisse und Warnungen.
  • Unterstützt Git-Zweige, das Anheften von Commits und Tags sowie das Verfolgen von SemVer-Tagbereichen.
  • Konfiguration der Anmeldeinformationen pro GitRepository-Ressource: Privater SSH-Schlüssel, HTTP/S-Benutzername/Passwort/Token und öffentliche OpenPGP-Schlüssel.

Nächste Schritte