Konfigurationsupdates für die Modernisierung

In diesem Dokument werden die Konfigurationsaktualisierungen beschrieben, die Sie an Ihren verwalteten Cloud Service Mesh-Clustern vornehmen müssen, wenn sie bei Kompatibilitätsprüfungen gekennzeichnet wurden, bevor Sie vor Ablauf der Supportfrist von der eingestellten ISTIOD-Steuerungsebene auf die TRAFFIC_DIRECTOR-Steuerungsebene modernisieren.

Im Folgenden finden Sie eine Liste möglicher Konfigurationsupdates, die erforderlich sind, um Ihren Cluster für die Modernisierung vorzubereiten. In den folgenden Abschnitten finden Sie eine Anleitung zum Aktualisieren:

• Multi-Cluster
• Workload Identity Federation for GKE aktivieren
• Verwaltetes CNI aktivieren
• Nicht standardmäßige Binärnutzung in Sidecar
• Zum Istio-Ingress-Gateway migrieren
• EnvoyFilter-Kompressorkonfigurationen modernisieren
• Internetnetzwerk-Endpunktgruppen aktivieren
• Berechtigungen für gemeinsam genutzte VPCs
• Fehlende Konfiguration der Steuerungsebene

Weitere Informationen zum Modernisierungs-Workflow finden Sie auf der Seite Modernisierung der verwalteten Steuerungsebene.

Von Istio-Secrets zu „multicluster_mode“ migrieren

Multi-Cluster-Secrets werden nicht unterstützt, wenn ein Cluster die Steuerungsebene TRAFFIC_DIRECTOR verwendet. In diesem Dokument wird beschrieben, wie Sie von der Verwendung von Istio-Multi-Cluster-Secrets zu multicluster_mode wechseln können.

Istio-Secrets im Vergleich zur deklarativen API – Übersicht

Die Open-Source-Istio-Multi-Cluster-Endpunkterkennung funktioniert, indem mit istioctl oder anderen Tools ein Kubernetes-Secret in einem Cluster erstellt wird. Mit diesem Secret kann ein Cluster den Traffic zu einem anderen Cluster im Mesh-Netzwerk per Load-Balancing verteilen. Die Steuerungsebene von ISTIOD liest dann dieses Secret und beginnt, Traffic an diesen anderen Cluster weiterzuleiten.

Cloud Service Mesh bietet eine deklarative API zur Steuerung des Multi-Cluster-Traffics, anstatt Istio-Secrets direkt zu erstellen. Diese API behandelt Istio-Secrets als Implementierungsdetail und ist zuverlässiger als das manuelle Erstellen von Istio-Secrets. Zukünftige Cloud Service Mesh-Features hängen von der deklarativen API ab. Sie können diese neuen Features nicht direkt mit Istio-Secrets verwenden. Die deklarative API ist die einzige unterstützte Option.

Wenn Sie Istio-Secrets verwenden, migrieren Sie so schnell wie möglich zur deklarativen API. Beachten Sie, dass die Einstellung multicluster_mode jeden Cluster anweist, Traffic an jeden anderen Cluster im Mesh-Netzwerk weiterzuleiten. Die Verwendung von Secrets ermöglicht eine flexiblere Konfiguration, da Sie für jeden Cluster konfigurieren können, an welchen anderen Cluster im Mesh-Netzwerk Traffic weitergeleitet werden soll. Eine vollständige Liste der Unterschiede zwischen den unterstützten Features der deklarativen API und Istio-Secrets finden Sie unter Unterstützte Features mit Istio-APIs.

Wichtig: Mit der deklarativen API wird ein ganzer Cluster auf einmal für die Endpunkterkennung aktiviert. Das bedeutet, dass jeder Cluster mit „multicluster_mode=connected“ Endpunkte für jeden anderen Cluster in der Flotte erkennt, der ebenfalls „multicluster_mode=connected“ hat.

Von Istio-Secrets zur deklarativen API migrieren

Wenn Sie Cloud Service Mesh mit automatischer Verwaltung über die Fleet Feature API bereitgestellt haben, müssen Sie diese Anleitung nicht befolgen. Diese Schritte gelten nur, wenn Sie die Einrichtung mit asmcli --managed vorgenommen haben.

Hinweis: Bei diesem Vorgang werden Secrets geändert, die auf einen Cluster verweisen. Dabei werden die Endpunkte entfernt und dann wieder hinzugefügt. Zwischen dem Entfernen und Hinzufügen der Endpunkte wird der Traffic kurzzeitig lokal weitergeleitet, anstatt ein Load Balancing zu anderen Clustern durchzuführen. Weitere Informationen finden Sie im GitHub-Problem.

So wechseln Sie von der Verwendung von Istio-Secrets zur deklarativen API: Führe diese Schritte gleichzeitig oder direkt nacheinander aus:

1. Aktivieren Sie die deklarative API für jeden Cluster in der Flotte, für den Sie die Multi-Cluster-Endpunkterkennung aktivieren möchten, indem Sie multicluster_mode=connected festlegen. Beachten Sie, dass Sie multicluster_mode=disconnected explizit festlegen müssen, wenn der Cluster nicht auffindbar sein soll.

   Verwenden Sie den folgenden Befehl, um einen Cluster für die Multi-Cluster-Endpunkterkennung zu aktivieren:

    kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
   

   Verwenden Sie den folgenden Befehl, um einen Cluster von der Endpunkterkennung auszuschließen:

    kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
   

2. Löschen Sie alte Secrets.

   Nachdem Sie multicluster_mode=connected für Ihre Cluster festgelegt haben, wird für jeden Cluster ein neues Secret für jeden anderen Cluster generiert, für den ebenfalls multicluster_mode=connected festgelegt ist. Das Secret wird im Namespace „istio-system“ platziert und hat das folgende Format:

   istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
   

   Auf jedes Secret wird außerdem das Label istio.io/owned-by: mesh.googleapis.com angewendet.

   Nachdem die neuen Secrets erstellt wurden, können Sie alle manuell mit istioctl create-remote-secret erstellten Secrets löschen:

   kubectl delete secret SECRET_NAME -n istio-system
   

Prüfen Sie nach der Migration die Anfragemesswerte, um sicherzustellen, dass sie wie erwartet weitergeleitet werden.

Workload Identity Federation for GKE aktivieren

Die Workload Identity-Föderation ist die empfohlene sichere Methode für Google Kubernetes Engine-Arbeitslasten. Dadurch wird der Zugriff auf Google Cloud -Dienste wie Compute Engine, BigQuery und Machine Learning APIs ermöglicht. Die Workload Identity-Föderation erfordert keine manuelle Konfiguration oder weniger sichere Methoden wie Dienstkonto-Schlüsseldateien, da IAM-Richtlinien verwendet werden. Weitere Informationen zu Workload Identity Federation finden Sie unter Funktionsweise von Workload Identity Federation für GKE.

Im folgenden Abschnitt wird beschrieben, wie Sie die Workload Identity-Föderation aktivieren.

Workload Identity-Föderation für Cluster aktivieren

1. Prüfen Sie, ob die Workload Identity-Föderation für Ihren Cluster aktiviert ist. Dazu muss für den GKE-Cluster ein Workload Identity Federation-Pool konfiguriert sein, der für die Validierung von IAM-Anmeldedaten erforderlich ist.

   Verwenden Sie den folgenden Befehl, um den für einen Cluster festgelegten Workload Identity-Pool zu prüfen:

   gcloud container clusters describe CLUSTER_NAME \
     --format="value(workloadIdentityConfig.workloadPool)"
   

   Ersetzen Sie dabei CLUSTER_NAME durch den Namen Ihres GKE-Cluster. Wenn Sie noch keine Standardzone oder -region für gcloud angegeben haben, müssen Sie beim Ausführen dieses Befehls evtl. das Flag --region oder --zone angeben.

2. Wenn die Ausgabe leer ist, folgen Sie der Anleitung unter Vorhandenen Cluster aktualisieren, um Workload Identity auf vorhandenen GKE-Clustern zu aktivieren.

Workload Identity-Föderation für Knotenpools aktivieren

Nachdem die Identitätsföderation von Arbeitslasten für einen Cluster aktiviert wurde, müssen Knotenpools für die Verwendung des GKE-Metadatenservers konfiguriert werden.

1. Alle Knotenpools eines Standard-Clusters auflisten Führen Sie den Befehl gcloud container node-pools list aus:

   gcloud container node-pools list --cluster CLUSTER_NAME
   

   Ersetzen Sie dabei CLUSTER_NAME durch den Namen Ihres GKE-Cluster. Wenn Sie noch keine Standardzone oder -region für gcloud angegeben haben, müssen Sie beim Ausführen dieses Befehls evtl. das Flag --region oder --zone angeben.

2. Prüfen Sie, ob jeder Knotenpool den GKE-Metadatenserver verwendet:

   gcloud container node-pools describe NODEPOOL_NAME \
       --cluster=CLUSTER_NAME \
       --format="value(config.workloadMetadataConfig.mode)"
   

   Ersetzen Sie Folgendes:

   • NODEPOOL_NAME durch den Namen Ihres Knotenpools.
   • CLUSTER_NAME durch den Namen Ihres GKE-Cluster.

3. Wenn die Ausgabe nicht GKE_METADATA enthält, aktualisieren Sie den Knotenpool mithilfe der Anleitung Vorhandenen Knotenpool aktualisieren.

Verwaltetes Container Network Interface (CNI) aktivieren

In diesem Abschnitt wird beschrieben, wie Sie verwaltetes CNI für Cloud Service Mesh in der Google Kubernetes Engine aktivieren.

Verwaltetes CNI – Übersicht

Die verwaltete Container Network Interface (CNI) ist eine von Google verwaltete Implementierung der Istio-CNI. Das CNI-Plug-in optimiert das Pod-Netzwerk durch die Konfiguration von iptables-Regeln. Dadurch wird die Weiterleitung von Traffic zwischen Anwendungen und Envoy-Proxys ermöglicht. Berechtigungen für den Init-Container, die für die Verwaltung von iptables erforderlich sind, sind dann nicht mehr nötig.

Das Istio-CNI-Plug-in ersetzt den istio-init-Container. Der Container istio-init war zuvor für die Einrichtung der Netzwerkumgebung des Pods verantwortlich, um das Abfangen von Traffic für die Istio-Sidecar-Datei zu ermöglichen. Das CNI-Plug-in führt dieselbe Netzwerkweiterleitungsfunktion aus, hat aber den zusätzlichen Vorteil, dass weniger erhöhte Berechtigungen erforderlich sind, was die Sicherheit erhöht.

Aus Gründen der Sicherheit und Zuverlässigkeit sowie zur Vereinfachung der Verwaltung und Fehlerbehebung ist Managed CNI für alle Managed Cloud Service Mesh-Bereitstellungen erforderlich.

Auswirkungen auf Init-Container

Init-Container sind spezielle Container, die vor Anwendungscontainern für Einrichtungsaufgaben ausgeführt werden. Einrichtungsaufgaben können das Herunterladen von Konfigurationsdateien, die Kommunikation mit externen Diensten oder die Initialisierung vor der Anwendung umfassen. Bei Init-Containern, die auf Netzwerkzugriff angewiesen sind, können Probleme auftreten, wenn verwaltetes CNI im Cluster aktiviert ist.

Der Pod-Einrichtungsprozess mit verwaltetem CNI sieht so aus:

1. Das CNI-Plug-in richtet Pod-Netzwerkschnittstellen ein, weist Pod-IPs zu und leitet Traffic an den Istio-Sidecar-Proxy weiter, der noch nicht gestartet wurde.
2. Alle Init-Container werden ausgeführt und abgeschlossen.
3. Der Istio-Sidecar-Proxy wird zusammen mit den Anwendungscontainern gestartet.

Wenn ein Init-Container versucht, ausgehende Netzwerkverbindungen herzustellen oder eine Verbindung zu Diensten innerhalb des Mesh-Netzwerks herzustellen, werden die Netzwerkanfragen von den Init-Containern möglicherweise verworfen oder falsch weitergeleitet. Das liegt daran, dass der Istio-Sidecar-Proxy, der den Netzwerkverkehr für den Pod verwaltet, nicht ausgeführt wird, wenn die Anfragen gestellt werden. Weitere Informationen finden Sie in der Istio-CNI-Dokumentation.

Verwaltetes CNI für Ihren Cluster aktivieren

Führen Sie die Schritte in diesem Abschnitt aus, um verwaltetes CNI in Ihrem Cluster zu aktivieren.

1. Entfernen Sie Netzwerkabhängigkeiten aus Ihrem Init-Container. Sie haben nun zwei Alternativen:

   • Anwendungslogik oder Container ändern: Sie können Ihre Dienste so ändern, dass die Abhängigkeit von Init-Containern, die Netzwerkanfragen erfordern, entfernt wird, oder Netzwerkoperationen in Ihren Anwendungscontainern ausführen, nachdem der Sidecar-Proxy gestartet wurde.
   • Kubernetes-ConfigMaps oder -Secrets verwenden: Speichern Sie Konfigurationsdaten, die von der Netzwerkanfrage abgerufen werden, in Kubernetes-ConfigMaps oder -Secrets und stellen Sie sie in Ihren Anwendungscontainern bereit. Alternative Lösungen finden Sie in der Istio-Dokumentation.

2. Aktivieren Sie verwaltetes CNI in Ihrem Cluster:

   1. Nehmen Sie die folgenden Konfigurationsänderungen vor:

      1. Führen Sie den folgenden Befehl aus, um die controlPlaneRevision zu finden.

         kubectl get controlplanerevision -n istio-system
         

      2. Legen Sie in Ihrer benutzerdefinierten ControlPlaneRevision-Ressource (CPR) das Label mesh.cloud.google.com/managed-cni-enabled auf true fest.

         kubectl label controlplanerevision CPR_NAME \
             -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
             --overwrite
         

         Ersetzen Sie CPR_NAME durch den Wert in der Spalte NAME aus der Ausgabe des vorherigen Schritts.

      3. Legen Sie in der ConfigMap „asm-options“ den Wert ASM_OPTS auf CNI=on fest.

         kubectl patch configmap asm-options -n istio-system \
             -p '{"data":{"ASM_OPTS":"CNI=on"}}'
         

      4. Legen Sie in Ihrer benutzerdefinierten CPR-Ressource (ControlPlaneRevision) die Annotation mesh.cloud.google.com/force-reprovision auf true fest. Durch diese Aktion wird ein Neustart der Steuerungsebene ausgelöst.

         Hinweis: Diese Methode wird nicht für den Neustart der Steuerungsebene empfohlen und sollte nur für die Modernisierung von Cloud Service Mesh verwendet werden.

         kubectl annotate controlplanerevision CPR_NAME \
             -n istio-system mesh.cloud.google.com/force-reprovision=true \
             --overwrite
         

   2. Prüfen Sie den Feature-Status. Rufen Sie den Feature-Status mit dem folgenden Befehl ab:

      gcloud container fleet mesh describe --project FLEET_PROJECT_ID
      

      Ersetzen Sie FLEET_PROJECT_ID durch die ID des Flotten-Hostprojekts. Im Allgemeinen ist die FLEET_PROJECT_ID der Name des Projekts.

      • Prüfen Sie, ob die Bedingung MANAGED_CNI_NOT_ENABLED aus servicemesh.conditions entfernt wurde.
      • Es kann bis zu 15–20 Minuten dauern, bis der Status aktualisiert wird. Warten Sie einige Minuten und führen Sie den Befehl dann noch einmal aus.

   3. Sobald der controlPlaneManagement.state im Feature-Status des Clusters Active ist, starten Sie die Pods neu.

Abkehr von der Verwendung nicht standardmäßiger Binärdateien in Sidecar

In diesem Abschnitt finden Sie Vorschläge, wie Sie Ihre Bereitstellungen mit dem Distroless-Envoy-Proxy-Image kompatibel machen können.

Distroless-Envoy-Proxy-Sidecar-Images

Cloud Service Mesh verwendet zwei Arten von Envoy-Proxy-Sidecar-Images, die auf Ihrer Konfiguration der Steuerungsebene basieren: das Proxy-Image default (mit verschiedenen Debug-Binärdateien) und das Proxy-Image distroless.

Für Cluster mit der verwalteten TRAFFIC_DIRECTOR-Steuerungsebene:

• Direkt eingebundene Cluster: Verwenden standardmäßig distroless-Images.
• Cluster, die von CSM-ISTIOD migriert wurden: Verwenden standardmäßig default-Images. Sie können distroless-Images explizit aktivieren, um Ihren Sicherheitsstatus zu verbessern.

Wenn Sie distroless-Images für einen von CSM-ISTIOD migrierten Cluster aktivieren möchten, können Sie sie global mit defaultConfig.image.imageType: distroless in Ihrer MeshConfig oder pro Arbeitslast mit der Pod-Annotation sidecar.istio.io/proxyImageType: distroless konfigurieren.

Distroless-Basis-Images sind minimale Container-Images, bei denen Sicherheit und Ressourcenoptimierung im Vordergrund stehen, da sie nur wesentliche Komponenten enthalten. Die Angriffsfläche wird verringert, um Sicherheitslücken zu vermeiden. Weitere Informationen finden Sie in der Dokumentation zum Distroless-Proxy-Image.

Binärkompatibilität

Als Best Practice sollten Sie den Inhalt einer Containerlaufzeit auf die erforderlichen Pakete beschränken. Dieser Ansatz verbessert die Sicherheit und das Signal-Rausch-Verhältnis von CVE-Scannen (Common Vulnerabilities and Exposures). Das Distroless-Sidecar-Image hat eine minimale Anzahl von Abhängigkeiten, die von allen nicht wesentlichen ausführbaren Dateien, Bibliotheken und Debugging-Tools befreit sind. Daher ist es nicht möglich, einen Shell-Befehl auszuführen oder curl, ping oder andere Fehlerbehebungsfunktionen wie kubectl exec im Container zu verwenden.

Cluster mit distroless Images kompatibel machen

• Entfernen Sie Verweise auf nicht unterstützte Binärdateien (wie bash oder curl) aus Ihrer Konfiguration. Insbesondere innerhalb von Bereitschafts-, Start- und Aktivitätsprüfungen sowie PostStart- und PreStop-Hooks für den Lebenszyklus in den Containern „istio-proxy“, „istio-init“ oder „istio-validation“.
• Ziehen Sie für bestimmte Anwendungsfälle Alternativen wie holdApplicationUntilProxyStarts in Betracht.
• Zum Debuggen können Sie sitzungsspezifische Container verwenden, um sie an einen laufenden Arbeitslast-Pod anzuhängen. Sie können sie dann prüfen und benutzerdefinierte Befehle ausführen. Ein Beispiel finden Sie unter {service_mesh_name}-Logs erfassen.

Wenn Sie für Ihren speziellen Anwendungsfall keine Lösung finden, wenden Sie sich an den Google Cloud-Support unter Support erhalten.

Zum Istio-Ingress-Gateway migrieren

In diesem Abschnitt erfahren Sie, wie Sie zum Istio Ingress Gateway migrieren. Es gibt zwei Methoden für die Migration zum Istio-Ingress-Gateway:

1. Phasenweise Migration mit Aufteilung des Traffics

   Bei dieser Methode wird die Minimierung von Unterbrechungen priorisiert. Sie senden den Traffic schrittweise an das neue Istio-Gateway, sodass Sie die Leistung bei einem kleinen Prozentsatz von Anfragen überwachen und bei Bedarf schnell rückgängig machen können. Beachten Sie, dass die Konfiguration der Aufteilung des Layer-7-Traffics für einige Anwendungen schwierig sein kann. Daher müssen Sie während der Umstellung beide Gateway-Systeme gleichzeitig verwalten. Die Schritte finden Sie unter Phasenweise Migration mit Aufteilung des Traffics.

2. Direkte Migration

   Bei dieser Methode wird der gesamte Traffic gleichzeitig an das neue Istio-Gateway weitergeleitet, nachdem Sie die Tests gründlich durchgeführt haben. Der Vorteil dieses Ansatzes ist die vollständige Trennung von der Infrastruktur des alten Gateways. So kann das neue Gateway flexibel konfiguriert werden, ohne dass die Einschränkungen der vorhandenen Einrichtung berücksichtigt werden müssen. Es besteht jedoch ein erhöhtes Risiko von Ausfallzeiten, wenn während der Umstellung unerwartete Probleme mit dem neuen Gateway auftreten. Die Schritte finden Sie unter Direkte Migration.

In den folgenden Migrationsbeispielen wird davon ausgegangen, dass Sie einen HTTP-Dienst (httpbin) im Anwendungs-Namespace (Standard) ausführen und extern über die Kubernetes Gateway API bereitstellen. Die relevanten Konfigurationen sind:

• Gateway: k8-api-gateway (im Namespace istio-ingress) – konfiguriert, um HTTP-Traffic auf Port 80 für alle Hostnamen zu überwachen, die auf .example.com enden.
• HTTPRoute: httpbin-route (im Namespace default) – leitet alle HTTP-Anfragen mit dem Hostnamen httpbin.example.com und einem Pfad, der mit /get beginnt, an den Dienst httpbin im Namespace default weiter.
• Die httpbin-Anwendung ist über die externe IP-Adresse 34.57.246.68 erreichbar.

Phasenweise Migration mit Aufteilung des Traffics

Neues Istio-Ingress-Gateway bereitstellen

1. Stellen Sie ein neues Ingress-Gateway bereit. Folgen Sie dazu der Anleitung im Abschnitt Beispiel-Gateway bereitstellen und passen Sie die Beispielkonfigurationen an Ihre Anforderungen an. Die Beispiele im Repository anthos-service-mesh sind für die Bereitstellung eines istio-ingressgateway-LoadBalancer-Dienstes und der entsprechenden ingress-gateway-Pods vorgesehen.

   Beispiel für eine Gateway-Ressource (istio-ingressgateway.yaml)

    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
      name: istio-api-gateway
      namespace: GATEWAY_NAMESPACE
    spec:
      selector:
        istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
      servers:
      - port:
          number: 80
          name: http
          protocol: HTTP
        hosts:   # or specific hostnames if needed
        - "httpbin.example.com"
   

2. Wenden Sie die Gateway-Konfiguration an, um den Traffic zu verwalten:

   kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
   

   Achten Sie darauf, dass „spec.selector“ in Ihrer Gateway-Ressource mit den Labels Ihrer ingress-gateway-Pods übereinstimmt. Wenn die ingress-gateway-Pods beispielsweise das Label istio=ingressgateway haben, muss in Ihrer Gateway-Konfiguration auch dieses istio=ingressgateway-Label ausgewählt werden.

Anfängliches Routing für das neue Gateway konfigurieren

1. Definieren Sie die anfänglichen Routingregeln für Ihre Anwendung mit einem Istio-VirtualService.

   Beispiel für einen VirtualService (my-app-vs-new.yaml):

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: httpbin-vs
     namespace: APPLICATION_NAMESPACE
   spec:
       gateways:
       - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
       hosts:
       - httpbin.example.com
       http:
       - match:
         - uri:
             prefix: /get
         route:
         - destination:
             host: httpbin
             port:
               number: 8000
   

2. Wenden Sie den VirtualService an:

   kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE
   

Über das neu bereitgestellte Istio-Ingress-Gateway auf den Back-End-Dienst (httpbin) zugreifen

1. Legen Sie die Umgebungsvariable für den Ingress-Host auf die externe IP-Adresse fest, die dem kürzlich bereitgestellten istio-ingressgateway-Load-Balancer zugeordnet ist:

   export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   

2. Prüfen Sie, ob die Anwendung (httpbin) über das neue Gateway zugänglich ist:

   curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
   

   Die Ausgabe sieht etwa so aus:

   HTTP/1.1 200 OK
   

Vorhandenen Ingress für die Aufteilung des Traffics ändern

Nachdem Sie die erfolgreiche Einrichtung des neuen Gateways (z. B. istio-api-gateway) bestätigt haben, können Sie einen Teil des Traffics darüber weiterleiten. Aktualisieren Sie dazu Ihre aktuelle HTTPRoute, um einen kleinen Prozentsatz des Traffics an das neue Gateway weiterzuleiten, während der größere Teil weiterhin das vorhandene Gateway (k8-api-gateway) verwendet.

1. Öffnen Sie die HTTPRoute zum Bearbeiten:

   kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE
   

2. Fügen Sie eine neue Backend-Referenz hinzu, die auf den Load-Balancer-Dienst des neuen Ingress-Gateways verweist, mit einer anfänglichen Gewichtung von 10% und aktualisieren Sie die Gewichtung für das Backend des alten Gateways.

   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: httpbin-route
     namespace: MY_APP_NAMESPACE  # your application's namespace
   spec:
     parentRefs:
     - name: k8-api-gateway
       namespace: istio-ingress
     hostnames: ["httpbin.example.com"]
     rules:
     - matches:
       - path:
           type: PathPrefix
           value: /get
       backendRefs:
       - name: httpbin
         port: 8000
         weight: 90
       - name: istio-ingressgateway # Newly deployed load balancer service
         namespace: GATEWAY_NAMESPACE
         port: 80
         weight: 10
   

3. Gewähren Sie die Berechtigung für Namespace-übergreifende Verweise mit einer Referenzgewährung.

   Damit Ihr HTTPRoute im Anwendungs-Namespace (Standard) auf den loadbalancer-Dienst im Gateway-Namespace (istio-ingress) zugreifen kann, müssen Sie möglicherweise eine Referenzgewährung erstellen. Diese Ressource dient als Sicherheitskontrolle und definiert explizit, welche Namespace-übergreifenden Referenzen zulässig sind.

   Im folgenden istio-ingress-grant.yaml wird eine Beispiel-Referenzgewährung beschrieben:

   apiVersion: gateway.networking.k8s.io/v1beta1
   kind: ReferenceGrant
   metadata:
     name: istio-ingressgateway-grant
     namespace: istio-ingress # Namespace of the referenced resource
   spec:
     from:
     - group: gateway.networking.k8s.io
       kind: HTTPRoute
       namespace: MY_APP_NAMESPACE # Namespace of the referencing resource
     to:
     - group: ""               # Core Kubernetes API group for Services
       kind: Service
       name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway
   

4. Wenden Sie die Referenzgewährung an:

   kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE
   

5. Anfragen an vorhandene externe IP-Adresse prüfen (z. B. 34.57.246.68) schlagen nicht fehl. Im Folgenden wird ein check-traffic-flow.sh-Skript beschrieben, mit dem fehlgeschlagene Anfragen geprüft werden können:

   # Update the following values based on your application setup
   external_ip="34.57.246.68" # Replace with existing external IP
   url="http://$external_ip/get"
   host_name="httpbin.example.com"
   
   # Counter for successful requests
   success_count=0
   
   # Loop 50 times
   for i in {1..50}; do
     # Perform the curl request and capture the status code
     status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url")
     # Check if the request was successful (status code 200)
     if [ "$status_code" -eq 200 ]; then
       ((success_count++))  # Increment the success counter
     else
       echo "Request $i: Failed with status code $status_code"
     fi
   done
   
   # After the loop, check if all requests were successful
   if [ "$success_count" -eq 50 ]; then
     echo "All 50 requests were successful!"
   else
     echo "Some requests failed.  Successful requests: $success_count"
   fi
   

6. Führen Sie das Script aus, um zu prüfen, ob alle Anfragen unabhängig von der Traffic-Route erfolgreich sind:

   chmod +x check-traffic-flow.sh
   ./check-traffic-flow.sh
   

Traffic-Prozentsatz langsam erhöhen

Wenn für die vorhandene externe IP-Adresse (z. B. 34.57.246.68) keine Anfragefehler auftreten, verlagern Sie nach und nach mehr Traffic auf das neue Istio-Ingress-Gateway, indem Sie die Backend-Gewichtungen in Ihrer HTTPRoute anpassen. Erhöhen Sie die Gewichtung für istio-ingressgateway und verringern Sie die Gewichtung für das alte Gateway in kleinen Schritten, z. B. 10%, 20 % usw.

Wichtig: Behalten Sie wichtige Messwerte wie die Erfolgsquote von Anfragen, die Latenz, die Fehlerraten und die Ressourcennutzung Ihrer Anwendungspods im Auge, um die Stabilität bei jedem Schritt zu gewährleisten.

Verwenden Sie den folgenden Befehl, um die vorhandene HTTPRoute zu aktualisieren:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Vollständige Trafficmigration und Entfernen des alten Gateways

1. Wenn das neue Istio-Ingress-Gateway eine stabile Leistung und eine erfolgreiche Anfrageverarbeitung zeigt, leiten Sie den gesamten Traffic dorthin weiter. Aktualisieren Sie Ihre HTTPRoute, um die Backend-Gewichtung des alten Gateways auf 0 und die des neuen Gateways auf 100 festzulegen.

2. Sobald der Traffic vollständig an das neue Gateway weitergeleitet wird, aktualisieren Sie Ihre externen DNS-Einträge für den Hostnamen Ihrer Anwendung (z. B. httpbin.example.com), sodass sie auf die externe IP-Adresse des Load-Balancer-Dienstes verweisen, der in Neues Istio-Ingress-Gateway bereitstellen erstellt wurde.

3. Löschen Sie schließlich das alte Gateway und die zugehörigen Ressourcen:

   kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
   kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE
   

Direkte Migration

Neues Istio-Ingress-Gateway bereitstellen

1. Stellen Sie ein neues Ingress-Gateway bereit. Folgen Sie dazu der Anleitung im Abschnitt Beispiel-Gateway bereitstellen und passen Sie die Beispielkonfigurationen an Ihre Anforderungen an. Die Beispiele im Repository anthos-service-mesh sind für die Bereitstellung eines istio-ingressgateway-LoadBalancer-Dienstes und der entsprechenden ingress-gateway-Pods vorgesehen.

   Beispiel für eine Gateway-Ressource (istio-ingressgateway.yaml)

    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
      name: istio-api-gateway
      namespace: GATEWAY_NAMESPACE
    spec:
      selector:
        istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
      servers:
      - port:
          number: 80
          name: http
          protocol: HTTP
        hosts:   # or specific hostnames if needed
        - "httpbin.example.com"
   

2. Wenden Sie die Gateway-Konfiguration an, um den Traffic zu verwalten:

   kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
   

   Achten Sie darauf, dass „spec.selector“ in Ihrer Gateway-Ressource mit den Labels Ihrer ingress-gateway-Pods übereinstimmt. Wenn die ingress-gateway-Pods beispielsweise das Label istio=ingressgateway haben, muss in Ihrer Gateway-Konfiguration auch dieses istio=ingressgateway-Label ausgewählt werden.

Anfängliches Routing für das neue Gateway konfigurieren

1. Definieren Sie die anfänglichen Routingregeln für Ihre Anwendung mit einem Istio-VirtualService.

   Beispiel für einen VirtualService (my-app-vs-new.yaml):

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: httpbin-vs
     namespace: APPLICATION_NAMESPACE
   spec:
       gateways:
       - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
       hosts:
       - httpbin.example.com
       http:
       - match:
         - uri:
             prefix: /get
         route:
         - destination:
             host: httpbin
             port:
               number: 8000
   

2. Wenden Sie den VirtualService an:

   kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE
   

Über das neu bereitgestellte Istio-Ingress-Gateway auf den Back-End-Dienst (httpbin) zugreifen

1. Legen Sie die Umgebungsvariable für den Ingress-Host auf die externe IP-Adresse fest, die dem kürzlich bereitgestellten istio-ingressgateway-Load-Balancer zugeordnet ist:

   export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
   

2. Prüfen Sie, ob die Anwendung (httpbin) über das neue Gateway zugänglich ist:

   curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
   

   Die Ausgabe sieht etwa so aus:

   HTTP/1.1 200 OK
   

Neues Gateway testen und überwachen

1. Testen Sie alle Routingregeln und validieren Sie die TLS-Konfiguration, Sicherheitsrichtlinien und andere Funktionen. Führen Sie einen Lasttest durch, um zu prüfen, ob das neue Gateway den erwarteten Traffic verarbeiten kann.

2. Nachdem das neue Gateway vollständig getestet wurde, aktualisieren Sie die externen DNS-Einträge für den Hostnamen Ihrer Anwendung (z. B. httpbin.example.com), sodass sie auf die externe IP-Adresse des Load-Balancer-Dienstes verweisen, der unter Neues Istio-Ingress-Gateway bereitstellen erstellt wurde.

3. Überwachen Sie wichtige Messwerte wie die Erfolgsquote von Anfragen, die Latenz, die Fehlerraten und die Ressourcennutzung Ihrer Anwendungs-Pods, um die Stabilität mit dem neuen Istio Ingress Gateway zu prüfen. Sobald das neue Gateway stabil ist, können Sie das alte Gateway und die zugehörigen Ressourcen löschen.

   kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
   kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE
   

Wichtige Hinweise: Wenn Ihre Anwendung HTTPS erfordert, müssen TLS-Zertifikate und -Konfigurationen auf dem neuen Istio Ingress-Gateway korrekt eingerichtet sein. Weitere Informationen finden Sie unter TLS-Terminierung im Ingress-Gateway einrichten.

Mehrere Steuerungsebenen korrigieren

Cloud Service Mesh unterstützte zuvor das Onboarding mit asmcli (eingestellt), wodurch die Bereitstellung mehrerer Steuerungsebenen nicht blockiert wurde. Cloud Service Mesh erzwingt jetzt die Best Practice, nur einen Kanal pro Cluster bereitzustellen, der dem Clusterkanal entspricht. Die Verwendung mehrerer bereitgestellter Kanäle im selben Cluster wird nicht unterstützt.

Wenn Sie Canary-Deployments für neue Versionen des Mesh im Rapid-Channel durchführen möchten, bevor sie im Stable- oder Regular-Channel verfügbar sind, müssen Sie zwei verschiedene Cluster verwenden, die jeweils einen separaten Channel haben. Beachten Sie, dass die Kanäle vom GKE-Clusterkanal gesteuert werden und Mesh kein separater Kanal zugeordnet ist.

Ob Sie mehrere Kanäle haben, können Sie anhand der Statusbedingung UNSUPPORTED_MULTIPLE_CONTROL_PLANES Ihrer Mitgliedschaft prüfen. Wenn diese Warnung nicht angezeigt wird, sind Sie nicht betroffen und können diesen Abschnitt überspringen.

1. Führen Sie den folgenden Befehl aus, um zu prüfen, ob Ihr Cluster mehrere Kanäle für die Steuerungsebene hat:

   gcloud container fleet mesh describe
   

   Die Ausgabe sieht etwa so aus:

   ...
   projects/.../locations/global/memberships/my-membership:
       servicemesh:
         conditions:
         - code: UNSUPPORTED_MULTIPLE_CONTROL_PLANES
           details: 'Using multiple control planes is not supported. Please remove a control plane from your cluster.'
           documentationLink: https://cloud.google.com/service-mesh/v1.30/docs/migrate/modernization-configuration-updates#multiple_control_planes
           severity: WARNING
         controlPlaneManagement:
           details:
           - code: REVISION_READY
             details: 'Ready: asm-managed-stable'
           implementation: ISTIOD
           state: ACTIVE
   ...
   

2. Wenn die Bedingung UNSUPPORTED_MULTIPLE_CONTROL_PLANES angezeigt wird, ermitteln Sie, welche Kanäle für Ihren Cluster vorhanden sind:

   kubectl get controlplanerevisions -n istio-system
   

   Die Ausgabe sieht etwa so aus:

   NAME                 RECONCILED   STALLED   AGE
   asm-managed-stable   True         False     97d
   asm-managed          True         False     97d
   asm-managed-rapid    True         False     97d
   

   In diesem Beispiel wurden alle drei Kanäle bereitgestellt:

   • asm-managed-stable -> STABLE
   • asm-managed -> REGULAR
   • asm-managed-rapid -> RAPID

   Wenn nur ein Ergebnis angezeigt wird, ist nur ein Kanal auf Ihrem Cluster bereitgestellt und Sie können die restlichen Schritte überspringen.

   Wenn zwei oder mehr Ergebnisse angezeigt werden, führen Sie die restlichen Schritte aus, um die überzähligen Kanäle zu entfernen.

Arbeitslasten in einem Kanal konsolidieren

Bevor Sie zusätzliche Kanäle entfernen können, müssen Sie dafür sorgen, dass Ihre Arbeitslasten nur einen einzigen Kanal verwenden.

1. Suchen Sie alle Labels, die Sie in Ihrem Cluster verwenden:

   kubectl get namespaces -l istio.io/rev=RELEASE_CHANNEL
   

   Ersetzen Sie RELEASE_CHANNEL je nach Ausgabe des vorherigen Befehls durch asm-managed-stable, asm-managed oder asm-managed-rapid. Wiederholen Sie diesen Schritt für jeden bereitgestellten Kanal.

   Die Ausgabe sieht etwa so aus:

   NAME      STATUS   AGE
   default   Active   110d
   

   Beachten Sie, dass in diesem Beispiel der Standard-Namespace mit dem Regular channel eingefügt wird.

   Wenn alle Ihre Arbeitslasten bereits denselben Kanal verwenden, können Sie mit dem Schritt Zusätzliche Kanäle entfernen fortfahren. Andernfalls fahren Sie mit diesem Abschnitt fort.

2. Ändern Sie die Labels so, dass nur ein Kanal verwendet wird:

   Achtung: Beachten Sie Folgendes, bevor Sie Labels ändern.
   • Pods können in einigen Fällen auch direkt mit dem Label sidecar.istio.io/inject eingefügt werden. Prüfen Sie auch diese auf die entsprechende Verwendung.
   • Sie können istio-injection=enabled-Labels für diesen Schritt ignorieren. Namespaces mit diesem Label werden automatisch so geändert, dass sie mit dem Kanal übereinstimmen, der im Cluster verbleibt.
   • Wählen Sie nach Möglichkeit den Kanal aus, der mit dem GKE-Clusterkanal übereinstimmt. Wenn dieser Kanal nicht vorhanden ist, wählen Sie einen der aktiven Kanäle aus.
   • Welchen Kanal Sie auswählen, spielt keine Rolle. Die GKE-Clusterversion bestimmt, welche Version des Mesh-Netzwerks Sie erhalten, nicht die Mesh-Version.
   • Prüfen Sie die meshconfig-Konfiguration zwischen allen aktiven Kanälen, die verwendet werden, um sicherzustellen, dass es keine Unterschiede zwischen ihnen gibt. Jeder Kanal verwendet eine separate ConfigMap für die Konfiguration. Wenn Sie zwei Kanäle zu einem zusammenfassen, sollte das Verhalten zwischen den beiden Kanälen konsistent sein. kubectl get configmap istio-asm-managed{-rapid | -stable} -n istio-system -o yaml

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

   Ersetzen Sie NAMESPACE durch den Namen Ihres Namespace:

   Als Best Practice wird empfohlen, istio-injection=enabled zu verwenden. Wenn Sie dieses Label jedoch nicht verwenden möchten, können Sie auch istio.io/rev=RELEASE_CHANNEL verwenden.

   Nachdem Sie das Label für einen Namespace / Pod geändert haben, müssen Sie alle Arbeitslasten neu starten, damit sie von der richtigen Steuerungsebene eingefügt werden.

Entfernen Sie die zusätzlichen Kanäle.

Nachdem Sie überprüft haben, dass alle Ihre Arbeitslasten auf einem einzigen Kanal ausgeführt werden, können Sie die nicht verwendeten zusätzlichen Kanäle entfernen. Wenn alle drei Release-Versionen bereitgestellt wurden, müssen Sie die folgenden Befehle für jede Version ausführen.

1. Löschen Sie die zusätzliche ControlPlaneRevision-Ressource:

   kubectl delete controlplanerevision RELEASE_CHANNEL -n istio-system
   

   Ersetzen Sie RELEASE_CHANNEL durch asm-managed-stable, asm-managed oder asm-managed-rapid.

2. Löschen Sie das MutatingWebhookConfiguration:

   kubectl delete mutatingwebhookconfiguration istiod-RELEASE_CHANNEL
   

3. Löschen Sie die ConfigMap meshconfig:

   kubectl delete configmap istio-RELEASE_CHANNEL
   

Automatische Verwaltung aktivieren

Achtung: Wenn Sie die automatische Verwaltung der Steuerungsebene aktivieren, werden Multi-Cluster und die verwaltete Datenebene für diesen Cluster automatisch aktiviert.

1. Führen Sie den folgenden Befehl aus, um die automatische Verwaltung zu aktivieren:

   gcloud container fleet mesh update \
       --management automatic \
       --memberships MEMBERSHIP_NAME \
       --project PROJECT_ID \
       --location MEMBERSHIP_LOCATION
   

   Ersetzen Sie Folgendes:

   • MEMBERSHIP_NAME ist der Name der Mitgliedschaft, der bei der Registrierung des Clusters bei der Flotte aufgeführt wurde.
   • PROJECT_ID ist die Projekt-ID Ihres Projekts.
   • MEMBERSHIP_LOCATION ist der Standort Ihrer Mitgliedschaft (entweder eine Region oder global). Sie können den Standort Ihrer Mitgliedschaft mit gcloud container fleet memberships list --project PROJECT_ID prüfen.

2. Prüfen Sie, ob die automatische Verwaltung aktiviert ist:

   gcloud container fleet mesh describe
   

   Die Ausgabe sieht etwa so aus:

   ...
   membershipSpecs:
     projects/.../locations/us-central1/memberships/my-member:
       mesh:
         management: MANAGEMENT_AUTOMATIC
   membershipStates:
     projects/.../locations/us-central1/memberships/my-member:
       servicemesh:
         conditions:
         - code: VPCSC_GA_SUPPORTED
           details: This control plane supports VPC-SC GA.
           documentationLink: http://cloud.google.com/service-mesh/v1.30/docs/managed/vpc-sc
           severity: INFO
         controlPlaneManagement:
           details:
           - code: REVISION_READY
             details: 'Ready: asm-managed'
           implementation: TRAFFIC_DIRECTOR
           state: ACTIVE
         dataPlaneManagement:
           details:
           - code: OK
             details: Service is running.
           state: ACTIVE
       state:
         code: OK
         description: |-
           Revision ready for use: asm-managed.
           All Canonical Services have been reconciled successfully.
   ...
   

EnvoyFilter-Kompressorkonfigurationen modernisieren

Wenn Sie den Filter envoy.extensions.filters.http.compressor.v3.Compressor verwenden, wurden mehrere Felder auf oberster Ebene in Envoy verworfen und nach response_direction_config.common_config und request_direction_config.common_config verschoben.

Informationen zum Aktualisieren Ihrer EnvoyFilter-Ressourcen auf das moderne und unterstützte Format finden Sie im Leitfaden EnvoyFilter-Kompressorkonfigurationen modernisieren.

Erforderliche Organisationsrichtlinie aktivieren

Für Cloud Service Mesh müssen bestimmte Richtlinien aktiviert sein, damit es ordnungsgemäß funktioniert.

Erforderliche Richtlinien

compute.disableInternetNetworkEndpointGroup

Cloud Service Mesh erfordert die Möglichkeit, Internetnetzwerk-Endpunktgruppen (NEGs) zu erstellen. Diese NEGs sind wichtige Komponenten für das Routing von Traffic zu Diensten außerhalb von Google Cloud.

Die Einschränkung constraints/compute.disableInternetNetworkEndpointGroup kann die Erstellung dieser erforderlichen Internet-NEGs verhindern.

Wenn diese Organisationsrichtlinie für Ihr Projekt, Ihren Ordner oder Ihre Organisation erzwungen wird, kann Cloud Service Mesh nicht ordnungsgemäß mit der Traffic Director-Steuerungsebene funktionieren. Dadurch wird die Migration zu dieser Cloud Service Mesh-Konfiguration oder der erfolgreiche Betrieb dieser Konfiguration verhindert.

Wenn Enforced auf true gesetzt ist, ist das Erstellen von Internet-NEGs deaktiviert.

Woher weiß ich, ob ich betroffen bin?

Sie können die geltende Richtlinie für Ihr Projekt mit der Google Cloud Console oder der Google Cloud CLI prüfen. Eine Anleitung zum Aufrufen von Organisationsrichtlinien finden Sie im Abschnitt Organisationsrichtlinien aufrufen der offiziellen Dokumentation.

Sie können beispielsweise diesen Google Cloud CLI-Befehl verwenden:

gcloud resource-manager org-policies describe constraints/compute.disableInternetNetworkEndpointGroup --project YOUR_PROJECT_ID --effective

Wenn die Richtlinie den Wert enforced: true hat, sind Sie betroffen.

constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy:
  enforced: true

Wenn die Richtlinie einen anderen Wert hat oder leer ist, sind Sie nicht betroffen.

constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy: {}

Problem beheben

Wenn die Richtlinie erzwungen wird, müssen Sie diese Einschränkung auf Organisations-, Ordner- oder Projektebene deaktivieren (auf false setzen).

Eine ausführliche Anleitung zum Ändern von Organisationsrichtlinien, einschließlich boolescher Einschränkungen wie dieser, finden Sie im Leitfaden Organisationsrichtlinien erstellen und verwalten. In der Regel benötigen Sie die Rolle roles/orgpolicy.policyAdmin, um diese Änderungen vorzunehmen.

Berechtigungen für gemeinsam genutzte VPCs

Wenn Sie das verwaltete Cloud Service Mesh mit einer freigegebene VPC verwenden, in der sich Ihre Cluster in einem Dienstprojekt und das VPC-Netzwerk in einem Hostprojekt befinden, sind zusätzliche Berechtigungen für den Cloud Service Mesh-Dienst-Agent im Fleet-Projekt erforderlich.

Im Rahmen der Migration zu einer TRAFFIC_DIRECTOR-Steuerungsebene benötigt Cloud Service Mesh Berechtigungen zum Verwalten von Firewallregeln im Hostprojekt, um eine ordnungsgemäße Systemdiagnose und Netzwerkfunktionalität zu gewährleisten. Dies war für die vorherige ISTIOD-Steuerungsebene nicht erforderlich.

Woher weiß ich, ob ich betroffen bin?

Sie sind betroffen, wenn:

1. Ihre GKE-Cluster befinden sich in einem Dienstprojekt.
2. Diese Cluster verwenden ein freigegebene VPC-Netzwerk, das in einem anderen Projekt (dem VPC-Hostprojekt) gehostet wird.
3. Der Cloud Service Mesh-Dienst-Agent des Flottenprojekts ist nicht berechtigt, Firewallregeln im VPC-Hostprojekt zu verwalten.

Möglicherweise wird im Feature-Status Ihrer Flotte eine Warnung mit dem Code SHARED_VPC_MISSING_PERMISSIONS angezeigt. Weitere Informationen zum Verstehen und Beheben dieses Problems, einschließlich system- und nutzerverwalteter Optionen, finden Sie unter Integritätsprüfungen verstehen.

Fehlende Konfiguration der Steuerungsebene

In den Best Practices von Cloud Service Mesh für die Verwaltung eines Service Mesh wird die Google Kubernetes Engine Fleet API verwendet, um das Feld „Management“ auf AUTOMATIC festzulegen. Dies ermöglicht die vollständig automatische Verwaltung vieler Mesh-Funktionen wie Webhooks und der Steuerungsebene. Außerdem wird der Cluster so eingerichtet, dass er automatisch neue Updates und Funktionen erhält, sobald sie veröffentlicht werden. Bei einigen Legacy-Installationsmethoden wurde Cloud Service Mesh nicht auf diese Weise konfiguriert. Sie müssen einige manuelle Schritte ausführen, um sie zu patchen.

Woher weiß ich, ob ich betroffen bin?

Prüfen Sie, ob Sie ein ControlPlaneRevision in Ihrem Cluster haben:

kubectl get controlplanerevisions -n istio-system

Wenn Sie bereits einen ControlPlaneRevision in Ihrem Cluster haben, gilt diese Anleitung nicht für Sie. Wenn Sie keinen ControlPlaneRevision haben, können Sie Ihre Cluster anhand dieser Anleitung modernisieren.

Hinweis: Es gibt ein bekanntes Problem, bei dem die Warnung MISSING_CONTROL_PLANE_CONFIG gemeldet wird, obwohl Ihr Cluster bereits einen ControlPlaneRevision hat. Das passiert, wenn Ihr Cluster zuvor mehr als einen Kanal für die Steuerungsebene hatte und Sie die ControlPlaneRevision für einen dieser Kanäle gelöscht haben. Wenn der vorherige Befehl mindestens einen ControlPlaneRevision zurückgibt, ist Ihr Mesh-Netzwerk richtig konfiguriert, es sind keine Maßnahmen erforderlich und Sie können die Warnung ignorieren.

Wenn Sie die Warnung MISSING_CONTROL_PLANE_CONFIG erhalten und Cloud Service Mesh nicht verwenden möchten, deaktivieren Sie Cloud Service Mesh.

Modernisierungsschritte

Führen Sie die folgenden Schritte aus, um festzustellen, was getan werden muss, um Ihre Konfiguration an die aktuellen Standards anzupassen.

gcloud container fleet mesh describe --project PROJECT_ID

Führen Sie je nach Ausgabe die folgenden Schritte aus:

Ausgabe	Auszuführender Schritt
API [gkehub.googleapis.com] not enabled on project [my-project]. Would you like to enable and retry (this will take a few minutes)? (y/N)?	Antworte mit y und versuche es noch einmal.
ERROR: (gcloud.container.fleet.mesh.describe) Service Mesh Feature for project [my-project] is not enabled	Fahren Sie mit 1. Mesh-Funktion aktivieren.
... resourceState: state: ACTIVE ...	Fahren Sie mit 2. Registrieren Sie den Cluster bei einer Flotte.

1. Mesh-Funktion aktivieren

Das Mesh-Feature kann mit dem folgenden Befehl aktiviert werden. Dadurch kann Cloud Service Mesh in Ihrem Projekt ausgeführt werden. Weitere Informationen und mögliche Nebenwirkungen finden Sie unter Service Mesh bereitstellen.

gcloud container fleet mesh enable --project PROJECT_ID

Fahren Sie nach dem Aktivieren des Mesh-Features mit 2 fort. Registrieren Sie den Cluster bei einer Flotte.

2. Cluster bei einer Flotte registrieren

Prüfen Sie, ob Ihr Cluster bereits in der Flotte registriert ist:

gcloud container fleet memberships list --project PROJECT_ID

Wenn Ihr Cluster nicht aufgeführt ist, folgen Sie dieser Anleitung, um ihn zu registrieren: Cluster bei der Flotte registrieren.

Wenn Sie einen Cluster bei Ihrer Flotte registrieren, kann dieser Cluster Features wie Cloud Service Mesh über die Flotte verwalten.

3. Mesh-Kanal bestimmen

Cloud Service Mesh hängt vom Google Kubernetes Engine-Kanal Ihres Clusters und nicht von einem unabhängigen Mesh-Kanal ab. In der Vergangenheit unterstützte Cloud Service Mesh die Auswahl eines oder mehrerer Mesh-Kanäle (die sich vom Google Kubernetes Engine-Clusterkanal unterscheiden). Möglicherweise haben Sie in Ihrer Mesh-Konfiguration noch Verweise auf diese Kanäle.

Bestimmen Sie zuerst, welche Kanäle Sie verwenden. Wenn Sie mehrere Kanäle verwenden, folgen Sie der Anleitung unter Mehrere Steuerungsebenen korrigieren, um die Nutzung auf einen einzelnen Kanal zu reduzieren.

Prüfen Sie die Labels in Ihren Namespaces, um festzustellen, welchen Mesh-Kanal Sie verwenden. Möglicherweise müssen Sie auch Arbeitslasten prüfen, wenn Sie Injektionslabels speziell für Arbeitslasten hinzugefügt haben. Mit dem folgenden Befehl werden alle Arbeitslasten im Cluster geprüft und die Ausgabe wird so gefiltert, dass die für diese Arbeitslasten verwendeten Steuerungsebenen und Injektions-Tags angezeigt werden.

kubectl get namespaces,pods,deployments,statefulsets,daemonsets --all-namespaces --show-labels | grep -E "istio.io/rev|istio-injection"

Wenn Sie benutzerdefinierte Tags oder Webhooks manuell erstellt haben, müssen Sie diese ebenfalls prüfen.

Die Ausgabe sieht etwa so aus:

namespace/default                                 Active   153d   istio-injection=enabled,istio.io/rev=asm-managed,kubernetes.io/metadata.name=default
namespace/payments                                Active   42d    istio.io/rev=asm-managed-stable,kubernetes.io/metadata.name=payments
default    pod/frontend-847f569874-v9kjz          2/2      Running  0   2m     app=frontend,istio.io/rev=asm-managed,pod-template-hash=847f569874
payments   pod/checkout-0                         2/2      Running  0   5d     app=checkout,istio.io/rev=asm-managed-stable,controller-revision-hash=5c68b9487
default    deployment.apps/frontend               1/1      1        1   153d   app=frontend,istio.io/rev=asm-managed
payments   statefulset.apps/checkout              1/1      1        1   42d    app=checkout,istio.io/rev=asm-managed-stable

Notieren Sie sich die Werte für istio.io/rev={channel}. Die Namen werden den Kanälen so zugeordnet. Wenn mehrere Kanäle verwendet werden, folgen Sie der Anleitung unter Mehrere Steuerungsebenen korrigieren, um die Anzahl auf einen einzelnen Kanal zu reduzieren:

Wert	Kanal
asm-managed-stable	Stabil
asm-managed	Regulär
asm-managed-rapid	Rapid

Wenn Ihr Mesh-Kanal mit dem Google Kubernetes Engine-Clusterkanal übereinstimmt, fahren Sie mit Schritt 5 fort.

4. ControlPlaneRevision-Ressource für Ihren Mesh-Kanal erstellen

Wenn Ihr Mesh-Kanal mit dem Google Kubernetes Engine-Clusterkanal übereinstimmt, können Sie diesen Schritt überspringen. Wenn Sie die automatische Verwaltung der Steuerungsebene aktivieren, wird diese ControlPlaneRevision-Ressource automatisch erstellt, wenn Ihr Kanal mit dem Clusterkanal übereinstimmt.

Erstellen Sie eine ControlPlaneRevision-Ressource für den verwendeten Mesh-Kanal:

Stabil

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed-stable
  namespace: istio-system
spec:
  type: managed_service
  channel: stable
EOF

Regulär

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed
  namespace: istio-system
spec:
  type: managed_service
  channel: regular
EOF

Rapid

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed-rapid
  namespace: istio-system
spec:
  type: managed_service
  channel: rapid
EOF

5. Automatische Verwaltung aktivieren

Achtung: Das Aktivieren der automatischen Verwaltung der Steuerungsebene hat Nebenwirkungen, z. B. die automatische Aktivierung der Endpunkterkennung für mehrere Cluster und der verwalteten Datenebene.

Wenn Sie die Endpunkterkennung für mehrere Cluster deaktivieren möchten, folgen Sie der Anleitung zum Deaktivieren unter Deklarative API für die Endpunkterkennung, bevor Sie die automatische Verwaltung der Steuerungsebene aktivieren.

Wenn Sie die verwaltete Datenebene deaktivieren möchten, folgen Sie der Anleitung unter Verwaltete Datenebene deaktivieren.

Führen Sie den folgenden Befehl aus, um die automatische Verwaltung zu aktivieren. Dadurch kann das von der Flotte verwaltete Cloud Service Mesh die Konfiguration der Steuerungsebene Ihres Clusters verwalten.

gcloud container fleet mesh update --management automatic --memberships MY_CLUSTER_MEMBERSHIP --project PROJECT_ID

Ersetzen Sie MY_CLUSTER_MEMBERSHIP durch den Namen Ihres Clusters.

6. Installation prüfen

Führen Sie dazu diesen Befehl aus:

gcloud container fleet mesh describe --project PROJECT_ID

Die Ausgabe sieht etwa so aus:

createTime: '2025-02-24T22:10:10.826263363Z'
etag: XjjRZB3-ZsueoaKihEBUupYhMDUjvoSyUHTVD2YgR6k
membershipSpecs:
  projects/1234567890/locations/us-central1/memberships/my-cluster-membership:
    mesh:
      management: MANAGEMENT_AUTOMATIC # See item 1 below
membershipStates:
  projects/1234567890/locations/us-central1/memberships/my-cluster-membership:
    servicemesh:
      conditions: [] # See item 2 below
      controlPlaneManagement: # See item 3 below
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        implementation: TRAFFIC_DIRECTOR
        state: ACTIVE
      dataPlaneManagement: # See item 4 below
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: |-
        Revision ready for use: asm-managed.
        All Canonical Services have been reconciled successfully.
      updateTime: '2025-06-17T23:39:05.267540058Z'
name: projects/my-project/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
spec: {}
updateTime: '2025-02-25T04:12:16.280672401Z'

1. In membershipSpecs hat jede Mitgliedschaft in Ihrer Flotte eine separate Spezifikation. Achten Sie darauf, dass für jedes Mitglied die Verwaltung korrekt auf MANAGEMENT_AUTOMATIC festgelegt ist.
2. Jeder Mitgliedschaft ist eine Liste von Statusbedingungen zugeordnet. Achten Sie darauf, dass hier keine Fehler oder Warnungen angezeigt werden, und folgen Sie den Links zur Dokumentation, um Probleme zu beheben.
3. controlPlaneManagement enthält den Status Ihrer Steuerungsebene. Prüfen Sie, ob die Steuerungsebene den Status ACTIVE hat.
4. dataPlaneManagement enthält den Status der Datenebene. Es wird empfohlen, diese Option zu aktivieren.