Anthos Service Mesh lokal aktualisieren

In dieser Anleitung wird erläutert, wie Sie Anthos Service Mesh von Version 1.7.3+ or a 1.8 patch release auf Version 1.8.6 in GKE on VMware aktualisieren. Upgrades von früheren Versionen werden nicht unterstützt. Wenn Sie eine ältere Version haben und ein Upgrade durchführen müssen, lesen Sie Upgrade von früheren Versionen.

Es wird empfohlen, ein auf Überarbeitung basierendes Upgrade (auch als „Canary Upgrade“ bezeichnet) zu verwenden, bei dem sowohl die neue als auch die vorherige Version der Steuerungsebene ausgeführt wird, wenn Sie die neue Version mit einem kleinen Prozentsatz Ihrer Arbeitslasten testen. Dieser Ansatz ist sicherer als ein direktes Upgrade, bei dem die neue Version der Steuerungsebene die vorherige Version ersetzt. Beachten Sie, dass istio-ingressgateway direkt aktualisiert wird. Planen Sie deshalb für Ihren Cluster eine gewisse Unterbrechung ein.

Es dauert fünf bis zehn Minuten, um die Komponenten der Anthos Service Mesh-Steuerungsebene noch einmal bereitzustellen. Außerdem müssen Sie in allen Arbeitslasten neue Sidecar-Proxys einfügen, damit sie mit der aktuellen Anthos Service Mesh-Version aktualisiert werden. Wie lange es dauert, die Sidecar-Proxys zu aktualisieren, hängt von vielen Faktoren ab, z. B. von der Anzahl der Pods, der Anzahl der Knoten, den Skalierungseinstellungen der Bereitstellung, den Budget für Pod-Störungen und anderen Konfigurationseinstellungen. Grob geschätzt dauert die Aktualisierung der Sidecar-Proxys 100 Pods pro Minute.

Upgrade vorbereiten

Wenn Sie die vorherige Installation angepasst haben, müssen Sie diese Anpassung nach dem Upgrade von Anthos Service Mesh übernehmen. Wenn Sie die Installation durch Hinzufügen des Flags --set values zu istioctl install angepasst haben, empfehlen wir, diese Einstellung in eine IstioOperator-YAML-Datei einzufügen. Sie können aber auch weiterhin das Flag --set_values verwenden. Zur Anpassung der Installation geben Sie das Flag -f mit einer YAML-Datei an, wenn Sie den Befehl istioctl install ausführen.

Umgebung einrichten

Sie benötigen die folgenden Tools auf dem Computer, von dem Sie Anthos Service Mesh installieren möchten. Sie können Anthos Service Mesh nur auf einem Nutzercluster und nicht auf einem Administratorcluster installieren.

Nach der Installation des Google Cloud CLI:

  1. Authentifizieren Sie sich mit dem Google Cloud CLI:

    gcloud auth login

  2. Aktualisieren Sie die Komponenten:

    gcloud components update

  3. Installieren Sie kubectl:

    gcloud components install kubectl

  4. Installieren Sie die erforderliche Version von kpt:

       curl -L https://github.com/GoogleContainerTools/kpt/releases/download/v0.39.2/kpt_linux_amd64 > kpt_0_39_2
   chmod +x kpt_0_39_2
   alias kpt="$(readlink -f kpt_0_39_2)"

  5. Wechseln Sie den Kontext zu Ihrem Nutzercluster:

    kubectl config use-context CLUSTER_NAME

  6. Gewähren Sie dem Nutzerkonto Administratorberechtigungen (Ihre E-Mail-Adresse für die Anmeldung in Google Cloud). Sie benötigen diese Berechtigungen, um die erforderlichen Regeln für die rollenbasierte Zugriffssteuerung (Role Based Access Control, RBAC) für Anthos Service Mesh zu erstellen:

    kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user=USER_ACCOUNT

Installationsdatei herunterladen

    Linux

  1. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter: 
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.6-asm.8-linux-amd64.tar.gz
  2. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit openssl: 
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.6-asm.8-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.8.6-asm.8-linux-amd64.tar.gz.1.sig istio-1.8.6-asm.8-linux-amd64.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    Die erwartete Ausgabe ist Verified OK.

  3. Entpacken Sie die Inhalte der Datei in einem Verzeichnis Ihres Dateisystems. So extrahieren Sie beispielsweise den Inhalt in das aktuelle Arbeitsverzeichnis: 
    tar xzf istio-1.8.6-asm.8-linux-amd64.tar.gz

    Mit dem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.8.6-asm.8 ein Installationsverzeichnis erstellt, das Folgendes enthält:

    • Beispielanwendungen im Verzeichnis samples.
    • Das istioctl-Befehlszeilentool, das Sie zum Installieren von Anthos Service Mesh verwenden, befindet sich im Verzeichnis bin.
    • Die Anthos Service Mesh-Konfigurationsprofile befinden sich im Verzeichnis manifests/profiles.

  4. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden. 
    cd istio-1.8.6-asm.8

    5. macOS

  5. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter: 
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.6-asm.8-osx.tar.gz
  6. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit openssl: 
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.6-asm.8-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.8.6-asm.8-osx.tar.gz.1.sig istio-1.8.6-asm.8-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    Die erwartete Ausgabe ist Verified OK.

  7. Entpacken Sie die Inhalte der Datei in einem Verzeichnis Ihres Dateisystems. So extrahieren Sie beispielsweise den Inhalt in das aktuelle Arbeitsverzeichnis: 
    tar xzf istio-1.8.6-asm.8-osx.tar.gz

    Mit dem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.8.6-asm.8 ein Installationsverzeichnis erstellt, das Folgendes enthält:

    • Beispielanwendungen im Verzeichnis samples.
    • Das istioctl-Befehlszeilentool, das Sie zum Installieren von Anthos Service Mesh verwenden, befindet sich im Verzeichnis bin.
    • Die Anthos Service Mesh-Konfigurationsprofile befinden sich im Verzeichnis manifests/profiles.

  8. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden. 
    cd istio-1.8.6-asm.8

    9. Windows

  9. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter: 
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.6-asm.8-win.zip
  10. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit openssl: 
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.8.6-asm.8-win.zip.1.sig
openssl dgst -verify - -signature istio-1.8.6-asm.8-win.zip.1.sig istio-1.8.6-asm.8-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    Die erwartete Ausgabe ist Verified OK.

  11. Entpacken Sie die Inhalte der Datei in einem Verzeichnis Ihres Dateisystems. So extrahieren Sie beispielsweise den Inhalt in das aktuelle Arbeitsverzeichnis: 
    tar xzf istio-1.8.6-asm.8-win.zip

    Mit dem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.8.6-asm.8 ein Installationsverzeichnis erstellt, das Folgendes enthält:

    • Beispielanwendungen im Verzeichnis samples.
    • Das istioctl-Befehlszeilentool, das Sie zum Installieren von Anthos Service Mesh verwenden, befindet sich im Verzeichnis bin.
    • Die Anthos Service Mesh-Konfigurationsprofile befinden sich im Verzeichnis manifests/profiles.

  12. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden. 
    cd istio-1.8.6-asm.8

Ressourcenkonfigurationsdateien vorbereiten

Wenn Sie den Befehl istioctl install ausführen, fügen Sie die Datei revisioned-custom-ingressgateway.yaml in die Befehlszeile ein. Mit dieser Datei können Sie steuern, wann Sie nach dem Upgrade zur neuen Version von istio-ingressgateway wechseln. Führen Sie die folgenden Schritte aus, um diese Datei herunterzuladen und zu konfigurieren:

  1. Wechseln Sie in das Verzeichnis, in das Sie das Paket anthos-service-mesh herunterladen möchten.

  2. Laden Sie das Paket herunter:

    kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.8-asm asm

  3. Setzen Sie das Tag auf die Version des Anthos Service Mesh, das Sie installieren:

    kpt cfg set asm anthos.servicemesh.tag 1.8.6-asm.8

  4. Legen Sie den Validierungs-Webhook so fest, dass er ein Überarbeitungslabel verwendet:

    kpt cfg set asm anthos.servicemesh.rev asm-186-8

    Wenn Sie Anthos Service Mesh installieren, legen Sie ein Überarbeitungslabel auf istiod fest. Sie müssen für den Validierten Webhook dieselbe Überarbeitung festlegen.

Upgrade von Anthos Service Mesh durchführen

Für die Installation einer neuen Version von Anthos Service Mesh empfehlen wir den revisionsbasierten Upgradeprozess (auch als „Canary Upgrade“ bezeichnet). Mit einem revisionsbasierten Upgrade installieren Sie eine neue Version der Steuerungsebene zusammen mit der vorhandenen Steuerungsebene. Fügen Sie bei der Installation der neuen Version das Label revision ein, das die Version der neuen Steuerungsebene angibt. Jede Überarbeitung ist eine vollständige Implementierung der Anthos Service Mesh-Steuerungsebene mit eigenem Deployment und Dienst.

Anschließend migrieren Sie zur neuen Version. Legen Sie dazu für Ihre Arbeitslasten dasselbe revision-Label fest, das auf die neue Steuerungsebene verweist, und führen Sie einen rollierenden Neustart durch, um die neue Anthos Service Mesh-Version in die Proxys einzufügen. Bei diesem Ansatz können Sie die Auswirkungen des Upgrades auf einen kleinen Prozentsatz Ihrer Arbeitslasten überwachen. Nachdem Sie Ihre Anwendung getestet haben, können Sie den gesamten Traffic zur neuen Version migrieren. Dieser Ansatz ist wesentlich sicherer als ein direktes Upgrade, bei dem eine neue Steuerungsebene die vorherige Version der Steuerungsebene ersetzt.

Steuerungsebene aktualisieren

  1. Wechseln Sie gegebenenfalls zum Verzeichnis istio-1.8.6-asm.8. Der istioctl-Client ist versionsabhängig. Sie müssen die Version im Verzeichnis istio-1.8.6-asm.8/bin verwenden.

  2. Führen Sie den folgenden Befehl aus, um die neue Steuerungsebene bereitzustellen. Wenn Sie ein unterstütztes optionales Feature aktivieren möchten, fügen Sie in der folgenden Befehlszeile -f und den YAML-Dateinamen ein. Weitere Informationen finden Sie unter Optionale Features aktivieren.

    bin/istioctl install \
  --set profile=asm-multicloud \
  -f asm/istio/options/revisioned-istio-ingressgateway.yaml \
  --set revision=asm-186-8

Mit dem Argument --set revision wird das Label istio.io/rev zu istiod hinzugefügt. Nach der Ausführung des Befehls haben Sie für die Steuerungsebene zwei Deployments und Dienste, die nebeneinander ausgeführt werden:

kubectl get pods -n istio-system

Arbeitslasten bereitstellen und neu bereitstellen

  1. Rufen Sie das Revisionslabel ab, das sich auf istiod und dem istio-ingressgateway befindet.

    kubectl get pod -n istio-system -L istio.io/rev

    Die Ausgabe des Befehls sieht in etwa so aus:

    NAME                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-65d884685d-6hrdk            1/1     Running   0          67m
istio-ingressgateway-65d884685d-94wgz            1/1     Running   0          67m
istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-186-8
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-186-8
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-178-10
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-178-10
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-186-8
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-186-8

    1. Prüfen Sie, ob Sie sowohl die alte als auch die neue Version von istio-ingressgateway haben.

      • Wenn Sie beim Upgrade die Option revisioned-istio-ingressgateway angegeben haben, wurde ein Canary-Upgrade von istio-ingressgateway durchgeführt. In diesem Fall zeigt die Ausgabe sowohl die alte als auch die neue Version von istio-ingressgateway an.

      • Wenn Sie beim Upgrade revisioned-istio-ingressgateway nicht angegeben haben, wurde ein direktes Upgrade von istio-ingressgateway durchgeführt. In diesem Fall enthält Ihre Ausgabe nur die neue Version.

    2. Notieren Sie sich in der Ausgabe unter der Spalte REV den Wert des Überarbeitungslabels für die neue Version. In diesem Beispiel ist der Wert asm-186-8.

    3. Notieren Sie sich außerdem den Wert im Überarbeitungslabel der alten istiod-Version. Diesen Wert benötigen Sie, um die alte Version von istiod zu löschen, wenn Sie die Arbeitslasten in die neue Version verschoben haben. In der Beispielausgabe lautet der Wert für das Überarbeitungslabel der alten Version asm-178-10.

  2. Wenn Sie sowohl die alte als auch die neue Version von istio-ingressgateway haben, wechseln Sie istio-ingressgateway zur neuen Überarbeitung. Ändern Sie im folgenden Befehl REVISION in den Wert, der dem Überarbeitungslabel der neuen Version entspricht.

    kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

    Erwartete Ausgabe: service/istio-ingressgateway patched

  3. Fügen Sie das Überarbeitungslabel einem Namespace hinzu und entfernen Sie das istio-injection-Label (falls vorhanden). Geben Sie im folgenden Befehl für REVISION den Wert an, der der neuen Überarbeitung von istiod entspricht.

    kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

    Wenn in der Ausgabe "istio-injection not found" angezeigt wird, können Sie dies ignorieren. Das bedeutet, dass der Namespace bisher nicht das Label istio-injection hatte. Da die automatische Injektion fehlschlägt, wenn ein Namespace sowohl das istio-injection als auch das Überarbeitungslabel enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Label istio-injection.

  4. Starten Sie die Pods neu, um die erneute Injektion auszulösen.

    kubectl rollout restart deployment -n NAMESPACE

  5. Überprüfen Sie, ob Ihre Pods so konfiguriert sind, dass sie auf die neue Version von istiod verweisen.

    kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

  6. Testen Sie die Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.

  7. Wenn Sie Arbeitslasten in anderen Namespaces haben, wiederholen Sie die Schritte, um den Namespace mit einem Label zu versehen und Pods neu zu starten.

  8. Wenn Sie sicher sind, dass Ihre Anwendung wie erwartet funktioniert, fahren Sie mit den Schritten für die Umstellung auf die neue Version von istiod fort. Wenn ein Problem mit Ihrer Anwendung auftritt, führen Sie die Schritte zum Rollback aus.

  9. Führen Sie folgenden Befehl noch einmal aus, um zu prüfen, ob Sie sowohl die alte als auch die neue Version von istio-ingressgateway oder nur die neue Version haben. Dies bestimmt, wie mit der Umstellung auf die neue Version von istio-ingressgateway oder einem Rollback auf die alte Version umgegangen wird.

    kubectl get pod -n istio-system -L istio.io/rev

    Umstellung vornehmen

    Wenn Sie sicher sind, dass Ihre Anwendung wie erwartet funktioniert, entfernen Sie die alte Steuerungsebene, um die Umstellung auf die neue Version abzuschließen.

    1. Wechseln Sie in das Verzeichnis, in dem sich die Dateien aus dem GitHub-Repository anthos-service-mesh befinden.

    2. Konfigurieren Sie den validierten Webhook so, dass er die neue Steuerungsebene verwendet.

      kubectl apply -f asm/istio/istiod-service.yaml

    3. Wenn Sie sowohl die alte als auch die neue Version von istio-ingressgateway nutzen, löschen Sie das alte istio-ingressgateway-Deployment. Der Befehl, den Sie ausführen, hängt davon ab, ob Sie von Istio migrieren oder ein Upgrade von einer vorherigen Version von Anthos Service Mesh machen:

      Migrieren

      Wenn Sie von Istio migriert haben, hat die alte istio-ingressgateway-Datei kein Überarbeitungslabel.

      kubectl delete deploy/istio-ingressgateway -n istio-system

      Upgrade

      Wenn Sie ein Upgrade von einer früheren Anthos Service Mesh-Version durchgeführt haben, ersetzen Sie im folgenden Befehl OLD_REVISION durch das Überarbeitungslabel für die vorherige Version von istio-ingressgateway.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true

    4. Löschen Sie die alte Version von istiod. Der verwendete Befehl hängt davon ab, ob Sie von Istio migrieren oder ein Upgrade von einer früheren Version von Anthos Service Mesh durchführen.

      Migrieren

      Wenn Sie von Istio migriert haben, hat die alte istiod-Datei kein Überarbeitungslabel.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

      Upgrade

      Wenn Sie ein Upgrade von einer früheren Anthos Service Mesh-Version durchgeführt haben, achten Sie im folgenden Befehl darauf, dass OLD_REVISION mit dem Überarbeitungslabel für die vorherige Version von istiod übereinstimmt.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true

    5. Entfernen Sie die alte Version der IstioOperator-Konfiguration.

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system

      Die erwartete Ausgabe sieht in etwa so aus:

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

    Rollback

    Wenn beim Testen der Anwendung mit der neuen istiod-Version ein Problem auftritt, gehen Sie so vor, um ein Rollback auf die vorherige Version auszuführen:

    1. Wechseln Sie zurück zur alten Version von istio-ingressgateway. Der verwendete Befehl hängt davon ab, ob Sie die alte und die neue Version von istio-ingressgateway oder nur die neue Version haben.

      • Wenn Sie sowohl die alte als auch die neue Version von istio-ingressgateway verwenden, führen Sie den kubectl patch service-Befehl aus und ersetzen OLD_REVISION durch die alte Überarbeitung.

        kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'

      • Wenn Sie nur die neue Version von istio-ingressgateway haben, führen Sie den kubectl rollout undo-Befehl aus.

        kubectl -n istio-system rollout undo deploy istio-ingressgateway

    2. Benennen Sie Ihren Namespace um, um die automatische Injektion mit der vorherigen Version von istiod zu aktivieren. Der zu verwendende Befehl hängt davon ab, ob Sie ein Überarbeitungslabel oder istio-injection=enabled mit der vorherigen Version verwendet haben.

      • Wenn Sie ein Überarbeitungslabel für die automatische Injektion verwendet haben, führen Sie Folgendes aus:

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite

      • Wenn Sie istio-injection=enabled verwendet haben, führen Sie Folgendes aus:

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

      Erwartete Ausgabe:

      namespace/NAMESPACE labeled

    3. Prüfen Sie, ob das Überarbeitungslabel im Namespace mit dem Überarbeitungslabel in der vorherigen Version von istiod übereinstimmt:

      kubectl get ns NAMESPACE --show-labels

    4. Starten Sie die Pods neu, um die erneute Einfügung auszulösen, damit die Proxys die Istio-Version erhalten:

      kubectl rollout restart deployment -n NAMESPACE

    5. Wenn Sie sowohl die alte als auch die neue Version von istio-ingressgateway verwenden, entfernen Sie das neue istio-ingressgateway-Deployment. Achten Sie darauf, dass der Wert von REVISION im folgenden Befehl korrekt ist.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true

    6. Entfernen Sie die neue Version von istiod. Achten Sie darauf, dass der Wert von REVISION im folgenden Befehl korrekt ist.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true

    7. Entfernen Sie die neue Version der IstioOperator-Konfiguration.

      kubectl delete IstioOperator installed-state-REVISION -n istio-system

      Die erwartete Ausgabe sieht in etwa so aus:

      istiooperator.install.istio.io "installed-state-REVISION" deleted

    8. Wenn Sie das Flag --disable_canonical_service nicht angegeben haben, hat das Skript den Canonical Service-Controller aktiviert. Wir empfehlen, ihn aktiviert zu lassen. Falls Sie ihn jedoch deaktivieren müssen, finden Sie weitere Informationen unter Canonical Service-Controller aktivieren und deaktivieren.

Nächste Schritte