Diese Seite wurde von der Cloud Translation API übersetzt.

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 wird beschrieben, wie Sie mit der Flotten-API das verwaltete 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 aktiviert.

Voraussetzungen

Ein oder mehrere Cluster mit einer unterstützten Version von GKE in einer der unterstützten Regionen.
Achten Sie darauf, dass der Cluster genügend Kapazität für die erforderlichen Komponenten hat, die vom verwalteten Cloud Service Mesh im Cluster installiert werden.
- Die Bereitstellung mdp-controller im Namespace kube-system fordert die CPU an: 50 m, den Arbeitsspeicher: 128 Mi.
- Das DaemonSet istio-cni-node im Namespace kube-system fordert auf jedem Knoten die CPU an: 100 m, den Arbeitsspeicher: 100 Mi.
Sorgen Sie dafür, dass der Clientcomputer, von dem Sie das verwaltete 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 ab der GKE-Version 1.21.3 unterstützt.
Cloud Service Mesh kann mehrere GKE-Cluster in einer Umgebung mit einem einzelnen Projekt oder 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 Multi-Cluster-Umgebung mit einem einzelnen Projekt kann das Flottenprojekt mit dem Clusterprojekt identisch sein. Weitere Informationen zu Flotten finden Sie unter Flottenübersicht.
- Für eine Umgebung mit mehreren Projekten empfehlen wir, die Flotte in einem anderen Projekt als den Clusterprojekten zu hosten. Wenn Ihre Organisationsrichtlinien 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.

Zum Installieren von Cloud Service Mesh erforderliche Rollen

In der folgenden Tabelle werden die Rollen beschrieben, die zum Installieren des verwalteten 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

Wir empfehlen, die Liste der von Cloud Service Mesh unterstützten Features und Einschränkungen zu lesen. 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 optionale Features auch ohne die IstioOperator API aktivieren. Weitere Informationen finden Sie unter Optionale Features im verwalteten Cloud Service Mesh aktivieren. Sie können auch das in asmcli enthaltene Migrationstool verwenden, um andere optionale IstioOperator-Features automatisch so zu konvertieren, dass sie mit der verwalteten Steuerungsebene kompatibel sind. Weitere Informationen finden Sie unter Von IstioOperator migrieren.
Für die Verwendung von Certificate Authority Service (CA Service) muss Cloud Service Mesh pro Cluster konfiguriert werden. Sie wird bei Verwendung der Flotten-Standardkonfiguration in GKE Enterprise nicht unterstützt.
Bei GKE Autopilot-Clustern wird die projektübergreifende Einrichtung nur mit GKE 1.23 oder höher unterstützt.
Zur Anpassung an das GKE Autopilot-Ressourcenlimit werden für GKE Autopilot-Cluster die standardmäßigen Proxy-Ressourcenanfragen und -limits auf 500 m CPU und 512 MB Arbeitsspeicher festgelegt. Sie können die Standardwerte mit einer benutzerdefinierten Injektion überschreiben.
Während des Bereitstellungsprozesses für eine verwaltete Steuerungsebene werden Istio-CRDs im angegebenen Cluster bereitgestellt. Wenn im Cluster vorhandene Istio-CRDs vorhanden sind, werden diese überschrieben
Looker CNI und Cloud Service Mesh sind nicht mit GKE Sandbox kompatibel. Daher unterstützt das verwaltete Cloud Service Mesh mit der TRAFFIC_DIRECTOR-Implementierung keine Cluster mit aktivierter GKE Sandbox.

Hinweise

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.

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

Go to project selector

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

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

Go to project selector

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

Konfigurieren Sie gcloud (auch wenn Sie Cloud Shell verwenden).

Authentifizieren Sie sich mit der Google Cloud CLI, wobei FLEET_PROJECT_ID die ID Ihres Fleet Host-Projekts ist. Im Allgemeinen wird das FLEET_PROJECT_ID standardmäßig erstellt und hat denselben Namen wie das Projekt.
```
       gcloud auth login --project FLEET_PROJECT_ID
```
Aktualisieren Sie die Komponenten:
```
       gcloud components update
```

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:

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. Außerdem können Sie durch Aktivieren der Mesh Configuration API in der Google Cloud Console auf die Cloud Service Mesh-Seiten zugreifen und die Cloud Service Mesh-Zertifizierungsstelle verwenden.	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 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: Das 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 auf einem Cluster verwendet, können diese APIs deaktiviert werden.

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 die Aktivierung standardmäßig für neue Flottencluster oder pro Cluster bevorzugen.

Für Ihre Flotte konfigurieren

Wenn Sie die Google Kubernetes Engine (GKE) Enterprise-Version aktiviert haben, können Sie das verwaltete 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 der Flotte finden Sie unter Features auf Flottenebene verwalten.

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

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

Console

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

Zu Feature Manager
Klicken Sie im Bereich Service Mesh auf Konfigurieren.
Prüfen Sie die Einstellungen, die von allen neuen Clustern übernommen werden, die Sie in der Google Cloud Console erstellen, und registrieren Sie sich bei der Flotte.

Hinweis: Diese Einstellungen sind GKE-Einstellungen, die für die Verwendung von Cloud Service Mesh erforderlich sind.
Klicken Sie auf Konfigurieren, um diese Einstellungen anzuwenden.
Klicken Sie im Dialogfeld zur Bestätigung auf Bestätigen.
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 dann im angezeigten Bestätigungsdialogfeld auf Bestätigen. Dies kann einige Minuten dauern.

gcloud

Wenn Sie mit der Google Cloud CLI Standardeinstellungen auf Flottenebene konfigurieren möchten, müssen Sie die folgenden Einstellungen festlegen:

Einstellungen auf Flottenebene

Erstellen Sie eine mesh.yaml-Datei, die nur die einzelne 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 der folgende 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 dem Ihres Flotten-Hostprojekts unterscheidet (z. B. wenn Sie eine freigegebene VPC verwenden), müssen Sie den Cloud Service Mesh-Dienstkonten im Flottenprojekt Zugriff auf das Netzwerkprojekt gewähren. Sie müssen dies nur einmal für das Netzwerkprojekt tun.
  
  Gewähren Sie Dienstkonten im Flottenprojekt die Berechtigung für den Zugriff auf das 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 Cluster zur Verwendung mit Cloud Service Mesh erstellen möchten, erstellen und registrieren Sie diese in einem einzigen Schritt über die Google Cloud CLI, um die Standardkonfiguration zu verwenden. Beispiel:
```
gcloud container clusters create-auto CLUSTER_NAME \
    --fleet-project FLEET_PROJECT_ID \
    --location=LOCATION
```
  Mit dem folgenden Befehl können Sie die Projektnummer für Ihr Flottenprojekt abrufen:
```
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
```
  Das Flag --location gibt die Compute-Zone oder -Region (z. B. us-central1-a oder us-central1) für den Cluster an.
- Wenn sich das Projekt Ihres Clusters von dem Ihres Flotten-Hostprojekts unterscheidet, müssen Sie Cloud Service Mesh-Dienstkonten im Flottenprojekt den Zugriff auf das Clusterprojekt erlauben und die erforderlichen APIs im Clusterprojekt aktivieren. Sie müssen dies nur einmal pro Clusterprojekt tun.
  
  Gewähren Sie Dienstkonten im Flottenprojekt 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
```
  Ersetzen Sie CLUSTER_PROJECT_ID durch die eindeutige ID Ihres Clusterprojekts. Wenn Sie den 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 das verwaltete Cloud Service Mesh für jeden Cluster in Ihrem Mesh einzeln zu konfigurieren.

Flottenfeature von Cloud Service Mesh aktivieren

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

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Cluster bei einer Flotte registrieren

Registrieren Sie einen GKE-Cluster mit der 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 an.
```
gcloud container clusters update CLUSTER_NAME \
  --location CLUSTER_LOCATION \
  --fleet-project FLEET_PROJECT_ID
```

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 zum Aktivieren der automatischen Verwaltung.

Wenn sich das Projekt Ihres Clusters vom Netzwerk des Flottenprojekts unterscheidet (Sie verwenden beispielsweise eine freigegebene VPC), müssen Sie den Cloud Service Mesh-Dienstkonten im Flottenprojekt Zugriff auf das Netzwerkprojekt gewähren. Sie müssen dies nur einmal für das Netzwerkprojekt tun.

Gewähren Sie Dienstkonten im Flottenprojekt die Berechtigung für den Zugriff auf das 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
```
Wenn sich das Projekt Ihres Clusters von dem Projekt Ihres Flottenhosts unterscheidet, müssen Sie den Cloud Service Mesh-Dienstkonten im Flottenprojekt den Zugriff auf das Clusterprojekt erlauben 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 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: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, 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 unbedingt 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:

  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 aufgeführt wurde, als Sie geprüft haben, ob Ihr Cluster bei der Flotte registriert wurde.
MEMBERSHIP_LOCATION ist der Standort Ihrer Mitgliedschaft (entweder eine Region oder global).

Wenn Sie die Mitgliedschaft kürzlich 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 du dich vor Mai 2023 registriert hast oder wenn du bei der Registrierung der Mitgliedschaft den Standort global angegeben hast. 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.'
...

Sehen Sie sich die Steuerungsebene an, die im Feld implementation angezeigt wird, entweder ISTIOD oder TRAFFIC_DIRECTOR. Informationen zu den Unterschieden der Steuerungsebene und zu unterstützten Konfigurationen sowie zur Auswahl der Implementierung der Steuerungsebene finden Sie unter Von Cloud Service Mesh unterstützte Features.

`kubectl` so konfigurieren, dass er auf den Cluster verweist

In den folgenden Abschnitten werden kubectl-Befehle für jeden Ihrer Cluster ausgeführt. Bevor Sie die folgenden Abschnitte durchgehen, führen Sie den folgenden Befehl für jeden Ihrer Cluster aus, um kubectl so zu konfigurieren, dass er 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 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. Informationen zum Aktivieren weiterer optionaler Features finden Sie unter Optionale Features in Cloud Service Mesh aktivieren.

Verwaltete Datenebene

Wenn Sie das verwaltete Cloud Service Mesh verwenden, verwaltet Google Upgrades Ihrer Proxys vollständig, sofern Sie es nicht deaktivieren.

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

Wenn die Proxyverwaltung deaktiviert ist, wird sie 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, indem sie Pods entfernt, die frühere Versionen des Proxys ausführen. Die Bereinigungen erfolgen schrittweise unter Berücksichtigung des Budgets für Pod-Störungen und zur Kontrolle 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 ein verwaltetes Cloud Service Mesh auf einem neuen Cluster bereitstellen, können Sie die verwaltete Datenebene vollständig oder für einzelne Namespaces oder Pods deaktivieren. Die verwaltete Datenebene ist für vorhandene Cluster, in denen sie standardmäßig oder manuell deaktiviert war, weiterhin deaktiviert.

Wenn Sie die verwaltete Datenebene auf Clusterebene deaktivieren und die Sidecar-Proxys wieder selbst verwalten möchten, ä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 mindestens zwei Tage vor dem Upgradevorgang gesendet.

So aktivieren Sie Wartungsbenachrichtigungen für verwaltete Datenebenen:

Öffnen Sie die Seite Kommunikation.

Zur Seite "Kommunikation"
Wählen Sie in der Zeile Cloud Service Mesh Upgrade in der Spalte E-Mail das Optionsfeld aus, um Wartungsbenachrichtigungen auf EIN zu setzen.

Jeder Nutzer, der Benachrichtigungen erhalten möchte, muss sich separat anmelden. Wenn Sie einen E-Mail-Filter für diese Benachrichtigungen festlegen möchten, 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>“

Lieber Cloud Service Mesh-Nutzer,

Das Upgrade der Cloud Service Mesh-Komponenten in Ihrem Cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) ist am ${scheduled_date_human_within} um ${scheduled_time_human_visible} 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

Ihr 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, die die Google Cloud Platform oder Ihr Konto betreffen. 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 fort.

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

Durch das Aktivieren von Cloud Service Mesh mit der Flotten-API 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 unter Endpunkterkennung zwischen Clustern mit deklarativer API.

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

Anwendungen bereitstellen

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

Verwaltet (TD)

Wenden Sie das Standardinjektionslabel auf den Namespace an:

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

Verwaltet (mithilfe von Istio)

Empfohlen:Führen Sie den folgenden Befehl aus, um das standardmäßige Injection-Label auf den Namespace anzuwenden:

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

Wenn Sie bereits Nutzer mit der verwalteten Istio-Steuerungsebene sind: Wir empfehlen die Verwendung der Standardeinschleusung, aber die versionsbasierte Injektion wird unterstützt. Gehen Sie dazu so vor:

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 für die 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.

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 jetzt konfiguriert. Wenn Arbeitslasten in beschrifteten Namespaces vorhanden sind, starten Sie diese neu, damit sie Proxys eingeschleust werden.

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 die Injection-Einstellungen anpassen. Dies kann jedoch zu unvorhergesehenen Konfigurationsfehlern und zu Problemen mit Sidecar-Containern führen. Bevor Sie die Injektion anpassen, sollten Sie die Informationen nach dem Beispiel lesen, um Hinweise zu bestimmten Einstellungen und Empfehlungen zu erhalten.

Diese Optionen können für einzelne Pods durch eine Konfiguration pro Pod überschrieben werden. Dazu fügen Sie dem Pod einen istio-proxy-Container hinzu. Die Sidecar-Injektion behandelt alle hier definierten Konfigurationen als Überschreibung der Standardvorlage für die Injektion.

Mit der folgenden Konfiguration werden beispielsweise verschiedene Einstellungen angepasst, einschließlich der Verringerung der CPU-Anfragen sowie des Hinzufügens einer Volume-Bereitstellung und eines preStop-Hooks:

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

Grundsätzlich kann jedes Feld in einem Pod festgelegt werden. Bei bestimmten Feldern ist jedoch Vorsicht geboten:

Bei Kubernetes muss das Feld image festgelegt werden, bevor die Injektion ausgeführt wird. Sie können das Standard-Image durch ein bestimmtes Image überschreiben. Wir empfehlen jedoch, image auf auto zu setzen. Dadurch wird das zu verwendende Image vom Sidecar-Injektor automatisch ausgewählt.
Einige Felder in containers sind abhängig von zugehörigen Einstellungen. Muss beispielsweise kleiner oder gleich dem CPU-Limit sein. Wenn beide Felder nicht ordnungsgemäß 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.

Darüber hinaus können bestimmte Felder durch Annotationen auf dem Pod konfiguriert werden. Es wird jedoch empfohlen, den obigen Ansatz zum Anpassen von Einstellungen zu verwenden. Achten Sie besonders auf die folgenden Anmerkungen:

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 der Sidecar-Datei als unbegrenzt festgelegt.
Wenn für GKE Standard sidecar.istio.io/proxyMemory festgelegt ist, müssen Sie sidecar.istio.io/proxyMemoryLimit explizit festlegen. Andernfalls wird das Arbeitsspeicherlimit der Sidecar-Datei als unbegrenzt festgelegt.
Für GKE Autopilot kann das Konfigurieren der Ressourcen requests und limits mit Annotationen zu einer Überdimensionierung von Ressourcen führen. Nutzen Sie die Bildvorlage, die Sie vermeiden sollten. Beispiele für Ressourcenänderungen in Autopilot

Ein Beispiel finden Sie in der folgenden Anmerkung zu Ressourcen:

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

Führen Sie die folgenden Schritte aus, um Anwendungen vom clusterinternen Cloud Service Mesh zum verwalteten Cloud Service Mesh zu migrieren:

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

Verwaltet (TD)

Wenden Sie das Standardinjektionslabel auf den Namespace an:

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

Verwaltet (mithilfe von Istio)

Empfohlen:Führen Sie den folgenden Befehl aus, um das standardmäßige Injection-Label auf den Namespace anzuwenden:

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

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 für die 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.

Wenden Sie das Überarbeitungslabel auf den Namespace an.

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

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

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:

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

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

Für das Gateway ist jetzt die Überarbeitung asm-managed festgelegt. Führen Sie für das Rollback den Cloud Service Mesh-Installationsbefehl noch einmal aus. Dadurch wird das Gateway noch einmal 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.

Verwaltete Cloud Service Mesh-Steuerungsebene in GKE bereitstellen

Vorbereitung

Voraussetzungen

Zum Installieren von Cloud Service Mesh erforderliche Rollen

Beschränkungen

Hinweise

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

Verwaltetes Cloud Service Mesh konfigurieren

Für Ihre Flotte konfigurieren

Console

gcloud

Pro Cluster konfigurieren

Flottenfeature von Cloud Service Mesh aktivieren

Cluster bei einer Flotte registrieren

Certificate Authority Service konfigurieren (optional)

Automatische Verwaltung aktivieren

Bereitstellung der Steuerungsebene prüfen

kubectl so konfigurieren, dass er auf den Cluster verweist

Verwaltete Datenebene

Verwaltete Datenebene deaktivieren (optional)

Wartungsbenachrichtigungen aktivieren

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

Anwendungen bereitstellen

Verwaltet (TD)

Verwaltet (mithilfe von Istio)

Injektion anpassen (optional)

Anwendungen zum verwalteten Cloud Service Mesh migrieren

Verwaltet (TD)

Verwaltet (mithilfe von Istio)

Alte Steuerungsebene löschen

Rollback durchführen

Cloud Service Mesh deinstallieren

`kubectl` so konfigurieren, dass er auf den Cluster verweist