Verwaltete Cloud Service Mesh-Steuerungsebene in GKE bereitstellen

Dieser Leitfaden unterstützt nicht nur Google Cloud Service APIs und Cloud Service APIs:

Weitere Informationen finden Sie unter Cloud Service Mesh – Übersicht.

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

Auf dieser Seite wird gezeigt, wie Sie mit der Fleet API ein verwaltetes Cloud Service Mesh mit Istio APIs einrichten.

Vorbereitung

Sie sollten Folgendes bereits haben:

• Ein Cloud-Projekt
• Ein Cloud-Rechnungskonto
• Erforderliche Berechtigungen zum Bereitstellen von Cloud Service Mesh erhalten
• Workload Identity in Ihren Clustern und Knotenpools aktiviert.

Voraussetzungen

• Ein oder mehrere Cluster mit einer unterstützten Version von GKE in einer der unterstützten Regionen.

• Bei verwaltetem Cloud Service Mesh werden GKE-Release-Kanäle verwendet, um Stabilität und Upgradegeschwindigkeit auszubalancieren. Neue Änderungen an den Clusterkomponenten von Cloud Service Mesh (einschließlich CNI, MDPC, Proxys und Istio-CRDs) werden zuerst für Cluster eingeführt, die den GKE Rapid Channel abonniert haben. Sobald sie eine ausreichende Stabilität nachgewiesen haben, werden sie in den regulären GKE-Channel und schließlich in den GKE-Stable Channel hochgestuft.

  • Managed Cloud Service Mesh unterstützt nicht das sichere Ändern von GKE-Release-Kanälen.
  • Wenn Sie den GKE-Release-Kanal ändern, führt Cloud Service Mesh automatisch ein Upgrade oder Downgrade der Clusterkomponenten (CNI, MDPC, standardmäßig eingeblendete Proxyversion und Istio-CRDs) durch, damit sie dem aktuellen GKE-Release-Kanal entsprechen.

• Achten Sie darauf, dass Ihr Cluster über ausreichende Kapazität für die erforderlichen Komponenten verfügt, die das verwaltete Cloud Service Mesh im Cluster installiert.

  • Für die Bereitstellung mdp-controller im Namespace kube-system werden CPU: 50 m und Arbeitsspeicher: 128 Mi benötigt.
  • Der istio-cni-node-Daemonset im Namespace kube-system fordert auf jedem Knoten cpu: 100m und memory: 100Mi an.

• Die Organisationsrichtlinie constraints/compute.disableInternetNetworkEndpointGroup muss deaktiviert sein. Wenn die Richtlinie aktiviert ist, funktioniert ServiceEntry möglicherweise nicht.

• Prüfen Sie, ob der Clientcomputer, auf dem Sie Managed Cloud Service Mesh bereitstellen, eine Netzwerkverbindung zum API-Server hat.

• 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 1.21.3 und höher unterstützt.

• Cloud Service Mesh kann mehrere GKE-Cluster in einem Projekt mit einem einzelnen Projekt oder in einer Umgebung mit einem einzelnen Netzwerk mit mehreren Projekten verwenden.

  • 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 Umgebung mit mehreren Clustern und einem einzigen Projekt kann das Flottenprojekt mit dem Clusterprojekt identisch sein. Weitere Informationen zu Flotten finden Sie unter Flotten – Übersicht.
  • Bei einer Umgebung mit mehreren Projekten empfehlen wir, die Flotte in einem separaten Projekt von den Clusterprojekten zu hosten. Wenn Ihre organisatorischen Richtlinien und die vorhandene Konfiguration dies zulassen, empfehlen wir, das freigegebene VPC-Projekt als Flotten-Hostprojekt zu verwenden. Weitere Informationen finden Sie unter Cluster mit freigegebener VPC einrichten.

Rollen, die zum Installieren von Cloud Service Mesh erforderlich sind

In der folgenden Tabelle werden die Rollen beschrieben, die zum Installieren von verwaltetem Cloud Service Mesh erforderlich sind.

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

Achtung: Beachten Sie die folgenden spezifischen Einschränkungen für den Gerätepool: – Alle Cluster in einem bestimmten Cloud Service Mesh müssen bei derselben Flotte registriert sein. Die Cluster können nicht für verschiedene Flotten registriert werden. – Alle Cluster in einem Projekt, das einen Cloud Service Mesh-Cluster enthält, müssen bei derselben Flotte registriert sein.

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

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

  Hinweis: Sie können weiterhin optionale Features aktivieren, ohne die IstioOperator API zu verwenden. Weitere Informationen finden Sie unter Optionale Features in verwaltetem Cloud Service Mesh aktivieren. Mit dem in asmcli enthaltenen Migrationstool können Sie außerdem andere optionale IstioOperator-Features automatisch konvertieren, damit sie mit der verwalteten Steuerungsebene kompatibel sind. Weitere Informationen finden Sie unter Von IstioOperator migrieren.

• Wenn Sie den CA-Dienst verwenden möchten, müssen Sie Cloud Service Mesh pro Cluster konfigurieren. Die Verwendung der Standardkonfiguration der Flotte in GKE Enterprise wird nicht unterstützt.

• Bei GKE Autopilot-Clustern wird die projektübergreifende Einrichtung nur mit GKE 1.23 oder höher unterstützt.

• Bei GKE Autopilot-Clustern werden die Standardanfragen und -limits für Proxy-Ressourcen auf 500 mCPU und 512 MB Arbeitsspeicher festgelegt, um sich an das Ressourcenlimit von GKE Autopilot anzupassen. Sie können die Standardwerte mithilfe der benutzerdefinierten Injection überschreiben.

• Während des Bereitstellungsprozesses für eine verwaltete Steuerungsebene werden Istio-CRDs im angegebenen Cluster bereitgestellt. Wenn im Cluster Istio-CRDs vorhanden sind, werden sie überschrieben.

• Istio CNI und Cloud Service Mesh sind nicht mit GKE Sandbox kompatibel. Daher werden Cluster mit aktivierter GKE Sandbox von verwaltetem Cloud Service Mesh mit der TRAFFIC_DIRECTOR-Implementierung nicht unterstützt.

Hinweise

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

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

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

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

   Go to project selector

5. Make sure that billing is enabled for your Google Cloud project.

6. Konfigurieren Sie gcloud, auch wenn Sie Cloud Shell verwenden.
1. Authentifizieren Sie sich mit der Google Cloud CLI. Dabei ist FLEET_PROJECT_ID die ID Ihres Flotten-Hostprojekts. In der Regel wird die FLEET_PROJECT_ID 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
   

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

Hinweis: Einige erforderliche APIs haben transitive Abhängigkeiten von anderen APIs.

API	Zweck	Kann deaktiviert werden?
meshconfig.googleapis.com	Cloud Service Mesh verwendet die Mesh Configuration API, um Konfigurationsdaten von Ihrem Mesh an Google Cloud weiterzuleiten. Darüber hinaus können Sie durch Aktivieren der Mesh Configuration API auf die Cloud Service Mesh-Seiten in der Google Cloud Console zugreifen und die Cloud Service Mesh-Zertifizierungsstelle verwenden.	Nein
meshca.googleapis.com	Bezieht sich auf die Cloud Service Mesh-Zertifizierungsstelle, die von verwaltetem 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 kann.	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*

Warnung: Deaktivieren von connectgateway.googleapis.com, trafficdirector.googleapis.com, networkservices.googleapis.com und/oder networksecurity.googleapis.com führt dazu, dass die verwaltete Cloud Service Mesh-Steuerungsebene nicht mehr funktioniert. Wenn die Flotte kein verwaltetes Cloud Service Mesh in einem Cluster verwendet, können diese APIs deaktiviert werden.

Verwaltetes Cloud Service Mesh konfigurieren

Die Schritte zum Bereitstellen von verwaltetem Cloud Service Mesh mit der Fleet API hängen davon ab, ob Sie es standardmäßig für neue Flottencluster oder pro Cluster aktivieren möchten.

Für Ihre Flotte konfigurieren

Wenn Sie die Google Kubernetes Engine (GKE) Enterprise-Version aktiviert haben, können Sie verwaltetes Cloud Service Mesh als Standardkonfiguration für Ihre Flotte aktivieren. Dies bedeutet, dass für jeden neuen GKE-Cluster in Google Cloud, der während der Clustererstellung registriert wird, verwaltetes Cloud Service Mesh im Cluster aktiviert ist. Weitere Informationen zur Standardkonfiguration für Flotten finden Sie unter Features auf Flottenebene verwalten.

Wenn Sie das verwaltete Cloud Service Mesh als Standardkonfiguration für Ihre Flotte aktivieren und Cluster bei der Clustererstellung bei der Flotte registrieren, wird nur Mesh-CA unterstützt. Wenn Sie Certificate Authority Service verwenden möchten, empfehlen wir, ihn pro Cluster zu aktivieren.

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

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. Prüfen Sie die Einstellungen, die von allen neuen Clustern übernommen werden, die Sie in der Google Cloud Console erstellen und bei der Flotte registrieren.

   Hinweis: Diese GKE-Einstellungen sind Voraussetzungen für die Verwendung von Cloud Service Mesh.

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 die folgenden Einstellungen festlegen:

• Einstellungen auf Flottenebene

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

    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 folgender Fehler angezeigt wird, müssen Sie GKE Enterprise aktivieren.

    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 Fleet-Hostprojekt unterscheidet (z. B. wenn Sie eine freigegebene VPC verwenden), müssen Sie Cloud Service Mesh-Dienstkonten im Fleetprojekt Zugriff auf das Netzwerkprojekt gewähren. Sie müssen dies nur einmal für das Netzwerkprojekt tun.

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

    gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
        --member "serviceAccount:[e-mail]" \
        --role roles/anthosservicemesh.serviceAgent
    

• Einstellungen auf Clusterebene

  • Wenn Sie bereit sind, Cluster für die Verwendung mit Cloud Service Mesh zu erstellen, können Sie sie mit der Google Cloud CLI in einem einzigen Schritt erstellen und registrieren, um die Standardkonfiguration zu verwenden. Beispiel:

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

    Sie können die Projektnummer für Ihr Flottenprojekt mit dem folgenden Befehl abrufen:

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

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

  • Wenn sich das Projekt Ihres Clusters von Ihrem Fleet-Hostprojekt unterscheidet, müssen Sie Cloud Service Mesh-Dienstkonten im Fleetprojekt Zugriff auf das Clusterprojekt gewähren und die erforderlichen APIs im Clusterprojekt aktivieren. Dies ist nur einmal für jedes Clusterprojekt erforderlich.

    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:[e-mail]" \
        --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 Kennung Ihres Clusterprojekts. Wenn Sie Ihren Cluster im selben Projekt wie Ihre Flotte erstellt haben, ist CLUSTER_PROJECT_ID mit FLEET_PROJECT_ID identisch.

Fahren Sie mit Prüfen, ob die Steuerungsebene bereitgestellt wurde fort.

Pro Cluster konfigurieren

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

Cloud Service Mesh-Flottenfeature aktivieren

Aktivieren Sie Cloud Service Mesh im Flottenprojekt. Wenn Sie mehrere Cluster registrieren möchten, wird Cloud Service Mesh auf Flottenebene aktiviert, sodass Sie diesen Befehl nur einmal ausführen müssen.

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Cluster bei einer Flotte registrieren

1. Registrieren Sie einen GKE-Cluster mithilfe der Workload Identity für Geräte. Das Flag --location ist 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, da Sie sie benötigen, wenn Sie die automatische Verwaltung aktivieren.

3. Wenn sich das Projekt des Netzwerks Ihres Clusters von Ihrem Fleet-Hostprojekt unterscheidet (z. B. wenn Sie eine freigegebene VPC verwenden), müssen Sie Cloud Service Mesh-Dienstkonten im Fleetprojekt Zugriff auf das Netzwerkprojekt gewähren. Sie müssen dies nur einmal für das Netzwerkprojekt tun.

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

    gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
         --member "serviceAccount:[e-mail]" \
         --role roles/anthosservicemesh.serviceAgent
   

4. Wenn sich das Projekt Ihres Clusters von Ihrem Fleet-Hostprojekt unterscheidet, müssen Sie Cloud Service Mesh-Dienstkonten im Fleetprojekt Zugriff auf das Clusterprojekt gewähren 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 von Cluster- und Flottenprojekten konfiguriert haben, wurden diese Änderungen bereits angewendet und Sie müssen die folgenden Befehle nicht 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:[e-mail]" \
        --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 ein Certificate Authority Service (CA-Dienst) erforderlich ist, folgen Sie der Anleitung unter Certificate Authority Service für verwaltetes Cloud Service Mesh konfigurieren, um ihn für Ihre Flotte zu aktivieren. Führen Sie alle Schritte aus, bevor Sie mit dem nächsten Abschnitt fortfahren.

Automatische Verwaltung aktivieren

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

Hinweis: Sie können diese Änderung auf mehrere Cluster gleichzeitig anwenden. Dazu übergeben Sie eine durch Kommas getrennte Liste von Mitgliedschaftsnamen als --memberships-Parameter.

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

Dabei gilt:

• MEMBERSHIP_NAME ist der Mitgliedschaftsname, der bei der Registrierung des Clusters bei der Flotte aufgeführt wurde.

• MEMBERSHIP_LOCATION ist der Standort deiner Mitgliedschaft (entweder eine Region oder global).

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

  Dieser Wert kann global sein, wenn Sie sich vor Mai 2023 registriert haben oder den Standort global bei der Registrierung der Mitgliedschaft angegeben haben. Du kannst den Standort deiner Mitgliedschaft mit gcloud container fleet memberships list --project FLEET_PROJECT_ID prüfen.

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 im Feld implementation angezeigte Steuerungsebene, entweder ISTIOD oder TRAFFIC_DIRECTOR. Informationen zu Unterschieden bei der Steuerungsebene, zu unterstützten Konfigurationen und zur Auswahl der Steuerungsebenenimplementierung finden Sie unter Unterstützte Cloud Service Mesh-Features.

Konfigurieren Sie kubectl so, dass es auf den Cluster verweist.

In den folgenden Abschnitten werden kubectl-Befehle für jeden Ihrer Cluster ausgeführt. Bevor Sie mit den folgenden Abschnitten fortfahren, führen Sie für jeden Ihrer Cluster den folgenden Befehl aus, um kubectl so zu konfigurieren, dass es auf den Cluster verweist.

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 verwalten. Wenn Sie ein Istio-Ingress- oder -Ausgangsgateway verwenden möchten, lesen Sie den Hilfeartikel Gateways bereitstellen. Wenn Sie die Kubernetes Gateway API verwenden möchten, lesen Sie den Hilfeartikel Gateway für Mesh vorbereiten. Informationen zum Aktivieren anderer optionaler Features finden Sie unter Optionale Features in Cloud Service Mesh aktivieren.

Verwaltete Datenebene

Wenn Sie verwaltetes Cloud Service Mesh verwenden, verwaltet Google die Upgrades Ihrer Proxys vollständig.

Wenn die Funktion „Verwaltete Datenebene“ aktiviert ist, werden die Sidecar-Proxys und die eingefügten Gateways aktiv und automatisch in Verbindung mit der verwalteten Steuerungsebene aktualisiert. Dazu werden Arbeitslasten neu gestartet, um neue Versionen des Proxys neu einzufügen. Dieser Vorgang beginnt nach dem Upgrade der Steuerungsebene und ist normalerweise innerhalb von zwei Wochen abgeschlossen.

Die verwaltete Datenebene verwendet den GKE-Release-Kanal. Wenn Sie den GKE-Release-Kanal ändern, während die verwaltete Datenebene aktiviert ist, aktualisiert das verwaltete Cloud Service Mesh die Proxys aller vorhandenen Arbeitslasten wie bei einem Roll-out der verwalteten Datenebene.

Wenn diese Option deaktiviert ist, erfolgt die Proxyverwaltung passiv – sie wird durch den natürlichen Lebenszyklus der Pods im Cluster gesteuert und muss vom Nutzer manuell ausgelöst werden, um die Aktualisierungsrate zu steuern.

Die verwaltete Datenebene aktualisiert Proxys durch Entfernen von Pods, auf denen ältere Versionen des Proxys ausgeführt werden. Die Bereinigungen werden schrittweise vorgenommen. Dabei wird das Budget für Pod-Störungen berücksichtigt und die Änderungsrate kontrolliert.

Hinweis: Wenn für den Cluster ein GKE-Wartungsfenster definiert ist, beginnen die Pods-Bereinigungen zu Beginn des nächsten verfügbaren Wartungsfensters und werden ohne Pause fortgesetzt, bis alle verwalteten Pods aktualisiert wurden (normalerweise 12 Stunden). Für CVE-bezogene Roll-outs wird kein Wartungsfenster eingehalten.

Die verwaltete Datenebene verwaltet nicht Folgendes:

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

Verwaltete Datenebene deaktivieren (optional)

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

Wenn Sie die verwaltete Datenebene auf Clusterebene deaktivieren und wieder die Sidecar-Proxys selbst verwalten möchten, ändern Sie die Anmerkung:

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 mindestens zwei Tage vor dem Upgrade gesendet.

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 in der Spalte E-Mail das Optionsfeld aus, um Wartungsbenachrichtigungen zu aktivieren (AN).

Jeder Nutzer, der Benachrichtigungen erhalten möchte, muss separat aktiviert werden. Wenn Sie einen E-Mail-Filter für diese Benachrichtigungen festlegen möchten, lautet der Betreff:

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: Bevorstehendes Upgrade für Ihren Cloud Service Mesh-Cluster „<location/cluster-name>“

Lieber Cloud Service Mesh-Nutzer,

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}) wird ein Upgrade auf ${scheduled_date_human_ lesbar} bei ${scheduled_time_human_ lesbar} 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 Servicemitteilung 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 Schritte für mehrere Cluster und fahren Sie mit Anwendungen bereitstellen oder Anwendungen migrieren fort.

Bevor Sie fortfahren, prüfen Sie, ob Cloud Service Mesh in jedem Cluster konfiguriert ist.

Hinweis: Weitere Informationen zur Endpunkterkennung finden Sie unter Endpunkterkennung mit mehreren Steuerungsebenen.

Wenn Sie Cloud Service Mesh mit der Flotten-API aktivieren, wird die Endpunkterkennung für diesen Cluster aktiviert. Sie müssen jedoch Firewallports öffnen. Informationen zum Deaktivieren der Endpunkterkennung für einen oder mehrere Cluster finden Sie in der Anleitung zum Deaktivieren der Endpunkterkennung zwischen Clustern mit deklarativer API.

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

Hinweis: Im Beispiel HelloWorld wird Docker Hub verwendet. In einem privaten Cluster kann die Containerlaufzeit Container-Images standardmäßig aus Artifact Registry abrufen. Die Containerlaufzeit kann keine Images aus einer anderen Container-Image-Registry im Internet abrufen. Sie können das Image herunterladen und in Artifact Registry hochladen oder Cloud NAT verwenden, um ausgehenden Internetzugriff für bestimmte private Knoten bereitzustellen. Weitere Informationen finden Sie unter Externe Container migrieren und Private Cluster erstellen.

Anwendungen bereitstellen

Wenn Sie in der Flotte mehr als einen Cluster mit verwaltetem Cloud Service Mesh haben, prüfen Sie, ob die Endpunkterkennung oder die Firewallports wie vorgesehen konfiguriert sind, bevor Sie fortfahren 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-Injektionslabel 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 das Standard-Injektionslabel auf den Namespace anzuwenden:

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

Bereits bestehende Nutzer der verwalteten Istio-Steuerungsebene:Wir empfehlen die Standard-Injection, aber auch die revisionsbasierte Injection wird unterstützt. Gehen Sie dazu so vor:

1. Führen Sie den folgenden Befehl aus, um die verfügbaren Release-Kanäle 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 Überarbeitungen der Steuerungsebene angezeigt werden, entfernen Sie eine. Mehrere Steuerungsebenenkanäle im Cluster werden nicht unterstützt.

   In der Ausgabe ist der Wert in der NAME-Spalte das Überarbeitungslabel, das dem verfügbaren Release-Kanal 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
   

Prüfen Sie mit dem folgenden Befehl, ob das Namespacelabel richtig angewendet wurde.

  kubectl get namespace -L istio-injection

Beispielausgabe:

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

Sie haben das verwaltete Cloud Service Mesh konfiguriert. Wenn Sie bereits Arbeitslasten in beschrifteten Namespaces haben, starten Sie diese neu, damit sie Proxys einfügen.

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.

Einfügen anpassen (optional)

Sie können Standardwerte überschreiben und die Injection-Einstellungen anpassen. Dies kann jedoch zu unvorhergesehenen Konfigurationsfehlern und damit verbundenen Problemen mit Sidecar-Containern führen. Bevor Sie die Injection anpassen, lesen Sie die Informationen nach dem Beispiel. Dort finden Sie Hinweise zu bestimmten Einstellungen und Empfehlungen.

Mit einer Pod-spezifischen Konfiguration können Sie diese Optionen für einzelne Pods überschreiben. Dazu fügen Sie Ihrem Pod einen istio-proxy-Container hinzu. Bei der Sidecar-Injection wird jede hier definierte Konfiguration als Überschreibung der Standard-Injection-Vorlage behandelt.

In der folgenden Konfiguration werden beispielsweise verschiedene Einstellungen angepasst, darunter die CPU-Anfragen gesenkt, ein Volume-Mount hinzugefügt und ein preStop-Hook hinzugefügt:

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. Bei bestimmten Feldern ist jedoch Vorsicht geboten:

• In Kubernetes muss das Feld image vor der Ausführung der Injection festgelegt werden. Sie können ein bestimmtes Image festlegen, um das Standardimage zu überschreiben. Wir empfehlen jedoch, image auf auto festzulegen. Dadurch wird das zu verwendende Image automatisch vom Sidecar-Injector ausgewählt.
• Einige Felder in containers sind von zugehörigen Einstellungen abhängig. Sie muss beispielsweise kleiner oder gleich dem CPU-Limit sein. Wenn beide Felder nicht richtig konfiguriert sind, 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 festlegen. GKE Autopilot berücksichtigt nur requests. Weitere Informationen finden Sie unter Ressourcenlimits in Autopilot festlegen.

Bestimmte Felder können außerdem über Anmerkungen im Pod konfiguriert werden. Wir empfehlen jedoch, die Einstellungen wie oben beschrieben anzupassen. Achten Sie bei den folgenden Anmerkungen besonders darauf:

• Wenn für GKE Standard sidecar.istio.io/proxyCPU festgelegt ist, müssen Sie sidecar.istio.io/proxyCPULimit explizit festlegen. Andernfalls wird das CPU-Limit des Sidecars auf „Unbegrenzt“ gesetzt.
• Wenn für GKE Standard sidecar.istio.io/proxyMemory festgelegt ist, müssen Sie sidecar.istio.io/proxyMemoryLimit explizit festlegen. Andernfalls wird das Speicherlimit des Sidecars auf „unbegrenzt“ festgelegt.
• Wenn Sie die Ressourcen requests und limits für GKE Autopilot mit Anmerkungen konfigurieren, werden die Ressourcen möglicherweise zu großzügig bereitgestellt. Verwenden Sie die Bildvorlage, um dies zu vermeiden. Weitere Informationen finden Sie unter Beispiele für Ressourcenänderungen in Autopilot.

Sehen Sie sich beispielsweise die folgende Anmerkung zu Ressourcen 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 zu verwaltetem Cloud Service Mesh migrieren

Warnung: Während des Migrationsprozesses werden Istio-CRDs im angegebenen Cluster installiert. Wenn im Cluster bereits Istio-CRDs vorhanden sind, werden diese überschrieben.

Führen Sie die folgenden Schritte aus, um Anwendungen von Cloud Service Mesh im Cluster zu einem verwalteten Cloud Service Mesh zu migrieren:

Hinweis: Achten Sie darauf, dass Sie ein verwaltetes Cloud Service Mesh bereitgestellt haben. Folgen Sie dazu den vorherigen Abschnitten dieses Leitfadens.
1. Ersetzen Sie das aktuelle Namespace-Label. Die Schritte hängen von Ihrer Implementierung der Steuerungsebene ab.

Verwaltet (TD)

1. Wenden Sie das Standard-Injektionslabel 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 das Standard-Injektionslabel auf den Namespace anzuwenden:

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

Bereits bestehende Nutzer der verwalteten Istio-Steuerungsebene:Wir empfehlen die Standard-Injection, aber auch die revisionsbasierte Injection wird unterstützt. Gehen Sie dazu so vor:

1. Führen Sie den folgenden Befehl aus, um die verfügbaren Release-Kanäle 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 Überarbeitungen der Steuerungsebene angezeigt werden, entfernen Sie eine. Mehrere Steuerungsebenenkanäle im Cluster werden nicht unterstützt.

   In der Ausgabe ist der Wert in der NAME-Spalte das Überarbeitungslabel, das dem verfügbaren Release-Kanal 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 den Cloud 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

Cloud Service Mesh deinstallieren

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