Verwaltetes Cloud Service Mesh mit Asmcli bereitstellen
Übersicht
Managed Cloud Service Mesh mit asmcli
ist eine verwaltete Steuerungsebene und
eine verwaltete Datenebene,
die Sie einfach konfigurieren können. Google sorgt für ihre Zuverlässigkeit, Upgrades, Skalierung und Sicherheit in abwärtskompatibler Art und Weise. Dieses
Anleitung zum Einrichten oder Migrieren von Anwendungen zum verwalteten Cloud Service Mesh
in einer Einzel- oder Multi-Cluster-Konfiguration mit asmcli
.
Weitere Informationen zu den unterstützten Features und Einschränkungen des verwalteten Cloud Service Mesh finden Sie hier: Siehe Unterstützte Features von Managed Cloud Service Mesh.
Vorbereitung
Sie sollten Folgendes bereits haben:
- Ein Cloud-Projekt
- Ein Cloud-Rechnungskonto
- die erforderlichen Berechtigungen erhalten haben. zum Bereitstellen des Cloud Service Mesh
- Das
asmcli
-Installationstool,kpt
und andere Tools, die unter Erforderliche Tools installieren angegeben sind
Für eine schnellere Bereitstellung muss für Ihre Cluster Workload Identity aktiviert sein. Wenn Workload Identity nicht aktiviert ist, wird es durch die Bereitstellung automatisch aktiviert.
Voraussetzungen
- Ein oder mehrere Cluster mit einer unterstützten Version von GKE in einer der unterstützten Regionen.
- Sorgen Sie dafür, dass Ihr Cluster genügend Kapazität für die erforderlichen Komponenten hat,
verwaltete Cloud Service Mesh-Installationen im Cluster.
- Das Deployment
mdp-controller
im Namespacekube-system
fordert CPU an: 50 m, Arbeitsspeicher: 128 Mi - Das Daemonset
istio-cni-node
im Namespacekube-system
fordert CPU an: 100m, Arbeitsspeicher: 100 Mi auf jedem Knoten.
- Das Deployment
- Achten Sie darauf, dass der Clientcomputer, auf dem Sie das verwaltete Cloud Service Mesh bereitstellen, Netzwerkverbindung zum API-Server.
- 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 unterstützt 1.21.3+.
Cloud Service Mesh kann mehrere GKE-Cluster in einem Umgebung mit einem Projekt und einem Netzwerk oder einem Netzwerk mit mehreren Projekten zu verbessern.
- 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 trennen. Wenn Ihre Organisation und die vorhandene Konfiguration dies zulassen, empfehlen wir die Verwendung von das freigegebene VPC-Projekt als Flotten-Hostprojekt. Weitere Informationen finden Sie unter Cluster mit freigegebener VPC einrichten.
- Wenn Ihre Organisation VPC Service Controls verwendet und Sie mithilfe von
Cloud Service Mesh in GKE-Clustern mit einem Release
größer oder gleich 1.22.1-gke.10 ist, müssen Sie möglicherweise zusätzliche
Konfigurationsschritten:
- Wenn Sie Cloud Service Mesh auf dem
Normalgröße oder stabile Version
Release-Version und dann
Sie müssen das zusätzliche Flag
--use-vpcsc
verwenden, wenn Sie den Parameter verwalteten Steuerungsebene und Leitfaden zu VPC Service Controls (Vorabversion). Andernfalls scheitert die Betereitstellung. - Wenn Sie das Cloud Service Mesh schnell bereitstellen
Release-Version und dann
Sie müssen das zusätzliche Flag
--use-vpcsc
nicht verwenden, wenn Anwendung der verwalteten Steuerungsebene, aber Sie müssen die Leitfaden zu VPC Service Controls (GA).
- Wenn Sie Cloud Service Mesh auf dem
Normalgröße oder stabile Version
Release-Version und dann
Sie müssen das zusätzliche Flag
Zum Installieren von Cloud Service Mesh erforderliche Rollen
In der folgenden Tabelle werden die Rollen beschrieben, die für die Installation 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.Für GKE Autopilot-Cluster ist die projektübergreifende Einrichtung nur ab GKE 1.23 unterstützt.
Für GKE Autopilot-Cluster, um eine Anpassung an den GKE Autopilot-Ressourcenlimit Standard-Proxy-Ressourcenanfragen und -limits sind auf 500 m CPU und 512 MB eingestellt. zu speichern. Sie können die Standardwerte mit benutzerdefinierte Injektion.
Bei der Bereitstellung einer verwalteten Steuerungsebene werden Istio-CRDs im angegebenen Cluster bereitgestellt. Wenn bereits Istio-CRDs im werden diese überschrieben,
Istio CNI und Cloud Service Mesh sind nicht mit GKE Sandbox kompatibel. Dementsprechend wird Das verwaltete Cloud Service Mesh mit der
TRAFFIC_DIRECTOR
-Implementierung unterstützen keine Cluster mit aktivierter GKE Sandbox.Das
asmcli
-Tool muss Zugriff auf den GKE-Endpunkt (Google Kubernetes Engine) haben. Sie können den Zugriff über eine "Sprung" Server wie einem Compute Engine-VM innerhalb der Virtual Private Cloud (VPC), die spezifische Zugriff haben.
Hinweise
gcloud konfigurieren
Führen Sie die folgenden Schritte auch dann aus, wenn Sie Cloud Shell verwenden.
Authentifizieren Sie sich mit dem Google Cloud CLI:
gcloud auth login --project PROJECT_ID
Dabei ist PROJECT_ID die eindeutige Kennzeichnung Ihres Clusterprojekts. Führen Sie den folgenden Befehl aus, um PROJECT_ID abzurufen:
gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)" ```
Aktualisieren Sie die Komponenten:
gcloud components update
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
Laden Sie die neueste Version des Tools in das aktuelle Arbeitsverzeichnis herunter:
curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
Machen Sie das Tool ausführbar:
chmod +x asmcli
Jeden Cluster konfigurieren
Führen Sie die folgenden Schritte aus, um das verwaltete Cloud Service Mesh für jeden Cluster in Ihres Mesh-Netzwerks.
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 unter Zeitpunkt der Bereitstellung des verwalteten Cloud Service Mesh. Beachten Sie, dass mehrere Kanäle sich gleichzeitig im selben Cluster befinden, wird nicht unterstützt.
Führen Sie das Installationstool für jeden Cluster aus, der das verwaltete Cloud Service Mesh verwenden wird. 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, FLEET_PROJECT_ID entspricht der Flotte PROJECT_ID Hostprojekt und das Clusterprojekt sind identisch. In komplexeren Konfigurationen wie mehrere Projekte vornehmen, empfehlen wir die Verwendung eines separaten Flottenhosts Projekt arbeiten.--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
- Führen Sie die Schritte unter Certificate Authority Service konfigurieren aus.
- 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 nicht innerhalb weniger Minuten ACTIVE
erreicht, verweisen Sie auf
Status der verwalteten Steuerungsebene prüfen
finden Sie 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 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.
Auf der verwalteten Datenebene werden Proxys aktualisiert, indem ausgeführte Pods entfernt werden früheren Versionen des Proxys. Die Bereinigungen erfolgen schrittweise, Budget für Pod-Störungen und die Steuerung der Änderungsrate.
Die verwaltete Datenebene verwaltet nicht Folgendes:
- Nicht eingefügte Pods
- Manuell eingefügte Pods
- Jobs
- StatefulSets
- DaemonSets
Wenn Sie das verwaltete Cloud Service Mesh auf einem älteren Cluster bereitgestellt haben, können Sie Aktivieren Sie die Verwaltung der Datenebene für den gesamten Cluster:
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 Überarbeitung, Namespace oder Pod der Steuerungsebene, indem Sie diese mit dem dieselbe Anmerkung. Wenn Sie einzelne Komponenten selektiv steuern, Die Rangfolge ist die Überarbeitung der Steuerungsebene, dann 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 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 an folgende Adresse gesendet: mindestens zwei Tage vor dem Upgradevorgang.
So aktivieren Sie Wartungsbenachrichtigungen für verwaltete Datenebenen:
Ö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.
Jeder Nutzer, der Benachrichtigungen erhalten möchte, muss diese separat aktivieren. Wenn Sie möchten Um einen E-Mail-Filter für diese Benachrichtigungen festzulegen, lautet die Betreffzeile:
Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"
.
Das folgende Beispiel zeigt eine typische Wartungsbenachrichtigung für die verwaltete Datenebene:
Betreff: Anstehendes Upgrade für Ihren Cloud Service Mesh-Cluster „
<location/cluster-name>
“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 Multi-Cluster-Schritte und fahren Sie mit Anwendungen bereitstellen oder Anwendungen migrieren
Bevor Sie fortfahren, prüfen Sie, ob das Cloud Service Mesh auf jedem Gerät konfiguriert ist Cluster.
Ö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 Implementierung der Steuerungsebene ab.
Verwaltet (TD)
- Wenden Sie das Standard-Injection-Label 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 die Standardeinschleusung anzuwenden. Label zum Namespace hinzu:
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. Gehe dazu so vor:
Führen Sie den folgenden Befehl aus, um die verfügbaren Release-Versionen zu finden:
kubectl -n istio-system get controlplanerevision
Die Ausgabe sieht in etwa so aus:
NAME AGE asm-managed-rapid 6d7h
HINWEIS: Wenn in der Liste oben zwei Versionen der Steuerungsebene angezeigt werden, entfernen Sie eine. Mehrere Kanäle der Steuerungsebene im Cluster werden nicht unterstützt.
In der Ausgabe ist der Wert in der Spalte
NAME
das Überarbeitungslabel, das der verfügbaren Release-Version für die Cloud Service Mesh-Version entspricht.Wenden Sie das Überarbeitungslabel auf den Namespace an.
kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Sie haben das verwaltete Cloud Service Mesh erfolgreich konfiguriert. Wenn Sie bereits vorhandene Arbeitslasten in beschrifteten Namespaces haben, starten Sie diese neu, eingefügten Proxys.
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 Einschleusungseinstellungen anpassen, aber das kann zu unvorhergesehenen Konfigurationsfehlern und Problemen mit der Sidecar-Datei Container. Lesen Sie vor dem Anpassen der Injektion die Informationen nach der Stichprobe für Hinweise zu bestimmten Einstellungen und Empfehlungen.
Mit der Konfiguration pro Pod lassen sich diese Optionen für einzelne Pods überschreiben.
Dazu wird dem Pod ein istio-proxy
-Container hinzugefügt. 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. Es muss jedoch darauf geachtet werden, bestimmte Felder:
- Für Kubernetes muss das Feld
image
festgelegt werden, bevor die Injection ausgeführt wird. Sie können zwar das Standardbild durch ein bestimmtes Bild überschreiben, wir empfehlen jedoch, dass Sie denimage
aufauto
setzen, wodurch der Sidecar-Injektor ausgelöst wird. automatisch das Bild auswählen. - Einige Felder in
containers
hängen von zugehörigen Einstellungen ab. Beispiel: muss kleiner oder gleich dem 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
. GKE Autopilot berücksichtigt nurrequests
. Weitere Informationen Weitere Informationen finden Sie unter Ressourcenlimits in Autopilot festlegen.
Darüber hinaus können bestimmte Felder im Pod durch Anmerkungen konfiguriert werden. Es wird jedoch empfohlen, die Einstellungen wie oben beschrieben anzupassen. Achten Sie besonders auf die folgenden Anmerkungen:
- 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, Sie müssensidecar.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. Mit der Vorlage für Bilder zu vermeiden. Beispiele für Ressourcenänderungen in Autopilot
Sehen Sie sich beispielsweise die folgende Ressourcenanmerkung 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 überprüfen Sie, ob Ihre Konfiguration wie erwartet 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
und Labelproxy_version
- 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 an ihrem Containernamen 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 zur Zuordnung der aktuellen Version zu Cloud Service Mesh finden Sie unter Cloud Service Mesh-Versionen pro Kanal.
Anwendungen zum verwalteten Cloud Service Mesh migrieren
Migration vorbereiten
Zur Vorbereitung der Migration von Anwendungen vom Cloud Service Mesh im Cluster zu einem verwalteten Dienst Cloud Service Mesh, führen Sie die folgenden Schritte aus:
Führen Sie das Tool wie unter Von Google verwaltete Steuerungsebene anwenden beschrieben aus.
(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
So migrieren Sie Anwendungen vom Cloud Service Mesh im Cluster zum verwalteten Cloud Service Mesh: führen Sie die folgenden Schritte aus:
- Ersetzen Sie das aktuelle Namespace-Label. Die Schritte hängen von Ihrer Implementierung der Steuerungsebene ab.
Verwaltet (TD)
- Wenden Sie das Standard-Injection-Label 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 die Standardeinschleusung anzuwenden. Label zum Namespace hinzu:
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. Gehe dazu so vor:
Führen Sie den folgenden Befehl aus, um die verfügbaren Release-Versionen zu finden:
kubectl -n istio-system get controlplanerevision
Die Ausgabe sieht in etwa so aus:
NAME AGE asm-managed-rapid 6d7h
HINWEIS: Wenn in der Liste oben zwei Versionen der Steuerungsebene angezeigt werden, entfernen Sie eine. Mehrere Kanäle der Steuerungsebene im Cluster werden nicht unterstützt.
In der Ausgabe ist der Wert in der Spalte
NAME
das Überarbeitungslabel, das der verfügbaren Release-Version für die Cloud Service Mesh-Version entspricht.Wenden Sie das Überarbeitungslabel auf den Namespace an.
kubectl label namespace NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
So führen Sie ein Rolling Upgrade von Bereitstellungen im Namespace durch:
kubectl rollout restart deployment -n NAMESPACE
Testen Sie Ihre Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.
Wenn Sie Arbeitslasten in anderen Namespaces haben, wiederholen Sie die vorherigen Schritte für jeden Namespace.
Wenn Sie die Anwendung in einer Multi-Cluster-Einrichtung bereitgestellt haben, replizieren Sie die Kubernetes- und Istio-Konfiguration in allen Clustern, es sei denn, Sie möchten die Konfiguration auf eine Teilmenge von Clustern beschränken. Die auf einen bestimmten Cluster angewendete Konfiguration ist die "Source of Truth" für diesen Cluster.
Wenn Sie mit der Anwendung zufrieden sind, können Sie den clusterinternen istiod
entfernen, nachdem Sie alle Namespaces für die verwaltete Steuerungsebene geändert haben oder diese als Sicherung beibehalten. istiod
wird automatisch herunterskaliert, um weniger Ressourcen zu verwenden. Fahren Sie mit Alte Steuerungsebene löschen fort.
Falls Probleme auftreten, können Sie diese bestimmen und beheben. Dazu verwenden Sie die Informationen unter Probleme mit der verwalteten Steuerungsebene beheben und führen bei Bedarf ein Rollback auf die vorherige Version durch.
Alte Steuerungsebene löschen
Nachdem Sie die Installation abgeschlossen und bestätigt haben, dass alle Namespaces die von Google verwaltete Steuerungsebene verwenden, können Sie die alte Steuerungsebene löschen.
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
Wenn Sie istioctl kube-inject
anstelle der automatischen Einschleusung verwendet oder zusätzliche Gateways installiert haben, prüfen Sie die Messwerte für die Steuerungsebene und achten Sie darauf, dass die Anzahl der verbundenen Endpunkte null ist.
Rollback durchführen
Führen Sie die folgenden Schritte aus, um ein Rollback auf die vorherige Version der Steuerungsebene durchzuführen:
Aktualisieren Sie Arbeitslasten, damit die vorherige Version der Steuerungsebene eingeschleust werden kann: Im folgenden Befehl wird der Überarbeitungswert
asm-191-1
nur als Beispiel verwendet. Ersetzen Sie den Beispielwert durch das Überarbeitungslabel der vorherigen Steuerungsebene.kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
Starten Sie die Pods neu, um die erneute Injektion auszulösen, damit die Proxys die vorherige Version erhalten:
kubectl rollout restart deployment -n NAMESPACE
Die verwaltete Steuerungsebene wird automatisch auf null skaliert und verwendet keine Ressource, wenn sie nicht verwendet wird. Die geänderten Webhooks und die Bereitstellung bleiben erhalten und wirken sich nicht auf das Clusterverhalten aus.
Für das Gateway ist jetzt die Überarbeitung asm-managed
festgelegt. Führen Sie für ein Rollback noch einmal aus.
den Cloud Service Mesh-Installationsbefehl, mit dem das Gateway, das zurückverweist, 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
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.
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
- Mehr über Release-Versionen erfahren
- Von
IstioOperator
migrieren - Gateway zur verwalteten Steuerungsebene migrieren
- Hier erfahren Sie, wie Sie Aktivieren Sie optionale verwaltete Cloud Service Mesh-Features Beispiele: