Managed Anthos Service Mesh ist ein von Google verwaltetes Service Mesh, das Sie nur aktivieren müssen. Google übernimmt die Zuverlässigkeit, Upgrades, Skalierung und Sicherheit auf abwärtskompatible Weise.
Auf dieser Seite wird gezeigt, wie Sie mit der Fleet Feature API ein verwaltetes Anthos Service Mesh einrichten.
Wenn Sie verwaltetes Anthos Service Mesh mithilfe der Fleet API aktivieren:
- Google wendet die Konfiguration der empfohlenen Steuerungsebene an
- Google aktiviert die automatische Verwaltung der Datenebene.
- Ihr Cluster wird basierend auf dem Releasekanal Ihres GKE-Clusters (Google Kubernetes Engine-Cluster) in einer Release-Version von Anthos Service Mesh registriert und Ihre Steuerungsebene und Datenebene werden mit jedem neuen Release beibehalten.
- Google ermöglicht die Endpunkterkennung und das clusterübergreifende Load-Balancing im gesamten Service Mesh mit Standardeinstellungen, obwohl Sie Firewallregeln erstellen müssen.
Verwenden Sie diesen Onboarding-Pfad für folgende Fälle:
gcloud
zum Konfigurieren des verwalteten Anthos Service Mesh mithilfe von Google Cloud APIs und IAM verwenden- Anthos Service Mesh mit denselben APIs wie andere Fleet-Features konfigurieren
- Automatisch die empfohlene Konfiguration von Anthos Service Mesh für jeden Ihrer Cluster zu erhalten
Vorbereitung
Sie sollten Folgendes bereits haben:
- Ein Cloud-Projekt
- Ein Cloud-Rechnungskonto
- Erforderliche Berechtigungen zum Bereitstellen von verwaltetem Anthos Service Mesh
- 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 Ihr Cluster genügend Kapazität für die erforderlichen Komponenten hat, die von Managed Anthos Service Mesh im Cluster installiert werden.
- Die Bereitstellung
mdp-controller
im Namespacekube-system
fordert die CPU an: 50 m, den Arbeitsspeicher: 128 Mi. - Das DaemonSet
istio-cni-node
im Namespacekube-system
fordert auf jedem Knoten die CPU an: 100 m, den Arbeitsspeicher: 100 Mi.
- Die Bereitstellung
- Prüfen Sie, ob der Clientcomputer, auf dem Sie Managed Anthos 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.
Managed Anthos 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 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.
- Wenn Ihre Organisation VPC Service Controls verwendet und verwaltete Anthos Service Mesh in GKE-Cluster bereitstellen, müssen Sie auch die Schritte unter VPC Service Controls für Anthos Service Mesh ausführen.
Beschränkungen
Wir empfehlen Ihnen, die Liste der von verwaltetem Anthos Service Mesh unterstützten Features und Einschränkungen durchzugehen. Insbesondere ist Folgendes zu berücksichtigen:
Die
IstioOperator
API wird nicht unterstützt, da sie hauptsächlich den Zugriff auf Clusterkomponenten steuert.Das Aktivieren des verwalteten Anthos Service Mesh mit der Flotten-API verwendet Mesh CA. Wenn Ihre Service Mesh-Bereitstellung regulierte Arbeitslasten umfasst oder Certificate Authority Service (CA Service) erfordert, folgen Sie der Anleitung unter Verwaltetes Anthos Service Mesh mit
asmcli
bereitstellen.Migrationen von verwaltetem Anthos Service Mesh mit
asmcli
zu Anthos Service Mesh mit Flotten-API werden nicht unterstützt. Ebenso wird das Konfigurieren des verwalteten Anthos Service Mesh mit der Fleet API von--management manual
bis--management automatic
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.
Die tatsächlichen Features, die für das verwaltete Anthos Service Mesh verfügbar sind, hängen von der Release-Version ab. Weitere Informationen finden Sie in der vollständigen Liste der von Anthos Service Mesh unterstützten Features und Einschränkungen.
Während des Bereitstellungsprozesses für eine von verwaltete Steuerungsebene werden Istio-CRDs, die dem ausgewählten Kanal entsprechen, im angegebenen Cluster bereitgestellt. Wenn im Cluster Istio-CRDs vorhanden sind, werden sie überschrieben.
Das Istio-CNI ist nicht mit GKE Sandbox kompatibel. Managed Anthos Service Mesh im Autopilot-Modus funktioniert daher nicht mit GKE Sandbox, da verwaltetes Istio CNI erforderlich ist.
Hinweise
- 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.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
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.
-
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 |
Anthos Service Mesh verwendet die Mesh Configuration API, um Konfigurationsdaten von Ihrem Mesh an Google Cloud weiterzuleiten. Wenn Sie die Mesh Configuration API aktivieren, können Sie außerdem auf die Anthos Service Mesh-Seiten in der Google Cloud Console zugreifen und die Anthos Service Mesh-Zertifizierungsstelle (Mesh CA) verwenden. | Nein |
meshca.googleapis.com |
Bezieht sich auf die Anthos Service Mesh-Zertifizierungsstelle, die vom verwalteten Anthos Service Mesh verwendet wird. | Nein |
container.googleapis.com |
Erforderlich zum Erstellen von GKE-Clustern (Google Kubernetes Engine). | Nein |
gkehub.googleapis.com |
Erforderlich, um das Mesh-Netzwerk als Flotte zu verwalten. | Nein |
monitoring.googleapis.com |
Erforderlich zum Erfassen von Telemetriedaten für Mesh-Arbeitslasten. | Nein |
stackdriver.googleapis.com |
Erforderlich für die Verwendung der Dienste-UI. | Nein |
opsconfigmonitoring.googleapis.com |
Erforderlich zur Verwendung der Services-UI für Cluster außerhalb von Google Cloud. | Nein |
connectgateway.googleapis.com |
Erforderlich, damit die verwaltete Anthos 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* |
Verwaltetes Anthos Service Mesh konfigurieren
Die erforderlichen Schritte zum Bereitstellen des verwalteten Anthos Service Mesh mit der Flotten-API hängen davon ab, ob Sie die Aktivierung standardmäßig für neue Flottencluster oder pro Cluster vornehmen möchten.
Für Ihre Flotte konfigurieren
Wenn Sie die Google Kubernetes Engine (GKE) Enterprise-Version aktiviert haben, können Sie das verwaltete Anthos 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, ein verwaltetes Anthos Service Mesh auf dem Cluster aktiviert ist. Weitere Informationen zur Standardkonfiguration der Flotte finden Sie unter Features auf Flottenebene verwalten.
Führen Sie die folgenden Schritte aus, um Standardwerte auf Flottenebene für das verwaltete Anthos Service Mesh zu aktivieren:
Console
Rufen Sie in der Google Cloud Console die Seite Feature Manager auf.
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.
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:
- 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 Anthos Service Mesh installiert ist.
- 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 Zeilemanagement: automatic
enthält:echo "management: automatic" > mesh.yaml
Aktivieren Sie Anthos 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 Clusterebene
Wenn Sie bereit sind, Cluster für die Verwendung mit Anthos Service Mesh zu erstellen, erstellen und registrieren Sie sie 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
oderus-central1
) für den Cluster an.Wenn sich das Projekt Ihres Clusters von dem Ihres Flotten-Hostprojekts unterscheidet, müssen Sie Anthos 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 Anthos Service Mesh für jeden Cluster in Ihrem Mesh einzeln zu konfigurieren.
Anthos Service Mesh-Flottenfeature aktivieren
Aktivieren Sie Anthos Service Mesh im Flottenprojekt. Wenn Sie mehrere Cluster registrieren möchten, wird Anthos 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
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
oderus-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 von Ihrem Fleet-Hostprojekt unterscheidet, müssen Sie Anthos 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
asmcli
zum Konfigurieren eines verwalteten Anthos Service Mesh für diese Kombination aus Cluster- und Flottenprojekten verwendet 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
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 Wertus-central1
.Dieser Wert kann
global
sein, wenn du dich vor Mai 2023 registriert hast oder wenn du bei der Registrierung der Mitgliedschaft den Standortglobal
angegeben hast. Du kannst den Standort deiner Mitgliedschaft mitgcloud 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
dataPlaneManagement:
details:
- code: OK
details: Service is running.
state: ACTIVE
state:
code: OK
description: 'Revision(s) ready for use: asm-managed.'
...
Beachten Sie das Überarbeitungslabel im Feld details
, z. B. asm-managed
in der angegebenen Ausgabe. Wenn Sie Überarbeitungslabels verwenden, müssen Sie dieses Label festlegen, bevor Sie Anwendungen bereitstellen. Wenn Sie Standard-Injection-Labels verwenden, müssen Sie dieses Label nicht festlegen.
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 anderer optionaler Features finden Sie unter Optionale Features in verwaltetem Anthos Service Mesh aktivieren.
Verwaltete Datenebene
Wenn Sie ein verwaltetes Anthos Service Mesh verwenden, verwaltet Google die Upgrades Ihrer Proxys vollständig, sofern Sie es nicht auf Namespace-, Arbeitslast- oder Überarbeitungsebene 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 Anthos 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 \
REVISION_LABEL \
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.
Wählen Sie in der Zeile Anthos 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 Anthos 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 ASM-Cluster "
<location/cluster-name>
"Hallo Anthos Service Mesh-Nutzer,
Für die Anthos 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
Ihr Anthos Service Mesh-Team
(c) 2022 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)
Bevor Sie fortfahren, sollten Sie bereits verwaltetes Anthos Service Mesh auf jedem Cluster konfiguriert haben, wie in den vorherigen Schritten beschrieben. Sie müssen nicht angeben, dass ein Cluster ein primärer Cluster ist, dies ist das Standardverhalten.
Außerdem müssen Sie asmcli
heruntergeladen haben (nur wenn Sie Ihre Konfiguration mit der Beispielanwendung prüfen möchten) und die Projekt- und Clustervariablen festlegen.
Öffentliche Cluster
Endpunkterkennung zwischen öffentlichen Clustern konfigurieren
Wenn Sie das verwaltete Anthos 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 öffentlichen Clustern mit deklarativer API.
Private Cluster
Endpunkterkennung zwischen privaten Clustern konfigurieren
Wenn Sie das verwaltete Anthos 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 unter Endpunkterkennung zwischen privaten Clustern mit deklarativer API.
Eine Beispielanwendung mit zwei Clustern finden Sie im HelloWorld-Dienstbeispiel.
Anwendungen bereitstellen
Wenn Sie in der Flotte mehrere Cluster mit verwaltetem Anthos Service Mesh haben, müssen Sie dafür sorgen, dass die Endpunkterkennungs- oder Firewallports wie vorgesehen konfiguriert sind, bevor Sie Anwendungen bereitstellen und fortfahren.Verwenden Sie zum Bereitstellen von Anwendungen entweder das Label des Kanals, den Sie während der Installation konfiguriert haben, oder istio-injection=enabled
, wenn Sie Standard-Injektionslabels verwenden.
Standard-Injektionslabels
kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite
Überarbeitungslabel
Entfernen Sie vor dem Bereitstellen von Anwendungen alle vorherigen istio-injection
-Labels aus ihren Namespaces und legen Sie stattdessen das Label istio.io/rev=REVISION_LABEL
fest.
Dies ist das Überarbeitungslabel, das Sie bei der Prüfung der Steuerungsebene identifiziert haben.
Wenn Sie es in ein bestimmtes Überarbeitungslabel ändern möchten, klicken Sie auf REVISION_LABEL
und ersetzen Sie es durch das entsprechende Label: asm-managed-rapid
für Rapid, asm-managed
für Regular oder asm-managed-stable
für Stabile.
Das Überarbeitungslabel entspricht einer Release-Version:
Überarbeitungslabel | Kanal |
---|---|
asm-managed |
Regulär |
asm-managed-rapid |
Rapid |
asm-managed-stable |
Stabile Version |
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Sie haben nun das verwaltete Anthos Service Mesh erfolgreich konfiguriert. Wenn Arbeitslasten in beschrifteten Namespaces vorhanden sind, starten Sie diese neu, damit sie Proxys eingeschleust werden.
Jetzt können Sie die Anwendungen oder die Bookinfo-Beispielanwendung bereitstellen.
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)
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"
limites:
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. Es wird jedoch empfohlen,image
aufauto
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. Beispielsweise muss die CPU-Anfrage unter dem CPU-Limit liegen. Wenn beide Felder nicht ordnungsgemäß konfiguriert sind, kann der Pod möglicherweise nicht gestartet werden. - Mit Kubernetes können Sie sowohl
requests
als auchlimits
für Ressourcen inPodSpec
festlegen. GKE Autopilot berücksichtigt nurrequests
. Weitere Informationen finden Sie unter Ressourcenlimits in Autopilot festlegen.
Darüber hinaus lassen sich bestimmte Felder durch Anmerkungen im Pod konfigurieren. Es wird jedoch empfohlen, den obigen Ansatz zum Anpassen der Einstellungen zu verwenden. Bei bestimmten Anmerkungen ist besondere Vorsicht geboten:
- Wenn für GKE Standard
sidecar.istio.io/proxyCPU
festgelegt ist, müssen Siesidecar.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 Siesidecar.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
undlimits
mit Annotationen zu einer Überdimensionierung von Ressourcen führen. Nutzen Sie die Bildvorlage, die Sie vermeiden sollten. Beispiele für Ressourcenänderungen in Autopilot
Hier ein Beispiel für die Konfiguration der Annotationen für 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"
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 ordnungsgemäß funktioniert:
Sehen Sie sich in der Google Cloud Console die Messwerte der Steuerungsebene an:
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: Label
revision
undproxy_version
Label - Aggregator: Summe
- Zeitraum: 1 Minute
Wenn Sie Anthos 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 Messwertecontainer_name="discovery"
haben. Entfernen Sie den Filter fürcontainer_name="cr-asm-managed"
, um Messwerte aus beiden anzuzeigen.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 Anthos Service Mesh-Versionszuordnung finden Sie unter Anthos Service Mesh-Versionen pro Kanal.
Anwendungen zu verwaltetem Anthos Service Mesh migrieren
Führen Sie die folgenden Schritte aus, um Anwendungen von Anthos Service Mesh im Cluster zu einem verwalteten Anthos Service Mesh zu migrieren:
Ersetzen Sie das aktuelle Namespace-Label. Welche Schritte erforderlich sind, hängt davon ab, ob Sie Standard-Injektionslabels (Beispiel:
istio-injection enabled
) oder die Überarbeitungslabel verwenden.Standard-Injektionslabels
Führen Sie den folgenden Befehl aus, um das Standard-Tag in die verwaltete Überarbeitung zu verschieben:
istioctl tag set default --revision REVISION_LABEL
Führen Sie den folgenden Befehl aus, um den Namespace mit
istio-injection=enabled
zu kennzeichnen, falls noch nicht geschehen:kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- \ --overwrite
Überarbeitungslabel
Wenn Sie das Label
istio.io/rev=REVISION_LABEL
verwendet haben, führen Sie den folgenden Befehl aus: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.
Prüfen Sie, ob die Messwerte wie erwartet angezeigt werden. Führen Sie dazu die Schritte unter Messwerte der Steuerungsebene prüfen aus.
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 den Anthos 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
Anthos 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 Anthos 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
- Optionale verwaltete Anthos Service Mesh-Features aktivieren, z. B.:
- Transportsicherheit konfigurieren, um Ihr Mesh zu schützen