Anthos Service Mesh 1.11 ist abgelaufen und wird nicht mehr unterstützt. Siehe Upgraden von früheren Versionen.

Lesen Sie die aktuelle Dokumentation oder wählen Sie eine andere verfügbare Version aus:

Verfügbare Versionen

Verwaltetes Anthos Service Mesh konfigurieren

Überblick

Managed Anthos Service Mesh ist eine von Google verwaltete Steuerungsebene und eine optionale Datenebene, die Sie nur konfigurieren müssen. Google sorgt für ihre Zuverlässigkeit, Upgrades, Skalierung und Sicherheit in abwärtskompatibler Art und Weise. In dieser Anleitung wird erläutert, wie Sie Anwendungen einrichten oder in das verwaltete Anthos Service Mesh in einer Einzel- oder Multi-Cluster-Konfiguration migrieren.

Informationen zu den unterstützten Features und Einschränkungen des verwalteten Anthos Service Mesh finden Sie unter Unterstützte Features für verwaltetes Anthos Service Mesh.

Vorbereitung

Sie sollten Folgendes bereits haben:

Ein Cloud-Projekt
Ein Cloud-Rechnungskonto
Das Installationsskript kpt und andere Tools, die unter Erforderliche Tools installieren angegeben sind.

Voraussetzungen

Ein oder mehrere Cluster mit einer unterstützten Version von GKE in einer der unterstützten Regionen.
In Ihren Clustern muss Workload Identity aktiviert sein. Weitere Informationen zum gcloud-Befehl finden Sie unter Workload Identity aktivieren.
Für die von Google verwaltete Datenebene müssen Sie das CNI-Plug-in (Container Network Interface) von Istio aktivieren, wenn Sie die von Google verwaltete Steuerungsebene bereitstellen, wie weiter unten auf dieser Seite beschrieben.

Migrationen

Direkte Migrationen/Upgrades von der Steuerungsebene im Cluster zur von Google verwalteten Steuerungsebene werden nur ab Version 1.9 unterstützt (installiert mit Mesh CA).
Installationen mit Istio CA müssen zuerst zu Mesh CA 1.9+ migriert werden.
Indirekte Migrationen/Upgrades werden unterstützt. Das bedeutet, dass Sie die standardmäßigen Upgrade-Pfade von Anthos Service Mesh für jede Version befolgen können, bis Sie Anthos Service Mesh 1.11 mit einer clusterinternen Steuerungsebene erreichen. Dann können Sie zur von Google verwalteten Steuerungsebene migrieren.

Beschränkungen

Wir empfehlen Ihnen, die Liste der von verwaltetem Anthos Service Mesh unterstützten Features und Einschränkungen durchzugehen. Insbesondere ist Folgendes zu berücksichtigen:

Verwaltetes Anthos Service Mesh kann nur mehrere GKE-Cluster in einem einzelnen Google Cloud-Projekt verwenden.
Die IstioOperator API wird nicht unterstützt.
Einschränkungen der verwalteten Datenebene:
- Dieser Vorschaurelease der verwalteten Datenebene ist nur für neue Bereitstellungen der verwalteten Steuerungsebene verfügbar. Wenn Sie zuvor die verwaltete Steuerungsebene bereitgestellt haben und die verwaltete Datenebene bereitstellen möchten, müssen Sie das Installationsskript noch einmal ausführen, wie unter Von Google verwaltete Steuerungsebene anwenden beschrieben.
- Die verwaltete Datumsebene ist in den Release-Kanälen "Regular" und "Rapid" verfügbar.

Workload Identity aktivieren

Wenn Workload Identity nicht aktiviert ist, finden Sie unter Workload Identity in einem Cluster aktivieren die zum Aktivieren erforderlichen IAM-Berechtigungen und die gcloud CLI.

Installationsskript herunterladen

Laden Sie die aktuellste Version des Skripts herunter, mit der Anthos Service Mesh 1.11.8 in das aktuelle Arbeitsverzeichnis installiert wird:
```
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.11 > install_asm
```
Machen Sie das Skript ausführbar:
```
chmod +x install_asm
```

Jeden Cluster konfigurieren

Führen Sie die folgenden Schritte aus, um ein verwaltetes Anthos Service Mesh für jeden Cluster in Ihrem Mesh-Netzwerk zu konfigurieren.

Clusteranmeldedaten abrufen

Rufen Sie die entsprechenden Anmeldedaten ab. Mit dem folgenden Befehl wird auch der Kontext kubectl auf den Zielcluster verweisen.

gcloud container clusters get-credentials  CLUSTER_NAME \
    --zone LOCATION \
    --project PROJECT_ID

Von Google verwaltete Steuerungsebene anwenden

Führen Sie das Installationsskript install_asm für jeden Cluster aus, der das verwaltete Anthos Service Mesh verwendet. Wir empfehlen, beim Ausführen von install_asm die beiden folgenden Optionen anzugeben:

--option cni-managed Diese Option aktiviert das Plug-in Istio Container Netzwerkschnittstelle (CNI). Das CNI-Plug-in konfiguriert die Weiterleitung von Netzwerktraffic zu und von den Sidecar-Proxys über die CNCF-CNI-Schnittstelle anstelle eines init-Containers mit umfassender Berechtigung.
--enable-registration Dieses Flag registriert den Cluster bei einer Flotte.

Diese Optionen sind erforderlich, wenn Sie auch die von Google verwaltete Datenebene bereitstellen möchten. Eine vollständige Liste der Optionen finden Sie auf der Asmcli-Referenzseite.

  ./install_asm --mode install --managed \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --enable-registration \
      --option cni-managed

Das Skript lädt alle Dateien zur Konfiguration der verwalteten Steuerungsebene in das angegebene --output_dir herunter und installiert ein Istio-Gateway zusammen mit dem istioctl-Tool und Beispielanwendungen. Bei den Schritten in diesem Leitfaden wird davon ausgegangen, dass Sie istioctl im Stammverzeichnis des Installationsverzeichnisses ausführen, wobei istioctl im Unterverzeichnis /bin vorhanden ist.

Wenn Sie install_asm im selben Cluster noch einmal ausführen, wird die vorhandene Konfiguration der Steuerungsebene überschrieben. Achten Sie darauf, dass Sie dieselben Optionen und Flags angeben, wenn Sie dieselbe Konfiguration verwenden möchten.

Beachten Sie, dass ein Gateway für eingehenden Traffic nicht automatisch mit der Steuerungsebene bereitgestellt wird. Durch das Entkoppeln der Bereitstellung des Ingress-Gateways können Sie Ihre Gateways in einer Produktionsumgebung leichter verwalten. Wenn der Cluster ein Ingress-Gateway benötigt, finden Sie weitere Informationen unter Istio-Gateways installieren.

Von Google verwaltete Datenebene anwenden

Wenn Sie möchten, dass Google Upgrades der Proxys verwaltet, aktivieren Sie die von Google verwaltete Datenebene. Wenn diese Option aktiviert ist, werden die Sidecar-Proxys und injizierten Gateways automatisch in Verbindung mit der verwalteten Steuerungsebene aktualisiert.

In der Feature-Vorschau aktualisiert die verwaltete Steuerungsebene Proxys durch Entfernen von Pods, auf denen ältere Versionen des Proxys ausgeführt werden. Die Bereinigungen werden in einer geordneten Weise vorgenommen. Dabei wird das Budget für Pod-Störungen berücksichtigt und die Änderungsrate kontrolliert.

In diesem Vorschaurelease der verwalteten Datenebene wird Folgendes nicht verwaltet:

Nicht eingefügte Pods.
Manuell mit istioctl kube-inject eingefügte Pods.
Jobs
Zustandsorientierte Sets
DaemonSet

Wenn Sie keine verwaltete Datenebene verwenden oder diese nicht für alle Namespaces aktivieren möchten, sollten Sie einen Neustart der Proxys auslösen, um vom neuesten Proxy-Image zu profitieren. Die Steuerungsebene funktioniert weiterhin mit den vorhandenen Proxys.

Die verwaltete Datenebene ist in beiden Release-Kanälen verfügbar: "Rapid" und "Regular".

So aktivieren Sie die von Google verwaltete Datenebene:

Aktivieren Sie die Verwaltung der Datenebene:
```
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'
```
Alternativ können Sie die von Google verwaltete Datenebene für einen bestimmten Pod aktivieren, indem Sie sie mit derselben Annotation versehen. Wenn Sie einen bestimmten Pod mit Annotationen versehen, verwendet dieser Pod den von Google verwalteten Sidecar-Proxy und der Rest der Arbeitslasten verwendet die nicht verwalteten Sidecar-Proxys.
Wiederholen Sie den vorherigen Schritt für jeden Namespace, den Sie für eine verwaltete Datenebene benötigen.

Aktivieren Sie Anthos Service Mesh in der Flotte:

gcloud alpha container hub mesh enable --project=PROJECT_ID

Es kann bis zu zehn Minuten dauern, bis der Datenebenen-Controller zur Verwaltung der Proxys im Cluster bereit ist. Führen Sie den folgenden Befehl aus, um den Status zu prüfen:

if kubectl get dataplanecontrols -o custom-columns=REV:.spec.revision,STATUS:.status.state | grep rapid | grep -v none > /dev/null; then echo "Managed Data Plane is ready."; else echo "Managed Data Plane is NOT ready."; fi

Wenn der Datenebene-Controller bereit ist, gibt der Befehl Folgendes aus: Managed Data Plane is ready.

Wenn der Datenebene-Controller nach mehr als zehn Minuten nicht bereit ist, finden Sie unter Status der verwalteten Datenebene Tipps zur Fehlerbehebung.

Wenn Sie die von Google verwaltete Datenebene deaktivieren und wieder die Sidecar-Proxys verwalten möchten, ändern Sie die Annotation:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Istio-Gateways installieren (optional)

Anthos Service Mesh bietet Ihnen die Möglichkeit, Gateways als Teil Ihres Service Mesh bereitzustellen und zu verwalten. Ein Gateway beschreibt einen Load-Balancer, der am Rand des Mesh-Netzwerks arbeitet und eingehende oder ausgehende HTTP/TCP-Verbindungen empfängt. Gateways sind Envoy-Proxys, die Ihnen eine detaillierte Kontrolle über den in das Mesh-Netzwerk eingehenden und ausgehenden Traffic ermöglichen.

Als Best Practice empfehlen wir, einen separaten Namespace für die Gateways zu erstellen. Stellen Sie die Gateways nicht im Namespace istio-system bereit.

Sie können ein oder mehrere Istio-Gateways in Ihrem Cluster installieren, um typischen eingehenden Traffic zu verarbeiten. Dazu verwenden Sie folgende Schritte:

Wählen Sie eine dieser beiden Optionen aus, um den Namespace einzurichten, in dem Sie das Gateway in späteren Schritten bereitstellen.
- Aktivieren Sie den Namespace für die Injection:
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite
```
OR
- Aktivieren Sie die Injection nur für den Gateway-Pod, aber nicht für alle Pods im Namespace. Mit diesem Befehl werden alle Injection-Labels entfernt. Später aktivieren Sie dann die Injection für den Pod selbst:
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev-
```

Verwenden Sie das folgende kleine Beispiel, um eine Bereitstellung und einen Dienst für das Gateway zu erstellen:

kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  type: LoadBalancer
  selector:
    istio: ingressgateway
  ports:
  - port: 80
    name: http
  - port: 443
    name: https
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: asm-managed-rapid # This is required only if the namespace is not labeled.
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: istio-ingressgateway-sds
  namespace: GATEWAY_NAMESPACE
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: istio-ingressgateway-sds
  namespace: GATEWAY_NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: istio-ingressgateway-sds
subjects:
- kind: ServiceAccount
  name: default
EOF

Prüfen Sie nach dem Erstellen der Bereitstellung, ob die neuen Dienste ordnungsgemäß funktionieren:

kubectl get pod,service -n GATEWAY_NAMESPACE

Die Ausgabe sollte in etwa so aussehen:

NAME                                      READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

Sie können auswählen, ob der Controller der verwalteten Datenebene die Proxys für Ihre Gateways verwaltet, genau wie für Ihre Dienste. Wenn Sie die verwaltete Datenebene bereitgestellt haben und möchten, dass die Gateway-Proxys verwaltet werden, versehen Sie den Gateway-Namespace wie unter Von Google verwaltete Datenebene anwenden beschrieben mit Labels und Annotationen.

Wenn Sie die Gateways selbst verwalten, müssen Sie die Pods in GATEWAY_NAMESPACE neu starten, wenn eine neue Version von Anthos Service Mesh veröffentlicht wird, damit sie die neue Konfiguration der Steuerungsebene übernehmen. Bevor Sie die Pods neu starten, prüfen Sie, ob die neue Steuerungsebene auf Ihrem Cluster bereitgestellt wurde. Prüfen Sie dazu die Version der Steuerungsebene anhand der benutzerdefinierten Metrics Explorer-Abfrage unter Messwerte der Steuerungsebene prüfen.

Endpunkterkennung konfigurieren (nur für Installationen mit mehreren Clustern)

Die verwaltete Anthos Service Mesh-Steuerungsebene unterstützt eine multi-primäre Konfiguration mit einem einzelnen Projekt und Netzwerk, mit dem Unterschied, dass die Steuerungsebene nicht im Cluster installiert ist.

Bevor Sie fortfahren, sollten Sie das Installationsskript, wie in den vorherigen Schritten beschrieben, bereits auf jedem Cluster ausgeführt haben. Sie müssen nicht angeben, dass ein Cluster ein primärer Cluster ist, dies ist das Standardverhalten.

Aktivieren Sie für jeden Cluster die Endpunkterkennung. Führen Sie dazu die folgenden Befehle für jeden anderen Cluster i=1..N im Mesh-Netzwerk aus:

Sorgen Sie dafür, dass der kubectl-Konfigurationskontext für jeden Cluster auf den aktuellen Cluster verweist:
```
export CTX=gke_PROJECT_ID_LOCATION_CLUSTER_NAME
```

Aktivieren Sie die Endpunkterkennung, indem Sie die folgenden Befehle einmal für jeden anderen Cluster i=1..N im Mesh-Netzwerk ausführen:

export CTX_i=gke_PROJECT_ID_LOCATION_i_CLUSTER_NAME_i

./bin/istioctl x create-remote-secret --context=${CTX_i} --name=CLUSTER_NAME_i | \
  kubectl apply -f - --context=${CTX}

Prüfen Sie mit dem folgenden Befehl, ob das Secret erstellt wurde:

kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system

Prüfen Sie die erwartete Ausgabe:

NAME                                   TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s

Wenn der aktuelle Cluster zu einem vorhandenen Mesh-Netzwerk mit mehreren Clustern hinzugefügt wird, müssen alle anderen Cluster dessen Endpunkte erkennen. Erstellen Sie dazu ein Secret für den aktuellen Cluster in allen anderen Clustern:
```
./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
  kubectl apply -f - --context=${CTX_i}
```

Darüber hinaus können Sie das Secret für den anderen Cluster überprüfen:

kubectl get secret istio-remote-secret-CLUSTER_NAME -n istio-system --context ${CTX_i}

Prüfen Sie die erwartete Ausgabe:

NAME                            TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME   Opaque   1      44s

Weitere Informationen und ein Beispiel mit zwei Clustern finden Sie unter Endpunkterkennung aktivieren.

Anwendungen bereitstellen

Entfernen Sie vor dem Bereitstellen von Anwendungen alle vorherigen istio-injection-Labels aus ihren Namespaces und legen Sie stattdessen das Label istio.io/rev:asm-managed-rapid fest:

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

Sie haben die verwaltete Anthos Service Mesh-Steuerungsebene konfiguriert. Jetzt können Sie die Anwendungen oder die Bookinfo-Beispielanwendung bereitstellen.

Wenn Sie eine Anwendung in einer Multi-Cluster-Konfiguration bereitstellen, replizieren Sie die Kubernetes- und Steuerungsebene auf allen Clustern, sofern Sie diese bestimmte Konfiguration nicht auf eine Teilmenge von Clustern beschränken. Die auf einen bestimmten Cluster angewendete Konfiguration ist die "Source of Truth" für diesen Cluster. Wenn der Cluster außerdem Anthos Service Mesh 1.7, 1.8 oder höher mit Mesh-CA in anderen Namespaces ausführt, prüfen Sie, ob die Anwendung mit den anderen, von der clusterinternen Steuerungsebene gesteuerten Anwendungen kommunizieren kann.

Messwerte der Steuerungsebene prüfen

Sie können die Version der Steuerungsebene und der Datenebene im Metrics Explorer ansehen.

So prüfen Sie, ob Ihre Konfiguration ordnungsgemäß funktioniert:

Sehen Sie sich in der Google Cloud Console die Messwerte der Steuerungsebene an:

Zum Metrics Explorer
Wählen Sie Ihren Arbeitsbereich aus und fügen Sie mit den folgenden Parametern eine benutzerdefinierte Abfrage hinzu:
- Ressourcentyp: Kubernetes-Container
- Messwert: Proxy-Clients
- Filter: container_name="cr-asm-managed-rapid"
- Gruppieren nach: Überarbeitungslabel und proxy_version-Label
- Aggregator-Summe
- Zeitraum: 1 Minute
Wenn Sie Anthos Service Mesh sowohl mit einer von Google verwalteten als auch mit einer clusterinternen Steuerungsebene ausführen, können Sie die Messwerte anhand ihres Containernamens unterscheiden. Beispielsweise haben verwaltete Messwerte den Wert container_name="cr-asm-managed", während nicht verwatete Messwerte container_name="discovery" haben. Entfernen Sie den Filter für container_name="cr-asm-managed", um Messwerte aus beiden anzuzeigen.
Prüfen Sie die Version der Steuerungsebene und die Proxyversion anhand der folgenden Felder in Metrics Explorer:
- Das Feld Überarbeitung gibt die Version der Steuerungsebene an.
- Das Feld proxy_version gibt die proxy_version an.
- Das Feld Wert gibt die Anzahl der verbundenen Proxys an.
Informationen zum aktuellen Kanal der Anthos Service Mesh-Versionszuordnung finden Sie unter Anthos Service Mesh-Versionen pro Kanal.

Anwendungen zu verwaltetem Anthos Service Mesh migrieren

Verwaltetes Anthos Service Mesh unterstützt nur die Migration von Anthos Service Mesh 1.9, das Mesh CA verwendet.

So migrieren Sie zum verwalteten Anthos Service Mesh:

Führen Sie das Skript wie unter Von Google verwaltete Steuerungsebene anwenden beschrieben aus.
Wenn Sie sowohl die von Google verwaltete Steuerungsebene als auch die Datenebene bereitgestellt haben:
1. Aktivieren Sie die Verwaltung der Datenebene:
```
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'
```
2. Aktivieren Sie Anthos Service Mesh in der Flotte:
```
gcloud alpha container hub mesh enable --project=PROJECT_ID
```

Ersetzen Sie das aktuelle Namespace-Label durch das Label istio.io/rev:asm-managed-rapid:

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid \
    --overwrite

So führen Sie ein Rolling Upgrade von Bereitstellungen im Namespace durch:
```
kubectl rollout restart deployment -n NAMESPACE
```
Testen Sie Ihre Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.
Wenn Sie Arbeitslasten in anderen Namespaces haben, wiederholen Sie die vorherigen Schritte für jeden Namespace.
Wenn Sie die Anwendung in einer Multi-Cluster-Einrichtung bereitgestellt haben, replizieren Sie die Kubernetes- und Istio-Konfiguration in allen Clustern, es sei denn, Sie möchten die Konfiguration auf eine Teilmenge von Clustern beschränken. Die auf einen bestimmten Cluster angewendete Konfiguration ist die "Source of Truth" für diesen Cluster.
Prüfen Sie, ob die Messwerte wie erwartet angezeigt werden. Führen Sie dazu die Schritte unter Messwerte der Steuerungsebene prüfen aus.

Ein Cluster kann verschiedene Überarbeitungen haben, z. B. Anthos Service Mesh 1.7 und 1.8 und eine clusterinterne Steuerungsebene. Sie können Namespaces mit verschiedenen Überarbeitungen der Anthos Service Mesh-Steuerungsebene auf unbestimmte Zeit kombinieren.

Wenn Sie mit der Anwendung zufrieden sind, können Sie den clusterinternen istiod entfernen, nachdem Sie alle Namespaces für die clusterinterne Steuerungsebene geändert haben oder diese als Sicherung beibehalten. istiod wird automatisch herunterskaliert, um weniger Ressourcen zu verwenden. Fahren Sie mit Alte Steuerungsebene löschen fort.

Falls Probleme auftreten, können Sie diese bestimmen und beheben. Dazu verwenden Sie die Informationen unter Probleme mit der verwalteten Steuerungsebene beheben und führen bei Bedarf ein Rollback auf die vorherige Version durch.

Alte Steuerungsebene löschen

Nachdem Sie die Installation abgeschlossen und bestätigt haben, dass alle Namespaces die von Google verwaltete Steuerungsebene verwenden, können Sie die alte Steuerungsebene löschen.

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

Wenn Sie istioctl kube-inject anstelle der automatischen Einschleusung verwendet oder zusätzliche Gateways installiert haben, prüfen Sie die Messwerte für die Steuerungsebene und achten Sie darauf, dass die Anzahl der verbundenen Endpunkte null ist.

Rollback durchführen

Führen Sie die folgenden Schritte aus, um ein Rollback auf die vorherige Version der Steuerungsebene durchzuführen:

Aktualisieren Sie Arbeitslasten, damit die vorherige Version der Steuerungsebene eingeschleust werden kann: Im folgenden Befehl wird der Überarbeitungswert asm-191-1 nur als Beispiel verwendet. Ersetzen Sie den Beispielwert durch das Überarbeitungslabel der vorherigen Steuerungsebene.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
Starten Sie die Pods neu, um die erneute Injektion auszulösen, damit die Proxys die vorherige Version erhalten:
```
kubectl rollout restart deployment -n NAMESPACE
```

Die verwaltete Steuerungsebene wird automatisch auf null skaliert und verwendet keine Ressource, wenn sie nicht verwendet wird. Die geänderten Webhooks und die Bereitstellung bleiben erhalten und wirken sich nicht auf das Clusterverhalten aus.

Für das Gateway ist jetzt die Überarbeitung asm-managed festgelegt. Führen Sie den Anthos Service Mesh-Installationsbefehl noch einmal aus, um ein Rollback durchzuführen. Dadurch wird das Gateway wieder bereitgestellt, das auf Ihre clusterinterne Steuerungsebene verweist:

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

Bei Erfolg können Sie diese Ausgabe erwarten:

deployment.apps/istio-ingressgateway rolled back

Ein Gateway zur von Google verwalteten Steuerungsebene migrieren

Erstellen Sie unter Vernwendung der Dokumentation ein Kubernetes-Deployment für die neue Version des Gateways. Sie müssen den vorhandenen Kubernetes Gateway-Dienst so konfigurieren, dass die alte und die neue Version ausgewählt werden. Verwenden Sie dazu in der Servicekonfiguration das Feld selector.
Mit dem Befehl kubectl scale lässt sich die neue Bereitstellung schrittweise hochskalieren. Gleichzeitig können Sie die alte Bereitstellung herunterskalieren und auf Anzeichen von Dienstunterbrechungen oder Ausfallzeiten achten. Bei einer erfolgreichen Migration sollten Sie ohne jede Dienstunterbrechung null alte Instanzen erreichen.

Deinstallieren

Von Google verwaltete Steuerungsebene wird automatisch auf null skaliert, wenn keine Namespaces verwendet werden, sodass keine Deinstallation nötig ist.

Fehlerbehebung

Informationen zum Identifizieren und Beheben von Problemen bei der Verwendung der verwalteten Steuerungsebene finden Sie unter Probleme mit der verwalteten Steuerungsebene beheben.

Nächste Schritte

Mehr über Release-Versionen erfahren