Verwaltete Cloud Service Mesh-Steuerungsebene in GKE bereitstellen

Cloud Service Mesh ist ein von Google verwaltetes Service Mesh, das Sie einfach aktivieren. Google übernimmt die Zuverlässigkeit, Upgrades, Skalierung und Sicherheit für Sie.

Auf dieser Seite erfahren Sie, wie Sie die Flotten-API zur Einrichtung verwalteter Cloud Service Mesh mit Istio APIs

Vorbereitung

Sie sollten Folgendes bereits haben:

Voraussetzungen

  • Ein oder mehrere Cluster mit einer unterstützten Version von GKE in einer der unterstützten Regionen.
  • Sorgen Sie dafür, dass Ihr Cluster genügend Kapazität für die erforderlichen Komponenten hat, verwaltete Cloud Service Mesh-Installationen im Cluster.
    • Das Deployment mdp-controller im Namespace kube-system fordert CPU an: 50 m, Arbeitsspeicher: 128 Mi
    • Das Daemonset istio-cni-node im Namespace kube-system fordert CPU an: 100m, Arbeitsspeicher: 100 Mi auf jedem Knoten.
  • Achten Sie darauf, dass der Clientcomputer, auf dem Sie das verwaltete Cloud Service Mesh bereitstellen, Netzwerkverbindung zum API-Server.
  • Ihre Cluster müssen in einer Flotte registriert sein. Dies ist in der Anleitung enthalten oder kann vor der Bereitstellung separat durchgeführt werden.
  • In Ihrem Projekt muss das Service Mesh Flotten-Feature aktiviert sein. Dies ist in der Anleitung enthalten oder kann separat durchgeführt werden.
  • GKE Autopilot wird nur mit der GKE-Version unterstützt 1.21.3+.

  • Cloud Service Mesh kann mehrere GKE-Cluster in einem Umgebung mit einem Projekt und einem Netzwerk oder einem Netzwerk mit mehreren Projekten zu verbessern.

    • Wenn Sie Cluster zusammenführen, die sich nicht im selben Projekt befinden, müssen sie im selben Flottenhostprojekt registriert sein und die Cluster müssen sich zusammen in einer Konfiguration mit freigegebener VPC im selben Netzwerk befinden.
    • Bei einer Multi-Cluster-Umgebung mit einem Projekt kann das Flottenprojekt wie das Clusterprojekt. Weitere Informationen zu Flotten finden Sie unter Flottenübersicht.
    • Bei einer Umgebung mit mehreren Projekten empfehlen wir, die Flotte in einer von den Clusterprojekten trennen. Wenn Ihre Organisation und die vorhandene Konfiguration dies zulassen, empfehlen wir die Verwendung von das freigegebene VPC-Projekt als Flotten-Hostprojekt. Weitere Informationen finden Sie unter Cluster mit freigegebener VPC einrichten.

Zum Installieren von Cloud Service Mesh erforderliche Rollen

In der folgenden Tabelle werden die Rollen beschrieben, die für die Installation von verwalteten Cloud Service Mesh.

Rollenname Rollen-ID Standort erteilen Beschreibung
GKE-Hub-Administrator roles/gkehub.admin Flottenprojekt Vollständiger Zugriff auf GKE-Hubs und zugehörige Ressourcen.
Service Usage-Administrator roles/serviceusage.serviceUsageAdmin Flottenprojekt Erlaubnis, Dienststatus zu aktivieren, zu deaktivieren und Zustände zu überprüfen, Vorgänge zu überprüfen, sowie Kontingent und Abrechnung für ein Nutzerprojekt zu verarbeiten. (Hinweis 1)
CA Service-Administrator Beta roles/privateca.admin Flottenprojekt Vollständiger Zugriff auf alle CA Service-Ressourcen. (Hinweis 2)

Beschränkungen

Wir empfehlen Ihnen, die Liste der Von Cloud Service Mesh unterstützte Features und Einschränkungen. Insbesondere ist Folgendes zu berücksichtigen:

  • Die IstioOperator API wird nicht unterstützt, da sie hauptsächlich den Zugriff auf Clusterkomponenten steuert.

  • Für die Verwendung von Certificate Authority Service (CA Service) muss Cloud Service Mesh pro Cluster konfiguriert werden. und wird bei Verwendung der Flotten-Standardkonfiguration nicht unterstützt in GKE Enterprise.

  • Für GKE Autopilot-Cluster ist die projektübergreifende Einrichtung nur ab GKE 1.23 unterstützt.

  • Für GKE Autopilot-Cluster, um eine Anpassung an den GKE Autopilot-Ressourcenlimit Standard-Proxy-Ressourcenanfragen und -limits sind auf 500 m CPU und 512 MB eingestellt. zu speichern. Sie können die Standardwerte mit benutzerdefinierte Injektion.

  • Bei der Bereitstellung einer verwalteten Steuerungsebene werden Istio-CRDs im angegebenen Cluster bereitgestellt. Wenn bereits Istio-CRDs im werden diese überschrieben,

  • Istio CNI und Cloud Service Mesh sind nicht mit GKE Sandbox kompatibel. Dementsprechend wird Das verwaltete Cloud Service Mesh mit der TRAFFIC_DIRECTOR-Implementierung unterstützen keine Cluster mit aktivierter GKE Sandbox.

Hinweise

  1. Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.
  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  5. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  6. Konfigurieren Sie gcloud (auch wenn Sie Cloud Shell verwenden).
    1. Authentifizieren Sie sich mit der Google Cloud CLI, wobei FLEET_PROJECT_ID ist die ID Ihres Flottenhostprojekts. Im Allgemeinen FLEET_PROJECT_ID wird standardmäßig erstellt und hat denselben Namen wie das Projekt.

             gcloud auth login --project FLEET_PROJECT_ID
      

    2. Aktualisieren Sie die Komponenten:

             gcloud components update
      

  7. Aktivieren Sie die erforderlichen APIs in Ihrem Fleet-Host-Projekt.

      gcloud services enable mesh.googleapis.com \
          --project=FLEET_PROJECT_ID
    

  8. Durch Aktivieren von mesh.googleapis.com werden die folgenden APIs aktiviert:

    API Zweck Kann deaktiviert werden?
    meshconfig.googleapis.com Cloud Service Mesh nutzt die Mesh Configuration API für die Weiterleitung Konfigurationsdaten aus Ihrem Mesh-Netzwerk in Google Cloud übertragen. Außerdem Wenn Sie die Mesh Configuration API aktivieren, können Sie auf die Cloud Service Mesh-Seiten in der Google Cloud Console und zur Verwendung der Cloud Service Mesh-Zertifizierungsstelle. Nein
    meshca.googleapis.com Bezieht sich auf die Cloud Service Mesh-Zertifizierungsstelle, die vom verwalteten Cloud Service Mesh verwendet wird. Nein
    container.googleapis.com Erforderlich zum Erstellen von Google Kubernetes Engine-Clustern (GKE). Nein
    gkehub.googleapis.com Erforderlich zum Verwalten des Mesh-Netzwerks als Flotte. Nein
    monitoring.googleapis.com Erforderlich zum Erfassen von Telemetrie für Mesh-Arbeitslasten. Nein
    stackdriver.googleapis.com Erforderlich für die Verwendung der Dienste-UI. Nein
    opsconfigmonitoring.googleapis.com Erforderlich, um die Services-UI für Cluster außerhalb von Google Cloud zu verwenden. Nein
    connectgateway.googleapis.com Erforderlich, damit die verwaltete Cloud Service Mesh-Steuerungsebene auf Mesh-Arbeitslasten zugreifen. Ja*
    trafficdirector.googleapis.com Ermöglicht eine hochverfügbare und skalierbare verwaltete Steuerungsebene. Ja*
    networkservices.googleapis.com Ermöglicht eine hochverfügbare und skalierbare verwaltete Steuerungsebene. Ja*
    networksecurity.googleapis.com Ermöglicht eine hochverfügbare und skalierbare verwaltete Steuerungsebene. Ja*
    <ph type="x-smartling-placeholder">

    Verwaltetes Cloud Service Mesh konfigurieren

    Die erforderlichen Schritte zum Bereitstellen des verwalteten Cloud Service Mesh mit der Flotten-API hängen davon ab, ob Sie diese Funktion Standard für neue Flottencluster oder Aktivieren Sie es pro Cluster.

    Für Ihre Flotte konfigurieren

    Wenn Sie aktiviert Google Kubernetes Engine (GKE) Enterprise können Sie Aktivieren Sie das verwaltete Cloud Service Mesh als Standardkonfiguration für Ihre Flotte. Dieses Dadurch wird jeder neue GKE-Cluster in Google Cloud registriert während des Clusters Erstellung das verwaltete Cloud Service Mesh im Cluster aktiviert ist. Weitere Informationen Standardkonfiguration für Flotten unter Flottenebene verwalten Funktionen.

    Verwaltetes Cloud Service Mesh als Standardkonfiguration für Ihre Flotte aktivieren und registrieren der Flotte während der Clustererstellung nur Mesh CA. Wenn Sie Certificate Authority Service, empfehlen wir, dass Sie es pro Cluster aktivieren.

    Führen Sie die folgenden Schritte aus, um Standardeinstellungen auf Flottenebene für das verwaltete Cloud Service Mesh zu aktivieren folgenden Schritten:

    Console

    1. Rufen Sie in der Google Cloud Console die Seite Feature Manager auf.

      Zu Feature Manager

    2. Klicken Sie im Bereich Service Mesh auf Konfigurieren.

    3. Überprüfen Sie die Einstellungen, die von allen neuen Clustern übernommen werden, die Sie in der Google Cloud Console erstellen und sich bei der Flotte registrieren.

    4. Klicken Sie auf Konfigurieren, um diese Einstellungen anzuwenden.

    5. Klicken Sie im Dialogfeld zur Bestätigung auf Bestätigen.

    6. Optional: Synchronisieren Sie vorhandene Cluster mit den Standardeinstellungen.

      1. Wählen Sie in der Liste Cluster in der Flotte die Cluster aus, die Sie synchronisieren möchten. Sie können nur Cluster auswählen, auf denen Cloud Service Mesh installiert ist.
      2. Klicken Sie auf Mit Flotteneinstellungen synchronisieren und im angezeigten Bestätigungsdialogfeld auf Bestätigen. Dies kann einige Minuten dauern.

    gcloud

    Wenn Sie Standardeinstellungen auf Flottenebene mit der Google Cloud CLI konfigurieren möchten, müssen Sie legen Sie folgende Einstellungen fest:

    • Einstellungen auf Flottenebene

      • Erstellen Sie eine mesh.yaml-Datei, die nur eine einzelne Zeile enthält. management: automatic:

        echo "management: automatic" > mesh.yaml
        
      • Aktivieren Sie Cloud Service Mesh für Ihre Flotte:

        gcloud container fleet mesh enable --project FLEET_PROJECT_ID \
            --fleet-default-member-config mesh.yaml
        

        Wenn der folgende Fehler angezeigt wird, gehen Sie so vor: Aktivieren Sie GKE Enterprise.

        ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The
        [anthos.googleapis.com] service is required for this operation and is not
        enabled for the project [PROJECT_NUMBER]. Please use the Google Developers
        Console to enable it.: failed precondition
        
    • Einstellungen auf Netzwerkebene

      • Wenn sich das Projekt Ihres Netzwerks von Ihrem Flotten-Hostprojekt unterscheidet (z. B. Sie eine freigegebene VPC verwenden, müssen Sie zulassen, Cloud Service Mesh-Dienstkonten im Flottenprojekt auf die Netzwerkprojekts an. Für das Netzwerkprojekt müssen Sie dies nur einmal tun.

        Gewähren Sie Dienstkonten im Flottenprojekt die Berechtigung, auf die Netzwerkprojekt:

        gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
            --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
            --role roles/anthosservicemesh.serviceAgent
        
    • Einstellungen auf Clusterebene

      • Wenn Sie bereit sind, Cluster zur Verwendung mit Cloud Service Mesh zu erstellen, erstellen Sie Registrieren Sie sie in einem einzigen Schritt über die Google Cloud CLI, um die Standardeinstellung Konfiguration. Beispiel:

        gcloud container clusters create-auto CLUSTER_NAME \
            --fleet-project FLEET_PROJECT_ID \
            --location=LOCATION
        

        Sie können die Projektnummer für Ihr Flottenprojekt abrufen, indem Sie den folgenden Befehl:

        gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
        

        Das Flag --location gibt die Compute-Zone oder -Region an (z. B. us-central1-a oder us-central1) für den Cluster.

      • Wenn sich das Projekt Ihres Clusters von Ihrem Flotten-Hostprojekt unterscheidet, müssen Sie Erlauben Sie Cloud Service Mesh-Dienstkonten im Flottenprojekt den Zugriff auf Clusterprojekt und aktivieren Sie die erforderlichen APIs im Clusterprojekt. Nur für Sie müssen Sie dies für jedes Clusterprojekt einmal tun.

        Gewähren Sie Dienstkonten im Flottenprojekt die Berechtigung, auf die Clusterprojekt:

        gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
            --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
            --role roles/anthosservicemesh.serviceAgent
        

        Aktivieren Sie die Mesh API im Projekt des Clusters:

        gcloud services enable mesh.googleapis.com \
          --project=CLUSTER_PROJECT_ID
        

        Ersetzen Sie CLUSTER_PROJECT_ID durch die eindeutige Kennzeichnung von Ihr Clusterprojekt. Wenn Sie den Cluster im selben Projekt erstellt haben wie bei Ihrer Flotte, dann ist CLUSTER_PROJECT_ID dasselbe wie FLEET_PROJECT_ID.

    Weiter zu Bereitstellung der Steuerungsebene prüfen

    Pro Cluster konfigurieren

    Führen Sie die folgenden Schritte aus, um das verwaltete Cloud Service Mesh für jeden Cluster in Ihres Mesh-Netzwerks.

    Flottenfeature von Cloud Service Mesh aktivieren

    Aktivieren Sie Cloud Service Mesh im Flottenprojekt. Wenn Sie sich registrieren, mehrere Cluster vorhanden sind, erfolgt die Aktivierung von Cloud Service Mesh auf Flottenebene, sodass Sie nur einmal ausführen müssen.

    gcloud container fleet mesh enable --project FLEET_PROJECT_ID
    

    Cluster bei einer Flotte registrieren

    1. GKE-Cluster registrieren mit Workload Identity für die Flotte. Das Flag --location gibt die Compute-Zone oder Region (z. B. us-central1-a oder us-central1) für den Cluster.

      gcloud container clusters update CLUSTER_NAME \
        --location CLUSTER_LOCATION \
        --fleet-project FLEET_PROJECT_ID
      
    2. Prüfen Sie, ob Ihr Cluster registriert ist:

      gcloud container fleet memberships list --project FLEET_PROJECT_ID
      

      Beispielausgabe:

      NAME                 EXTERNAL_ID                           LOCATION
      cluster-1            1d8e255d-2b55-4df9-8793-0435461a2cbc  us-central1
      

      Notieren Sie sich die MEMBERSHIP_NAME. Sie benötigen sie, wenn Sie die automatische Verwaltung zu aktivieren.

    3. Wenn sich das Netzwerk des Clusters von dem Projekt des Flottenhostprojekts unterscheidet (Sie verwenden beispielsweise eine freigegebene VPC), müssen Sie zulassen, Cloud Service Mesh-Dienstkonten im Flottenprojekt auf die Netzwerkprojekts an. Für das Netzwerkprojekt müssen Sie dies nur einmal tun.

      Gewähren Sie Dienstkonten im Flottenprojekt die Berechtigung, auf die Netzwerkprojekt:

       gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
            --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
            --role roles/anthosservicemesh.serviceAgent
      
    4. Wenn sich das Projekt Ihres Clusters von Ihrem Flotten-Hostprojekt unterscheidet, müssen Sie Cloud Service Mesh-Dienstkonten im Flottenprojekt für den Zugriff auf den Cluster Projekt erstellen und die erforderlichen APIs im Clusterprojekt aktivieren.

      Dies ist nur einmal für jedes Clusterprojekt erforderlich. Wenn Sie zuvor verwaltetes Cloud Service Mesh für diese Kombination aus Cluster und Flottenprojekte sind, wurden diese Änderungen bereits angewendet und Sie die folgenden Befehle ausführen.

      Gewähren Sie Dienstkonten im Fleet-Projekt die Berechtigung für den Zugriff auf das Clusterprojekt:

       gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
           --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
           --role roles/anthosservicemesh.serviceAgent
      

      Aktivieren Sie die Mesh API im Projekt des Clusters:

       gcloud services enable mesh.googleapis.com \
           --project=CLUSTER_PROJECT_ID
      

    Certificate Authority Service konfigurieren (optional)

    Wenn für Ihre Service-Mesh-Bereitstellung Certificate Authority Service (CA Service) erforderlich ist, und folgen Sie dann der Anleitung unter Certificate Authority Service für verwaltetes Cloud Service Mesh konfigurieren. um sie für Ihre Flotte zu aktivieren. Führe alle Schritte aus, bevor du fortfährst mit dem nächsten Abschnitt fortfahren.

    Automatische Verwaltung aktivieren

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

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

    Dabei gilt:

    • MEMBERSHIP_NAME ist der Name der Mitgliedschaft, der bei der Bestätigung aufgeführt wurde. ob Ihr Cluster bei der Flotte registriert wurde.
    • MEMBERSHIP_LOCATION ist der Standort deiner Mitgliedschaft (entweder ein Region oder global).

      Wenn Sie die Mitgliedschaft mit dem Befehl in dieser Anleitung vor Kurzem erstellt haben, sollte die Region Ihres Clusters sein. Wenn Sie einen zonalen Cluster haben, verwenden Sie den Region, die der Zone des Clusters entspricht. Wenn Sie z. B. eine zonale Cluster in us-central1-c und verwenden Sie dann den Wert us-central1.

      Dieser Wert kann global sein, wenn du dich vor Mai 2023 registriert hast oder wenn du hat bei der Registrierung der Mitgliedschaft den global-Standort angegeben. Sie können den Standort deiner Mitgliedschaft gcloud container fleet memberships list --project FLEET_PROJECT_ID

    Bereitstellung der Steuerungsebene prüfen

    Prüfen Sie nach einigen Minuten, ob der Status der Steuerungsebene ACTIVE lautet:

    gcloud container fleet mesh describe --project FLEET_PROJECT_ID
    

    Die Ausgabe sieht etwa so aus:

    ...
    membershipSpecs:
      projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
        mesh:
          management: MANAGEMENT_AUTOMATIC
    membershipStates:
      projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
        servicemesh:
          controlPlaneManagement:
            details:
            - code: REVISION_READY
              details: 'Ready: asm-managed'
            state: ACTIVE
            implementation: ISTIOD | TRAFFIC_DIRECTOR
          dataPlaneManagement:
            details:
            - code: OK
              details: Service is running.
            state: ACTIVE
        state:
          code: OK
          description: 'Revision(s) ready for use: asm-managed.'
    ...
    

    Notieren Sie sich die Steuerungsebene, die im Feld implementation angezeigt wird. Sie können entweder ISTIOD oder TRAFFIC_DIRECTOR. Weitere Informationen finden Sie unter Von Cloud Service Mesh unterstützte Features für Unterschiede der Steuerungsebene und unterstützte Konfigurationen Implementierung der Steuerungsebene ausgewählt.

    kubectl so konfigurieren, dass er auf den Cluster verweist

    In den folgenden Abschnitten werden kubectl-Befehle für jeden der folgenden Schritte ausgeführt: für Ihre Cluster. Bevor Sie mit den folgenden Abschnitten fortfahren, führen Sie den folgenden Befehl für jeden Ihrer Cluster, um kubectl so zu konfigurieren, dass sie auf des Clusters.

    gcloud container clusters get-credentials CLUSTER_NAME \
          --location CLUSTER_LOCATION \
          --project CLUSTER_PROJECT_ID
    

    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 Gateway für eingehenden Traffic oder ein Gateway für ausgehenden Traffic benötigt, finden Sie weitere Informationen unter Gateways bereitstellen. Um andere zu aktivieren optionale Funktionen, siehe Optionale Features in Cloud Service Mesh aktivieren

    Verwaltete Datenebene

    Wenn Sie ein verwaltetes Cloud Service Mesh verwenden, verwaltet Google die Upgrades Ihrer Proxys vollständig es sei denn, Sie deaktivieren sie.

    Bei der verwalteten Datenebene werden die Sidecar-Proxys und eingefügten Gateways automatisch in Verbindung mit der verwalteten Steuerungsebene aktualisiert, indem Arbeitslasten neu starten, um neue Versionen des Proxys wieder einzufügen. Dies ist in der Regel 1–2 Wochen nach dem Upgrade der verwalteten Steuerungsebene abgeschlossen.

    Wenn diese Option deaktiviert ist, richtet sich die Proxy-Verwaltung nach dem natürlichen Lebenszyklus der Pods in dem Cluster und muss vom Nutzer manuell ausgelöst werden, um das Update zu steuern zu zahlen.

    Auf der verwalteten Datenebene werden Proxys aktualisiert, indem ausgeführte Pods entfernt werden früheren Versionen des Proxys. Die Bereinigungen erfolgen schrittweise, Budget für Pod-Störungen und die Steuerung der Änderungsrate.

    Die verwaltete Datenebene verwaltet nicht Folgendes:

    • Nicht eingefügte Pods
    • Manuell eingefügte Pods
    • Jobs
    • StatefulSets
    • DaemonSets

    Verwaltete Datenebene deaktivieren (optional)

    Wenn Sie das verwaltete Cloud Service Mesh auf einem neuen Cluster bereitstellen, können Sie Sie deaktivieren die verwaltete Datenebene vollständig oder nur für einzelne Namespaces oder Pods. Die verwaltete Datenebene bleibt für vorhandene Cluster deaktiviert, in denen standardmäßig oder manuell deaktiviert wurde.

    So deaktivieren Sie die verwaltete Datenebene auf Clusterebene und kehren zurück zu Verwalten Sie die Sidecar-Proxys selbst, ändern Sie die Annotation:

    kubectl annotate --overwrite controlplanerevision -n istio-system \
      mesh.cloud.google.com/proxy='{"managed":"false"}'
    

    So deaktivieren Sie die verwaltete Datenebene für einen Namespace:

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

    So deaktivieren Sie die verwaltete Datenebene für einen Pod:

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

    Wartungsbenachrichtigungen aktivieren

    Sie können bis zu eine Woche vor der geplanten Wartung über die bevorstehende Wartung der verwalteten Datenebene informiert werden. Wartungsbenachrichtigungen werden nicht standardmäßig gesendet. Sie müssen außerdem ein GKE-Wartungsfenster konfigurieren, bevor Sie Benachrichtigungen erhalten können. Wenn diese Option aktiviert ist, werden Benachrichtigungen an folgende Adresse gesendet: mindestens zwei Tage vor dem Upgradevorgang.

    So aktivieren Sie Wartungsbenachrichtigungen für verwaltete Datenebenen:

    1. Öffnen Sie die Seite Kommunikation.

      Zur Seite "Kommunikation"

    2. Wählen Sie in der Zeile Cloud Service Mesh-Upgrade unter der Spalte E-Mail die Option Optionsfeld, um Wartungsbenachrichtigungen auf AN zu setzen.

    Jeder Nutzer, der Benachrichtigungen erhalten möchte, muss diese separat aktivieren. Bei Bedarf Um einen E-Mail-Filter für diese Benachrichtigungen festzulegen, lautet die Betreffzeile:

    Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME".

    Das folgende Beispiel zeigt eine typische Wartungsbenachrichtigung für die verwaltete Datenebene:

    Betreff: Anstehendes Upgrade für Ihren Cloud Service Mesh-Cluster „<location/cluster-name>

    Hallo,

    Für die Cloud Service Mesh-Komponenten in Ihrem Cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) ist ein Upgrade am ${scheduled_date_human_understand} um ${scheduled_time_human_composer} geplant.

    In den Versionshinweisen (https://cloud.google.com/service-mesh/docs/release-notes) finden Sie weitere Informationen zu diesem neuen Update.

    Wenn diese Wartung gekündigt wird, erhalten Sie eine weitere Benachrichtigung.

    Viele Grüße

    Das Cloud Service Mesh-Team

    (c) 2023 Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA Mit dieser Mitteilung informieren wir Sie über wichtige Änderungen in Bezug auf die Google Cloud Platform oder Ihr Konto. Sie können Benachrichtigungen zu Wartungsfenstern deaktivieren, indem Sie Ihre Einstellungen anpassen: https://console.cloud.google.com/user-preferences/communication?project=${project_id}

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

    Wenn Ihr Mesh-Netzwerk nur einen Cluster hat, überspringen Sie diese Multi-Cluster-Schritte und fahren Sie mit Anwendungen bereitstellen oder Anwendungen migrieren

    Bevor Sie fortfahren, prüfen Sie, ob das Cloud Service Mesh auf jedem Gerät konfiguriert ist Cluster.

    Durch das Aktivieren von Cloud Service Mesh mit der Flotten-API wird die Endpunkterkennung aktiviert für diesem Cluster. Sie müssen jedoch Firewallports öffnen. Informationen zum Deaktivieren der Endpunkterkennung für einen oder mehrere Cluster finden Sie in der Anleitung um sie zu deaktivieren, Endpunkterkennung zwischen Clustern mit deklarativer API

    Eine Beispielanwendung mit zwei Clustern finden Sie im HelloWorld-Dienstbeispiel.

    Anwendungen bereitstellen

    Wenn Sie mehr als einen Cluster in der Flotte haben, die ein verwaltetes Cloud Service Mesh verwenden, gilt Folgendes: Achten Sie darauf, dass die Endpunkterkennung oder Firewallports wie vorgesehen konfiguriert sind und Anwendungen bereitstellen.

    Aktivieren Sie den Namespace für die Injection: Die Schritte hängen von Ihrer Implementierung der Steuerungsebene ab.

    Verwaltet (TD)

    1. Wenden Sie das Standard-Injection-Label auf den Namespace an:
    kubectl label namespace NAMESPACE
        istio.io/rev- istio-injection=enabled --overwrite
    

    Verwaltet (Istiod)

    Empfohlen:Führen Sie den folgenden Befehl aus, um die Standardeinschleusung anzuwenden. Label zum Namespace hinzu:

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

    Wenn Sie bereits Nutzer mit der Managed Istiod-Steuerungsebene sind: Wir empfehlen die Standardeinschleusung, aber die überarbeitete Injektion ist unterstützt. Gehe dazu so vor:

    1. Führen Sie den folgenden Befehl aus, um die verfügbaren Release-Versionen zu finden:

      kubectl -n istio-system get controlplanerevision
      

      Die Ausgabe sieht in etwa so aus:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      HINWEIS: Wenn in der Liste oben zwei Versionen der Steuerungsebene angezeigt werden, entfernen Sie eine. Mehrere Kanäle der Steuerungsebene im Cluster werden nicht unterstützt.

      In der Ausgabe ist der Wert in der Spalte NAME das Überarbeitungslabel, das der verfügbaren Release-Version für die Cloud Service Mesh-Version entspricht.

    2. Wenden Sie das Überarbeitungslabel auf den Namespace an.

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

    Sie haben das verwaltete Cloud Service Mesh erfolgreich konfiguriert. Wenn Sie bereits vorhandene Arbeitslasten in beschrifteten Namespaces haben, starten Sie diese neu, eingefügten Proxys.

    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.

    Injektion anpassen (optional)

    Sie können Standardwerte überschreiben und Einschleusungseinstellungen anpassen, aber das kann zu unvorhergesehenen Konfigurationsfehlern und Problemen mit der Sidecar-Datei Container. Lesen Sie vor dem Anpassen der Injektion die Informationen nach der Stichprobe für Hinweise zu bestimmten Einstellungen und Empfehlungen.

    Mit der Konfiguration pro Pod lassen sich diese Optionen für einzelne Pods überschreiben. Dazu wird dem Pod ein istio-proxy-Container hinzugefügt. Sidecar-Datei wird jede hier definierte Konfiguration als Überschreibung des Standard-Injection-Vorlage.

    Mit der folgenden Konfiguration werden beispielsweise verschiedene Einstellungen angepasst, wie z. B. das Verringern der CPU-Anfragen, das Hinzufügen einer Volume-Bereitstellung und das Hinzufügen einer preStop-Hook:

    apiVersion: v1
    kind: Pod
    metadata:
      name: example
    spec:
      containers:
      - name: hello
        image: alpine
      - name: istio-proxy
        image: auto
        resources:
          requests:
            cpu: "200m"
            memory: "256Mi"
          limits:
            cpu: "200m"
            memory: "256Mi"
        volumeMounts:
        - mountPath: /etc/certs
          name: certs
        lifecycle:
          preStop:
            exec:
              command: ["sleep", "10"]
      volumes:
      - name: certs
        secret:
          secretName: istio-certs
    

    Im Allgemeinen kann jedes Feld in einem Pod festgelegt werden. Es muss jedoch darauf geachtet werden, bestimmte Felder:

    • Für Kubernetes muss das Feld image festgelegt werden, bevor die Injection ausgeführt wird. Sie können zwar das Standardbild durch ein bestimmtes Bild überschreiben, wir empfehlen jedoch, dass Sie den image auf auto setzen, wodurch der Sidecar-Injektor ausgelöst wird. automatisch das Bild auswählen.
    • Einige Felder in containers hängen von zugehörigen Einstellungen ab. Beispiel: muss kleiner oder gleich dem CPU-Limit sein. Wenn beide Felder nicht korrekt konfiguriert ist, kann der Pod möglicherweise nicht gestartet werden.
    • Mit Kubernetes können Sie sowohl requests als auch limits für Ressourcen in Ihrem Pod spec. GKE Autopilot berücksichtigt nur requests. Weitere Informationen Weitere Informationen finden Sie unter Ressourcenlimits in Autopilot festlegen.

    Darüber hinaus können bestimmte Felder im Pod durch Anmerkungen konfiguriert werden. Es wird jedoch empfohlen, die Einstellungen wie oben beschrieben anzupassen. Achten Sie besonders auf die folgenden Anmerkungen:

    • Wenn für GKE Standard sidecar.istio.io/proxyCPU festgelegt ist, stellen Sie müssen Sie explizit sidecar.istio.io/proxyCPULimit festlegen. Andernfalls wird die Sidecar-Datei Das CPU-Limit wird auf „unbegrenzt“ festgelegt.
    • Wenn für GKE Standard sidecar.istio.io/proxyMemory festgelegt ist, Sie müssen sidecar.istio.io/proxyMemoryLimit explizit festlegen. Andernfalls Das Arbeitsspeicherlimit der Sidecar-Datei wird auf "unbegrenzt" festgelegt.
    • Für GKE Autopilot werden die Ressourcen requests und limits konfiguriert mit Annotationen können Ressourcen überdimensioniert werden. Mit der Vorlage für Bilder zu vermeiden. Beispiele für Ressourcenänderungen in Autopilot

    Sehen Sie sich beispielsweise die folgende Ressourcenanmerkung an:

    spec:
      template:
        metadata:
          annotations:
            sidecar.istio.io/proxyCPU: "200m"
            sidecar.istio.io/proxyCPULimit: "200m"
            sidecar.istio.io/proxyMemory: "256Mi"
            sidecar.istio.io/proxyMemoryLimit: "256Mi"
    

    Anwendungen zum verwalteten Cloud Service Mesh migrieren

    So migrieren Sie Anwendungen vom Cloud Service Mesh im Cluster zum verwalteten Cloud Service Mesh: führen Sie die folgenden Schritte aus:

    1. Ersetzen Sie das aktuelle Namespace-Label. Die Schritte hängen von Ihrer Implementierung der Steuerungsebene ab.

    Verwaltet (TD)

    1. Wenden Sie das Standard-Injection-Label auf den Namespace an:
    kubectl label namespace NAMESPACE
        istio.io/rev- istio-injection=enabled --overwrite
    

    Verwaltet (Istiod)

    Empfohlen:Führen Sie den folgenden Befehl aus, um die Standardeinschleusung anzuwenden. Label zum Namespace hinzu:

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

    Wenn Sie bereits Nutzer mit der Managed Istiod-Steuerungsebene sind: Wir empfehlen die Standardeinschleusung, aber die überarbeitete Injektion ist unterstützt. Gehe dazu so vor:

    1. Führen Sie den folgenden Befehl aus, um die verfügbaren Release-Versionen zu finden:

      kubectl -n istio-system get controlplanerevision
      

      Die Ausgabe sieht in etwa so aus:

      NAME                AGE
      asm-managed-rapid   6d7h
      

      HINWEIS: Wenn in der Liste oben zwei Versionen der Steuerungsebene angezeigt werden, entfernen Sie eine. Mehrere Kanäle der Steuerungsebene im Cluster werden nicht unterstützt.

      In der Ausgabe ist der Wert in der Spalte NAME das Überarbeitungslabel, das der verfügbaren Release-Version für die Cloud Service Mesh-Version entspricht.

    2. Wenden Sie das Überarbeitungslabel auf den Namespace an.

      kubectl label namespace NAMESPACE \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      
    1. So führen Sie ein Rolling Upgrade von Bereitstellungen im Namespace durch:

      kubectl rollout restart deployment -n NAMESPACE
      
    2. Testen Sie Ihre Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.

    3. Wenn Sie Arbeitslasten in anderen Namespaces haben, wiederholen Sie die vorherigen Schritte für jeden Namespace.

    4. 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.

    Wenn Sie mit der Anwendung zufrieden sind, können Sie den clusterinternen istiod entfernen, nachdem Sie alle Namespaces für die verwaltete 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:

    1. 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
      
    2. 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 für ein Rollback noch einmal aus. den Cloud Service Mesh-Installationsbefehl, mit dem das Gateway, das zurückverweist, noch einmal bereitgestellt wird. mit Ihrer clusterinternen Steuerungsebene:

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

    Bei Erfolg können Sie diese Ausgabe erwarten:

    deployment.apps/istio-ingressgateway rolled back
    

    Cloud Service Mesh deinstallieren

    Die verwaltete Steuerungsebene wird automatisch auf null skaliert, wenn sie nicht von Namespaces verwendet wird. Für Eine ausführliche Anleitung finden Sie unter Cloud Service Mesh deinstallieren.