Verwaltetes Cloud Service Mesh mit asmcli bereitstellen

Übersicht

Verwaltetes Cloud Service Mesh mit asmcli ist eine verwaltete Steuerungsebene und eine verwaltete Datenebene, die Sie einfach konfigurieren. Google sorgt für ihre Zuverlässigkeit, Upgrades, Skalierung und Sicherheit in abwärtskompatibler Art und Weise. In dieser Anleitung wird erläutert, wie Sie Anwendungen einrichten oder zum verwalteten Cloud Service Mesh in einer Einzel- oder Multi-Cluster-Konfiguration mit asmcli migrieren.

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

Vorbereitung

Sie sollten Folgendes bereits haben:

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. Dieser Schritt kann separat vor der Bereitstellung oder im Rahmen der Bereitstellung erfolgen. Übergeben Sie dazu die Flags --enable-registration und --fleet-id.

  • In Ihrem Projekt muss das Service Mesh Flotten-Feature aktiviert sein. Sie können die Funktion im Rahmen der Bereitstellung aktivieren, indem Sie --enable-gcp-components übergeben oder den folgenden Befehl ausführen:

    gcloud container fleet mesh enable --project=FLEET_PROJECT_ID

    Dabei ist FLEET_PROJECT_ID die Projekt-ID des Flottenhostprojekts.

  • 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.
    • Wenn Ihre Organisation VPC Service Controls verwendet und Sie Cloud Service Mesh in GKE-Clustern mit einer Version größer oder gleich 1.22.1-gke.10 bereitstellen, müssen Sie möglicherweise zusätzliche Konfigurationsschritte ausführen:

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

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.

  • 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 mit der TRAFFIC_DIRECTOR-Implementierung verwaltete Cloud Service Mesh-Cluster, für die die GKE Sandbox aktiviert ist, nicht unterstützt.

  • Das asmcli-Tool muss Zugriff auf den Google Kubernetes Engine-Endpunkt (GKE) haben. Sie können den Zugriff über einen Jumpserver konfigurieren, z. B. eine Compute Engine-VM innerhalb der Virtual Private Cloud (VPC), die bestimmten Zugriff gewährt.

Hinweise

gcloud konfigurieren

Führen Sie die folgenden Schritte auch dann aus, wenn Sie Cloud Shell verwenden.

  1. Authentifizieren Sie sich mit dem Google Cloud CLI:

    gcloud auth login --project PROJECT_ID

    Dabei ist PROJECT_ID die eindeutige Kennzeichnung des Clusterprojekts. Führen Sie den folgenden Befehl aus, um Ihre PROJECT_ID abzurufen:

       gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
   ```

  2. Aktualisieren Sie die Komponenten:

    gcloud components update

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

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

Installationstool herunterladen

  1. Laden Sie die neueste Version des Tools in das aktuelle Arbeitsverzeichnis herunter:

    curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli

  2. Machen Sie das Tool ausführbar:

    chmod +x asmcli

Jeden Cluster konfigurieren

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

Verwaltete Steuerungsebene anwenden

Bevor Sie die verwaltete Steuerungsebene anwenden können, müssen Sie einen Release-Channel auswählen. Ihr Cloud Service Mesh-Kanal wird durch Ihren GKE-Clusterkanal zum Zeitpunkt der Bereitstellung von verwaltetem Cloud Service Mesh bestimmt. Mehrere Kanäle im selben Cluster gleichzeitig werden nicht unterstützt.

Führen Sie das Installationstool für jeden Cluster aus, der verwaltetes Cloud Service Mesh verwendet. Wir empfehlen, die beiden folgenden Optionen anzugeben:

  • --enable-registration --fleet_id FLEET_PROJECT_ID Diese beiden Flags registrieren den Cluster in einer Flotte, wobei FLEET_ID die Projekt-ID des Fleet-Hostprojekts ist. Wenn Sie ein einzelnes Projekt verwenden, ist FLEET_PROJECT_ID mit PROJECT_ID identisch, also das das Flottenhostprojekt und das Clusterprojekt sind identisch. In komplexeren Konfigurationen wie mehreren Projekten empfehlen wir die Verwendung eines separaten Hostprojekts.

  • --enable-all Dieses Flag aktiviert sowohl die erforderlichen Komponenten als auch die Registrierung.

Das asmcli-Tool konfiguriert die verwaltete Steuerungsebene direkt mit Tools und Logik im CLI-Tool. Folgen Sie der nachstehenden Anleitungen je nach Ihrer bevorzugten Zertifizierungsstelle.

Zertifizierungsstellen

Wählen Sie eine Zertifizierungsstelle für Ihr Mesh aus.

Mesh CA

Führen Sie den folgenden Befehl aus, um die Steuerungsebene mit Standardfeatures und Mesh CA zu installieren. Geben Sie Ihre Werte in die angegebenen Platzhalter ein.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all

CA-Dienst

  1. Führen Sie die Schritte unter Certificate Authority Service konfigurieren aus.
  2. Führen Sie den folgenden Befehl aus, um die Steuerungsebene mit Standardfeatures und Certificate Authority Service zu installieren. Geben Sie Ihre Werte in die angegebenen Platzhalter ein.
  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all \
      --ca gcp_cas \
      --ca_pool pool_name

Das Tool lädt alle Dateien zum Konfigurieren der verwalteten Steuerungsebene in das angegebene Verzeichnis --output_dir herunter und installiert das istioctl-Tool und Beispielanwendungen. Bei den Schritten in diesem Leitfaden wird davon ausgegangen, dass Sie istioctl über den --output_dir-Speicherort ausführen, den Sie bei der Ausführung von asmcli install festgelegt haben, wobei istioctl im Unterverzeichnis <Istio release dir>/bin vorhanden ist.

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

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:

membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      ...
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'

Wenn der Status innerhalb weniger Minuten nicht ACTIVE erreicht, finden Sie unter Status der verwalteten Steuerungsebene prüfen weitere Informationen zu möglichen Fehlern.

Zero-Touch-Upgrades

Sobald die verwaltete Steuerungsebene installiert ist, führt Google ein Upgrade automatisch durch, wenn neue Releases oder Patches verfügbar sind.

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. Dies beginnt nach dem Upgrade der Steuerungsebene und ist normalerweise innerhalb von zwei Wochen nach dem Start 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.

Die verwaltete Datenebene verwaltet nicht Folgendes:

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

Wenn Sie Managed Cloud Service Mesh in einem älteren Cluster bereitgestellt haben, können Sie die Datenebenenverwaltung für den gesamten Cluster aktivieren:

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

Alternativ können Sie die verwaltete Datenebene selektiv für eine bestimmte Überarbeitung, einen bestimmten Namespace oder einen bestimmten Pod der Steuerungsebene aktivieren, indem Sie sie mit derselben Annotation versehen. Wenn Sie einzelne Komponenten selektiv steuern, ist die Reihenfolge der Überarbeitung die Steuerungsebene, der Namespace und dann der Pod.

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

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Erwartete Ausgabe

membershipStates:
  projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
    servicemesh:
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed-rapid.'

Wenn der Dienst nicht innerhalb von zehn Minuten bereit ist, lesen Sie die Informationen unter Status der verwalteten Datenebene.

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"}'

Wartungsfenster aktivieren

Wenn Sie ein GKE-Wartungsfenster konfiguriert haben, beginnen aktive Upgrades zu Beginn des nächsten verfügbaren Wartungsfensters und werden ohne Pause fortgesetzt, bis alle verwalteten Pods aktualisiert wurden (normalerweise 12 Stunden). Das Wartungsfenster wird bei CVE-bezogenen Roll-outs nicht eingehalten.

Cloud Service Mesh verwendet das Wartungsfenster von GKE, um mit GKE übereinzustimmen.

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.

Öffentliche Cluster

Endpunkterkennung zwischen öffentlichen Clustern konfigurieren

Wenn Sie mit öffentlichen Clustern (nicht privaten Clustern) arbeiten, haben Sie folgende Möglichkeiten: Endpunkterkennung zwischen öffentlichen Clustern konfigurieren oder noch einfacher Endpunkterkennung zwischen öffentlichen Clustern aktivieren.

Private Cluster

Endpunkterkennung zwischen privaten Clustern konfigurieren

Wenn Sie private GKE-Cluster verwenden, müssen Sie den Endpunkt der Clustersteuerungsebene als öffentlichen Endpunkt statt als privaten Endpunkt konfigurieren. Weitere Informationen finden Sie unter Endpunkterkennung zwischen privaten Clustern konfigurieren.

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 Steuerungsebenenimplementierung 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-Anschluss 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 den 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 in 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"

Messwerte der Steuerungsebene prüfen

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

So prüfen Sie, ob Ihre Konfiguration wie erwartet funktioniert:

  1. Rufen Sie in der Google Cloud Console die Messwerte der Steuerungsebene auf:

    Zum Metrics Explorer

  2. Wählen Sie Ihren Arbeitsbereich aus und fügen Sie mit den folgenden Parametern eine benutzerdefinierte Abfrage hinzu:

    • Ressourcentyp: Kubernetes-Container
    • Messwert: Proxy-Clients
    • Filter: container_name="cr-REVISION_LABEL"
    • Gruppieren nach: revision-Label und proxy_version-Label
    • Aggregator: Summe
    • Zeitraum: 1 Minute

    Wenn Sie Cloud Service Mesh sowohl mit einer von Google verwalteten als auch mit einer clusterinternen Steuerungsebene ausführen, können Sie die Messwerte anhand ihres Containernamens unterscheiden. Beispielsweise haben verwaltete Messwerte den Wert container_name="cr-asm-managed", während nicht verwatete Messwerte container_name="discovery" haben. Entfernen Sie den Filter für container_name="cr-asm-managed", um Messwerte aus beiden anzuzeigen.

  3. Prüfen Sie die Version der Steuerungsebene und die Proxyversion anhand der folgenden Felder in Metrics Explorer:

    • Das Feld Überarbeitung gibt die Version der Steuerungsebene an.
    • Das Feld proxy_version gibt die proxy_version an.
    • Das Feld Wert gibt die Anzahl der verbundenen Proxys an.

    Informationen zum aktuellen Kanal der Cloud Service Mesh-Versionszuordnung finden Sie unter Cloud Service Mesh-Versionen pro Kanal.

Anwendungen zu verwaltetem Cloud Service Mesh migrieren

Migration vorbereiten

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

  1. Führen Sie das Tool wie unter Von Google verwaltete Steuerungsebene anwenden beschrieben aus.

  2. (Optional) Wenn Sie die von Google verwaltete Datenebene verwenden möchten, aktivieren Sie die Verwaltung der Datenebene:

      kubectl annotate --overwrite controlplanerevision REVISION_TAG \
  mesh.cloud.google.com/proxy='{"managed":"true"}'

Anwendungen migrieren

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

  1. Ersetzen Sie das aktuelle Namespace-Label. Die Schritte hängen von Ihrer Steuerungsebenenimplementierung 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

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.

Fehlerbehebung

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

Nächste Schritte