Verwaltete Cloud Service Mesh-Steuerungsebene in GKE bereitstellen
Cloud Service Mesh ist ein von Google verwaltetes Service Mesh, das Sie einfach aktivieren. Google sorgt für Zuverlässigkeit, Upgrades, Skalierung und Sicherheit.
Auf dieser Seite wird gezeigt, wie Sie mit der Fleet API ein verwaltetes Cloud Service Mesh mit Istio APIs einrichten.
Vorbereitung
Sie sollten Folgendes bereits haben:
- Ein Cloud-Projekt
- Ein Cloud-Rechnungskonto
- die erforderlichen Berechtigungen erhalten haben. zum Bereitstellen des Cloud Service Mesh
- Aktiviert Workload Identity in Ihren Clustern und Knotenpools.
Voraussetzungen
- Ein oder mehrere Cluster mit einer unterstützten Version von GKE in einer der unterstützten Regionen.
- 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 Namespacekube-system
werden CPU: 50 m und Arbeitsspeicher: 128 Mi benötigt. - Der
istio-cni-node
-Daemonset im Namespacekube-system
fordert auf jedem Knoten cpu: 100m und memory: 100Mi an.
- Für die Bereitstellung
- Die Organisationsrichtlinie
constraints/compute.disableInternetNetworkEndpointGroup
muss deaktiviert sein. Wenn die Richtlinie aktiviert ist, funktioniert ServiceEntry möglicherweise nicht. - Prüfen Sie, ob der Clientcomputer, auf dem Sie Managed Cloud Service Mesh bereitstellen, eine Netzwerkverbindung zum API-Server hat.
- Ihre Cluster müssen in einer Flotte registriert sein. Dies ist in der Anleitung enthalten oder kann vor der Bereitstellung separat durchgeführt werden.
- In Ihrem Projekt muss das Service Mesh Flotten-Feature aktiviert sein. Dies ist in der Anleitung enthalten oder kann separat durchgeführt werden.
GKE Autopilot wird nur mit der GKE-Version 1.21.3 und höher unterstützt.
Cloud Service Mesh kann mehrere GKE-Cluster in einem Projekt mit einem einzelnen Projekt oder in einer Umgebung mit einem einzelnen Netzwerk mit mehreren Projekten verwenden.
- Wenn Sie Cluster zusammenführen, die sich nicht im selben Projekt befinden, müssen sie im selben Flottenhostprojekt registriert sein und die Cluster müssen sich zusammen in einer Konfiguration mit freigegebener VPC im selben Netzwerk befinden.
- Bei einer Multi-Cluster-Umgebung mit einem Projekt kann das Flottenprojekt wie das Clusterprojekt. Weitere Informationen zu Flotten finden Sie unter Flottenübersicht.
- Bei einer Umgebung mit mehreren Projekten empfehlen wir, die Flotte in einer von den Clusterprojekten getrennt. Wenn Ihre organisatorischen Richtlinien und die vorhandene Konfiguration dies zulassen, empfehlen wir, das freigegebene VPC-Projekt als Flotten-Hostprojekt zu verwenden. Weitere Informationen finden Sie unter Cluster mit freigegebener VPC einrichten.
Rollen, die zum Installieren von Cloud Service Mesh erforderlich sind
In der folgenden Tabelle werden die Rollen beschrieben, die zum Installieren von verwalteten Cloud Service Mesh.
Rollenname | Rollen-ID | Standort erteilen | Beschreibung |
---|---|---|---|
GKE-Hub-Administrator | roles/gkehub.admin | Flottenprojekt | Vollständiger Zugriff auf GKE-Hubs und zugehörige Ressourcen. |
Service Usage-Administrator | roles/serviceusage.serviceUsageAdmin | Flottenprojekt | Erlaubnis, Dienststatus zu aktivieren, zu deaktivieren und Zustände zu überprüfen, Vorgänge zu überprüfen, sowie Kontingent und Abrechnung für ein Nutzerprojekt zu verarbeiten. (Hinweis 1) |
CA Service-Administrator Beta | roles/privateca.admin | Flottenprojekt | Vollständiger Zugriff auf alle CA Service-Ressourcen. (Hinweis 2) |
Beschränkungen
Wir empfehlen Ihnen, die Liste der Von Cloud Service Mesh unterstützte Features und Einschränkungen. Insbesondere ist Folgendes zu berücksichtigen:
Die
IstioOperator
API wird nicht unterstützt, da sie hauptsächlich den Zugriff auf Clusterkomponenten steuert.Wenn Sie den CA-Dienst verwenden möchten, müssen Sie Cloud Service Mesh pro Cluster konfigurieren. Die Verwendung der Standardkonfiguration der Flotte in GKE Enterprise wird nicht unterstützt.
Bei GKE Autopilot-Clustern wird die projektübergreifende Einrichtung nur mit GKE 1.23 oder höher unterstützt.
Bei GKE Autopilot-Clustern werden die Standardanfragen und -limits für Proxy-Ressourcen auf 500 mCPU und 512 MB Arbeitsspeicher festgelegt, um sich an das Ressourcenlimit von GKE Autopilot anzupassen. Sie können die Standardwerte mit benutzerdefinierte Injektion.
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 von verwaltetem Cloud Service Mesh mit der
TRAFFIC_DIRECTOR
-Implementierung keine Cluster mit aktivierter GKE Sandbox unterstützt.
Hinweis
- 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
ist die ID Ihres Flottenhostprojekts. In der Regel wird die FLEET_PROJECT_ID standardmäßig erstellt und hat denselben Namen wie das Projekt.
gcloud auth login --project FLEET_PROJECT_ID
- 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
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 bei der Flotte registrieren.
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 Cloud Service Mesh installiert ist.
- Klicken Sie auf Mit Flotteneinstellungen synchronisieren und im angezeigten Bestätigungsdialogfeld auf Bestätigen. Dies kann einige Minuten dauern.
Einstellungen auf Flottenebene
Erstellen Sie eine
mesh.yaml
-Datei, die nur die einzige Zeilemanagement: automatic
enthält:echo "management: automatic" > mesh.yaml
Aktivieren Sie Cloud Service Mesh für Ihre Flotte:
gcloud container fleet mesh enable --project FLEET_PROJECT_ID \ --fleet-default-member-config mesh.yaml
Wenn folgender Fehler angezeigt wird, müssen Sie GKE Enterprise aktivieren.
ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The [anthos.googleapis.com] service is required for this operation and is not enabled for the project [PROJECT_NUMBER]. Please use the Google Developers Console to enable it.: failed precondition
Einstellungen auf Netzwerkebene
Wenn sich das Projekt Ihres Netzwerks von Ihrem Fleet-Hostprojekt unterscheidet (z. B. wenn Sie eine freigegebene VPC verwenden), müssen Sie Cloud Service Mesh-Dienstkonten im Fleetprojekt Zugriff auf das Netzwerkprojekt gewähren. Sie müssen dies nur einmal für das Netzwerkprojekt tun.
Gewähren Sie Dienstkonten im Fleet-Projekt die Berechtigung für den Zugriff auf das Netzwerkprojekt:
gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Einstellungen auf Clusterebene
Wenn Sie bereit sind, Cluster für die Verwendung mit Cloud Service Mesh zu erstellen, können Sie sie mit der Google Cloud CLI in einem einzigen Schritt erstellen und registrieren, um die Standardkonfiguration zu verwenden. Beispiel:
gcloud container clusters create-auto CLUSTER_NAME \ --fleet-project FLEET_PROJECT_ID \ --location=LOCATION
Sie können die Projektnummer für Ihr Flottenprojekt mit dem folgenden Befehl abrufen:
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
Das Flag
--location
gibt die Compute-Zone oder -Region an (z. B.us-central1-a
oderus-central1
) für den Cluster.Wenn sich das Projekt Ihres Clusters von Ihrem Flotten-Hostprojekt unterscheidet, müssen Sie Erlauben Sie Cloud Service Mesh-Dienstkonten im Flottenprojekt den Zugriff auf Clusterprojekt und aktivieren Sie die erforderlichen APIs im Clusterprojekt. Dies ist nur einmal für jedes Clusterprojekt erforderlich.
Gewähren Sie Dienstkonten im Flottenprojekt Zugriff auf die Clusterprojekt:
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Aktivieren Sie die Mesh API im Projekt des Clusters:
gcloud services enable mesh.googleapis.com \ --project=CLUSTER_PROJECT_ID
Ersetzen Sie CLUSTER_PROJECT_ID durch die eindeutige Kennung Ihres Clusterprojekts. Wenn Sie Ihren Cluster im selben Projekt wie Ihre Flotte erstellt haben, ist CLUSTER_PROJECT_ID mit FLEET_PROJECT_ID identisch.
Registrieren Sie einen GKE-Cluster mithilfe der Workload Identity für Geräte. Das Flag
--location
ist die Compute-Zone oder -Region (z. B.us-central1-a
oderus-central1
) für den Cluster.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, wenn Sie die automatische Verwaltung zu aktivieren.
Wenn sich das Projekt des Netzwerks Ihres Clusters von Ihrem Fleet-Hostprojekt unterscheidet (z. B. wenn Sie eine freigegebene VPC verwenden), müssen Sie Cloud Service Mesh-Dienstkonten im Fleetprojekt Zugriff auf das Netzwerkprojekt gewähren. Für das Netzwerkprojekt müssen Sie dies nur einmal tun.
Gewähren Sie Dienstkonten im Fleet-Projekt die Berechtigung für den Zugriff auf das Netzwerkprojekt:
gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Wenn sich das Projekt Ihres Clusters von Ihrem Flotten-Hostprojekt unterscheidet, müssen Sie Cloud Service Mesh-Dienstkonten im Flottenprojekt für den Zugriff auf den Cluster Projekt erstellen und die erforderlichen APIs im Clusterprojekt aktivieren.
Dies ist nur einmal für jedes Clusterprojekt erforderlich. Wenn Sie zuvor verwaltetes Cloud Service Mesh für diese Kombination von Cluster- und Flottenprojekten konfiguriert haben, wurden diese Änderungen bereits angewendet und Sie müssen die folgenden Befehle nicht ausführen.
Gewähren Sie Dienstkonten im Fleet-Projekt die Berechtigung für den Zugriff auf das Clusterprojekt:
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \ --member "serviceAccount: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
- MEMBERSHIP_NAME ist der Name der Mitgliedschaft, der bei der Registrierung des Clusters bei der Flotte aufgeführt wurde.
MEMBERSHIP_LOCATION ist der Standort deiner Mitgliedschaft (entweder ein Region oder
global
).Wenn Sie die Mitgliedschaft vor Kurzem mit dem Befehl in dieser Anleitung erstellt haben, sollte dies die Region Ihres Clusters sein. Wenn Sie einen zonalen Cluster haben, verwenden Sie die Region, die der Zone des Clusters entspricht. Wenn Sie beispielsweise einen zonalen Cluster in
us-central1-c
haben, verwenden Sie den Wertus-central1
.Dieser Wert kann
global
sein, wenn du dich vor Mai 2023 registriert hast oder wenn du hat bei der Registrierung der Mitgliedschaft den Standortglobal
angegeben. Sie können den Standort deiner Mitgliedschaftgcloud container fleet memberships list --project FLEET_PROJECT_ID
- Nicht eingefügte Pods
- Manuell eingefügte Pods
- Jobs
- StatefulSets
- DaemonSets
Öffnen Sie die Seite Kommunikation.
Wählen Sie in der Zeile Cloud Service Mesh-Upgrade unter der Spalte E-Mail die Option Optionsfeld, um Wartungsbenachrichtigungen auf AN zu setzen.
- Wenden Sie das Standard-Injection-Label auf den Namespace an:
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 Kanäle der Steuerungsebene 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.Wenden Sie das Überarbeitungslabel auf den Namespace an.
kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
- Für Kubernetes muss das Feld
image
festgelegt werden, bevor die Injection ausgeführt wird. Sie können ein bestimmtes Image festlegen, um das Standardimage zu überschreiben. Wir empfehlen jedoch,image
aufauto
festzulegen. Dadurch wird das zu verwendende Image automatisch vom Sidecar-Injector ausgewählt. - Einige Felder in
containers
hängen von zugehörigen Einstellungen ab. Sie darf beispielsweise nicht höher als das CPU-Limit sein. Wenn beide Felder nicht korrekt konfiguriert ist, kann der Pod möglicherweise nicht gestartet werden. - Mit Kubernetes können Sie sowohl
requests
als auchlimits
für Ressourcen in Ihrem Podspec
festlegen. GKE Autopilot berücksichtigt nurrequests
. Weitere Informationen finden Sie unter Ressourcenlimits in Autopilot festlegen. - Wenn für GKE Standard
sidecar.istio.io/proxyCPU
festgelegt ist, stellen Sie müssen Sie explizitsidecar.istio.io/proxyCPULimit
festlegen. Andernfalls wird die Sidecar-Datei Das CPU-Limit wird auf „unbegrenzt“ festgelegt. - Wenn für GKE Standard
sidecar.istio.io/proxyMemory
festgelegt ist, müssen Siesidecar.istio.io/proxyMemoryLimit
explizit festlegen. Andernfalls Das Arbeitsspeicherlimit der Sidecar-Datei wird auf "unbegrenzt" festgelegt. - Für GKE Autopilot werden die Ressourcen
requests
undlimits
konfiguriert die Verwendung von Annotationen, kann zu einer Überdimensionierung von Ressourcen führen. Verwenden Sie die Bildvorlage, um dies zu vermeiden. Weitere Informationen finden Sie unter Beispiele für Ressourcenänderungen in Autopilot. - Ersetzen Sie das aktuelle Namespace-Label. Die Schritte hängen von Ihrer Steuerungsebenenimplementierung ab.
- Wenden Sie das Standard-Injection-Label auf den Namespace an:
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.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.
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
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 Wenn Sie die Mesh Configuration API aktivieren, können Sie auf die Cloud Service Mesh-Seiten in der Google Cloud Console und zur Verwendung der Cloud Service Mesh-Zertifizierungsstelle. | Nein |
meshca.googleapis.com |
Bezieht sich auf die Cloud Service Mesh-Zertifizierungsstelle, die vom verwalteten Cloud Service Mesh verwendet wird. | Nein |
container.googleapis.com |
Erforderlich zum Erstellen von Google Kubernetes Engine-Clustern (GKE). | Nein |
gkehub.googleapis.com |
Erforderlich zum Verwalten des Mesh-Netzwerks als Flotte. | Nein |
monitoring.googleapis.com |
Erforderlich zum Erfassen von Telemetrie für Mesh-Arbeitslasten. | Nein |
stackdriver.googleapis.com |
Erforderlich für die Verwendung der Dienste-UI. | Nein |
opsconfigmonitoring.googleapis.com |
Erforderlich, um die Services-UI für Cluster außerhalb von Google Cloud zu verwenden. | Nein |
connectgateway.googleapis.com |
Erforderlich, damit die verwaltete Cloud Service Mesh-Steuerungsebene auf Mesh-Arbeitslasten zugreifen 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 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 Funktion Standard für neue Flottencluster oder Aktivieren Sie es pro Cluster.
Für Ihre Flotte konfigurieren
Wenn Sie aktiviert Google Kubernetes Engine (GKE) Enterprise können Sie Aktivieren Sie das verwaltete Cloud Service Mesh als Standardkonfiguration für Ihre Flotte. Dies bedeutet, dass für jeden neuen GKE-Cluster in Google Cloud, der während der Clustererstellung registriert wird, verwaltetes Cloud Service Mesh im Cluster aktiviert ist. Weitere Informationen zur Standardkonfiguration für Flotten finden Sie unter Features auf Flottenebene verwalten.
Verwaltetes Cloud Service Mesh als Standardkonfiguration für Ihre Flotte aktivieren und registrieren an die Flotte während der Clustererstellung nur Mesh CA. Wenn Sie den Zertifizierungsstellendienst verwenden möchten, empfehlen wir, ihn pro Cluster zu aktivieren.
Führen Sie die folgenden Schritte aus, um Standardeinstellungen auf Flottenebene für das verwaltete Cloud Service Mesh zu aktivieren folgenden Schritten:
Console
gcloud
Wenn Sie Standardeinstellungen auf Flottenebene mit der Google Cloud CLI konfigurieren möchten, müssen Sie die folgenden Einstellungen festlegen:
Weiter zu Bereitstellung der Steuerungsebene prüfen
Pro Cluster konfigurieren
Führen Sie die folgenden Schritte aus, um das verwaltete Cloud Service Mesh für jedes einzelne einzelne Cluster in Ihrem Mesh-Netzwerk.
Cloud Service Mesh-Flottenfeature aktivieren
Aktivieren Sie Cloud Service Mesh im Flottenprojekt. Wenn Sie sich registrieren, mehrere Cluster vorhanden sind, erfolgt die Aktivierung von Cloud Service Mesh auf Flottenebene, sodass Sie nur einmal ausführen müssen.
gcloud container fleet mesh enable --project FLEET_PROJECT_ID
Cluster bei einer Flotte registrieren
Certificate Authority Service konfigurieren (optional)
Wenn für Ihre Service-Mesh-Bereitstellung Certificate Authority Service (CA Service) erforderlich ist, und folgen Sie dann der Anleitung unter Certificate Authority Service für verwaltetes Cloud Service Mesh konfigurieren. um sie für Ihre Flotte zu aktivieren. Schließen Sie alle Schritte ab, bevor Sie fortfahren 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:
Bereitstellung der Steuerungsebene prüfen
Prüfen Sie nach einigen Minuten, ob der Status der Steuerungsebene ACTIVE
lautet:
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
Die Ausgabe sieht etwa so aus:
...
membershipSpecs:
projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
mesh:
management: MANAGEMENT_AUTOMATIC
membershipStates:
projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
servicemesh:
controlPlaneManagement:
details:
- code: REVISION_READY
details: 'Ready: asm-managed'
state: ACTIVE
implementation: ISTIOD | TRAFFIC_DIRECTOR
dataPlaneManagement:
details:
- code: OK
details: Service is running.
state: ACTIVE
state:
code: OK
description: 'Revision(s) ready for use: asm-managed.'
...
Notieren Sie sich die Steuerungsebene, die im Feld implementation
angezeigt wird. Sie können entweder
ISTIOD
oder TRAFFIC_DIRECTOR
. Informationen zu Unterschieden bei der Steuerungsebene, zu unterstützten Konfigurationen und zur Auswahl der Steuerungsebenenimplementierung finden Sie unter Unterstützte Cloud Service Mesh-Features.
Konfigurieren Sie kubectl
so, dass es auf den Cluster verweist.
In den folgenden Abschnitten werden kubectl
-Befehle für jeden der folgenden Schritte ausgeführt:
für Ihre Cluster. Bevor Sie mit den folgenden Abschnitten fortfahren, führen Sie den
folgenden Befehl für jeden Ihrer Cluster, um kubectl
so zu konfigurieren, dass sie auf
des Clusters.
gcloud container clusters get-credentials CLUSTER_NAME \
--location CLUSTER_LOCATION \
--project CLUSTER_PROJECT_ID
Beachten Sie, dass ein Gateway für eingehenden Traffic nicht automatisch mit der Steuerungsebene bereitgestellt wird. Durch das Entkoppeln der Bereitstellung des Ingress-Gateways können Sie Ihre Gateways in einer Produktionsumgebung verwalten. Wenn Sie ein Istio-Ingress- oder -Ausgangsgateway verwenden möchten, lesen Sie den Hilfeartikel Gateways bereitstellen. Wenn Sie die Kubernetes Gateway API verwenden möchten, lesen Sie den Hilfeartikel Gateway für Mesh vorbereiten. Informationen zum Aktivieren anderer optionaler Features finden Sie unter Optionale Features in Cloud Service Mesh aktivieren.
Verwaltete Datenebene
Wenn Sie ein verwaltetes Cloud Service Mesh verwenden, verwaltet Google die Upgrades Ihrer Proxys vollständig es sei denn, Sie deaktivieren sie.
Bei der verwalteten Datenebene werden die Sidecar-Proxys und eingefügten Gateways automatisch in Verbindung mit der verwalteten Steuerungsebene aktualisiert, indem Arbeitslasten neu starten, um neue Versionen des Proxys wieder einzufügen. Dies ist in der Regel 1–2 Wochen nach dem Upgrade der verwalteten Steuerungsebene abgeschlossen.
Wenn diese Option deaktiviert ist, richtet sich die Proxy-Verwaltung nach dem natürlichen Lebenszyklus der Pods in dem Cluster und muss vom Nutzer manuell ausgelöst werden, um das Update zu steuern zu zahlen.
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:
Verwaltete Datenebene deaktivieren (optional)
Wenn Sie das verwaltete Cloud Service Mesh auf einem neuen Cluster bereitstellen, können Sie Sie deaktivieren die verwaltete Datenebene vollständig oder nur für einzelne Namespaces oder Pods. Die verwaltete Datenebene bleibt für vorhandene Cluster deaktiviert, in denen standardmäßig oder manuell deaktiviert wurde.
So deaktivieren Sie die verwaltete Datenebene auf Clusterebene und kehren zurück zu Verwalten Sie die Sidecar-Proxys selbst, ändern Sie die Annotation:
kubectl annotate --overwrite controlplanerevision -n istio-system \
mesh.cloud.google.com/proxy='{"managed":"false"}'
So deaktivieren Sie die verwaltete Datenebene für einen Namespace:
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"false"}'
So deaktivieren Sie die verwaltete Datenebene für einen Pod:
kubectl annotate --overwrite pod POD_NAME \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Wartungsbenachrichtigungen aktivieren
Sie können bis zu eine Woche vor der geplanten Wartung über die bevorstehende Wartung der verwalteten Datenebene informiert werden. Wartungsbenachrichtigungen werden nicht standardmäßig gesendet. Sie müssen außerdem ein GKE-Wartungsfenster konfigurieren, bevor Sie Benachrichtigungen erhalten können. Wenn diese Option aktiviert ist, werden Benachrichtigungen mindestens zwei Tage vor dem Upgrade gesendet.
So aktivieren Sie Wartungsbenachrichtigungen für verwaltete Datenebenen:
Jeder Nutzer, der Benachrichtigungen erhalten möchte, muss diese separat aktivieren. 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: Anstehendes Upgrade für Ihren Cloud Service Mesh-Cluster „
<location/cluster-name>
“Hallo,
Für die Cloud Service Mesh-Komponenten in Ihrem Cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) ist ein Upgrade am ${scheduled_date_human_understand} um ${scheduled_time_human_composer} geplant.
In den Versionshinweisen (https://cloud.google.com/service-mesh/docs/release-notes) finden Sie weitere Informationen zu diesem neuen Update.
Wenn diese Wartung gekündigt wird, erhalten Sie eine weitere Benachrichtigung.
Viele Grüße
Das Cloud Service Mesh-Team
(c) 2023 Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA Mit dieser Mitteilung informieren wir Sie über wichtige Änderungen in Bezug auf die Google Cloud Platform oder Ihr Konto. Sie können Benachrichtigungen zu Wartungsfenstern deaktivieren, indem Sie Ihre Einstellungen anpassen: https://console.cloud.google.com/user-preferences/communication?project=${project_id}
Endpunkterkennung konfigurieren (nur für Installationen mit mehreren Clustern)
Wenn Ihr Mesh-Netzwerk nur einen Cluster hat, überspringen Sie diese Schritte für mehrere Cluster und fahren Sie mit Anwendungen bereitstellen oder Anwendungen migrieren fort.
Bevor Sie fortfahren, prüfen Sie, ob das Cloud Service Mesh auf jedem Gerät konfiguriert ist Cluster.
Wenn Sie Cloud Service Mesh mit der Flotten-API aktivieren, wird die Endpunkterkennung für diesen Cluster aktiviert. Sie müssen jedoch Firewallports öffnen. Informationen zum Deaktivieren der Endpunkterkennung für einen oder mehrere Cluster finden Sie in der Anleitung zum Deaktivieren der Endpunkterkennung zwischen Clustern mit deklarativer API.
Eine Beispielanwendung mit zwei Clustern finden Sie im HelloWorld-Dienstbeispiel.
Anwendungen bereitstellen
Wenn Sie mehr als einen Cluster in der Flotte mit verwaltetem Cloud Service Mesh haben, gilt Folgendes: Achten Sie darauf, dass die Endpunkterkennung oder Firewallports wie vorgesehen konfiguriert sind und Anwendungen bereitstellen.Aktivieren Sie den Namespace für die Injection: Die Schritte hängen von Ihrer Steuerungsebenenimplementierung ab.
Verwaltet (TD)
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
Wenn Sie bereits Nutzer mit der Managed Istiod-Steuerungsebene sind: Wir empfehlen die Standardeinschleusung, aber die überarbeitete Injektion ist unterstützt. Gehen Sie dazu so vor:
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.
Injektion 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. Sidecar-Datei
wird jede hier definierte Konfiguration als Überschreibung des
Standard-Injection-Vorlage.
Mit der folgenden Konfiguration werden beispielsweise
verschiedene Einstellungen angepasst,
wie z. B. das Verringern der CPU-Anfragen, das Hinzufügen einer Volume-Bereitstellung und das Hinzufügen einer
preStop
-Hook:
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
- name: hello
image: alpine
- name: istio-proxy
image: auto
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
cpu: "200m"
memory: "256Mi"
volumeMounts:
- mountPath: /etc/certs
name: certs
lifecycle:
preStop:
exec:
command: ["sleep", "10"]
volumes:
- name: certs
secret:
secretName: istio-certs
Im Allgemeinen kann jedes Feld in einem Pod festgelegt werden. Bei bestimmten Feldern ist jedoch Vorsicht geboten:
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:
Sehen Sie sich beispielsweise die folgende Anmerkung zu Ressourcen an:
spec:
template:
metadata:
annotations:
sidecar.istio.io/proxyCPU: "200m"
sidecar.istio.io/proxyCPULimit: "200m"
sidecar.istio.io/proxyMemory: "256Mi"
sidecar.istio.io/proxyMemoryLimit: "256Mi"
Anwendungen zu verwaltetem Cloud Service Mesh migrieren
So migrieren Sie Anwendungen vom Cloud Service Mesh im Cluster zum verwalteten Cloud Service Mesh: führen Sie die folgenden Schritte aus:
Verwaltet (TD)
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
Wenn Sie bereits Nutzer mit der Managed Istiod-Steuerungsebene sind: Wir empfehlen die Standardeinschleusung, aber die überarbeitete Injektion ist unterstützt. Gehen Sie dazu so vor:
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:
Die verwaltete Steuerungsebene wird automatisch auf null skaliert und verwendet keine Ressource, wenn sie nicht verwendet wird. Die geänderten Webhooks und die Bereitstellung bleiben erhalten und wirken sich nicht auf das Clusterverhalten aus.
Für das Gateway ist jetzt die Überarbeitung asm-managed
festgelegt. Führen Sie für ein Rollback noch einmal aus.
den Cloud Service Mesh-Installationsbefehl, mit dem das Gateway, das zurück verweist, noch einmal bereitgestellt wird.
mit Ihrer clusterinternen Steuerungsebene:
kubectl -n istio-system rollout undo deploy istio-ingressgateway
Bei Erfolg können Sie diese Ausgabe erwarten:
deployment.apps/istio-ingressgateway rolled back
Cloud Service Mesh deinstallieren
Die verwaltete Steuerungsebene wird automatisch auf null skaliert, wenn sie nicht von Namespaces verwendet wird. Für Eine ausführliche Anleitung finden Sie unter Cloud Service Mesh deinstallieren.