Diese Seite enthält Informationen zur Planung eines Anthos Service Mesh-Upgrades. Wir empfehlen Ihnen außerdem, die Hinweise zu Istio-Upgrades zu lesen.
Informationen zu Canary-Upgrades
Wir empfehlen, beim Upgrade des Anthos Service Mesh zuerst ein Canary-Deployment der neuen Steuerungsebene auszuführen. Bei einem Canary-Upgrade installiert asmcli
eine neue Überarbeitung der Steuerungsebene neben der alten Steuerungsebene. Sowohl die alte als auch die neue Steuerungsebene sind mit dem Label revision
versehen, das als Kennung für Steuerungsebenen dient.
Anschließend migrieren Sie Arbeitslasten auf die neue Steuerungsebene, indem Sie für Ihre Namespaces dasselbe Label revision
festlegen und einen rollierenden Neustart durchführen. Der Neustart fügt die Sidecar-Proxys wieder in die Pods ein, damit die Proxys die neue Steuerungsebene verwenden. Bei diesem Ansatz können Sie die Auswirkungen des Upgrades auf einen kleinen Prozentsatz Ihrer Arbeitslasten überwachen. Nachdem Sie Ihre Anwendung getestet haben, können Sie den gesamten Traffic zur neuen Steuerungsebene migrieren oder ein Rollback zur alten Steuerungsebene durchführen. Dieser Ansatz ist wesentlich sicherer als ein direktes Upgrade, bei dem die neue Steuerungsebene die alte Steuerungsebene ersetzt.
In dieser ersten Vorschau installiert asmcli
standardmäßig istio-ingressgateway
mit einem Überarbeitungslabel. Dies ermöglicht ein Canary-Upgrade des istio-ingressgateway
und der Steuerungsebene.
Steuerungsebene anpassen
Wenn Sie die vorherige Installation angepasst haben, müssen Sie diese Anpassung nach dem Upgrade von Anthos Service Mesh übernehmen. Wenn Sie die Installation angepasst haben, indem Sie istioctl install
das Flag --set values
hinzugefügt haben, müssen Sie diese Einstellungen in einer YAML-Datei vom Typ IstioOperator
hinzufügen, die als Overlay-Datei bezeichnet wird. Sie geben die Overlay-Datei an, indem Sie beim Ausführen des Skripts die Option --custom_overlay
mit dem Dateinamen verwenden.
Das Paket anthos-service-mesh
in GitHub enthält viele Overlay-Dateien. Diese Dateien enthalten gängige Anpassungen der Standardkonfiguration. Sie können diese Dateien unverändert anwenden oder weitere Änderungen daran vornehmen. Einige Dateien sind erforderlich, um optionale Anthos Service Mesh-Features zu aktivieren.
Das Paket anthos-service-mesh
wird heruntergeladen, wenn Sie asmcli
ausführen, um Ihr Projekt und Ihren Cluster zu validieren.
Wenn Sie Anthos Service Mesh mit asmcli install
installieren, können Sie mit --option
oder --custom_overlay
eine oder mehrere Overlay-Dateien angeben.
Wenn Sie keine Änderungen an den Dateien im anthos-service-mesh
-Repository vornehmen müssen, können Sie --option
verwenden. Das Skript ruft die Datei von GitHub ab. Sie können aber auch die Overlay-Datei ändern und die Änderungen mit der Option --custom_overlay
an asmcli
übergeben.
Zertifizierungsstelle wählen
Wenn Ihre aktuelle Anthos Service Mesh-Installation die Anthos Service Mesh-Zertifizierungsstelle (Mesh CA) als Zertifizierungsstelle für die Ausstellung von mTLS-Zertifikaten (Mutual TLS) verwendet, sollten Sie Mesh CA aus folgenden Gründen weiterhin verwenden:
- Mesh CA ist ein zuverlässiger und skalierbarer Dienst, der für dynamisch skalierte Arbeitslasten in Google Cloud optimiert ist.
- Mit Mesh CA verwaltet Google die Sicherheit und Verfügbarkeit des CA-Back-Ends.
- Mesh CA ermöglicht es Ihnen, sich für alle Cluster auf eine einzige Root of Trust zu verlassen.
Wenn Ihre aktuelle Anthos Service Mesh-Installation Istio CA (früher "Citadel") verwendet, können Sie beim Upgrade zu Mesh CA wechseln. Dazu müssen Sie jedoch Ausfallzeiten planen. Während des Upgrades wird mTLS-Traffic unterbrochen, bis alle Arbeitslasten der neuen Steuerungsebene mit der Mesh CA übergeben wurden.
Zertifikate der Mesh CA enthalten die folgenden Daten zu den Diensten Ihrer Anwendung:
- Die Google Cloud-Projekt-ID
- Der GKE-Namespace
- Der Name des GKE-Dienstkontos
Zertifizierungsstelle bestimmen
Wenn Sie asmcli install
ausführen, um das Upgrade zu starten, geben Sie die Zertifizierungsstelle an, die asmcli
auf der neuen Steuerungsebene aktivieren soll.
Das Ändern von Zertifizierungsstellen führt zu Ausfallzeiten, wenn Arbeitslasten auf der neuen Steuerungsebene bereitgestellt werden. Wenn Sie keine Ausfallzeiten planen können, geben Sie für die neue Steuerungsebene dieselbe Zertifizierungsstelle an, die auch von der alten Steuerungsebene verwendet wird, . Wenn Sie nicht sicher sind, welche Zertifizierungsstelle in Ihrem Mesh aktiviert ist, führen Sie folgende Befehle aus:
Rufen Sie eine Liste der Pods aus einem Ihrer Namespaces ab:
kubectl get pods -n NAMESPACE
Ersetzen Sie im folgenden Befehl
POD_NAME
durch den Namen eines Ihrer Pods:kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1
Wenn die Mesh-Zertifizierungsstelle für den Namespace aktiviert ist, sehen Sie folgende Ausgabe:
- name: CA_ADDR value: meshca.googleapis.com:443
Gateway-Konfiguration vorbereiten
Anthos Service Mesh bietet Ihnen die Möglichkeit, Gateways als Teil Ihres Service Mesh bereitzustellen und zu verwalten. Ein Gateway beschreibt einen Load-Balancer, der am Rand des Mesh-Netzwerks arbeitet und eingehende oder ausgehende HTTP/TCP-Verbindungen empfängt. Gateways sind Envoy-Proxys, die Ihnen eine detaillierte Kontrolle über den in das Mesh-Netzwerk eingehenden und ausgehenden Traffic ermöglichen.
Standardmäßig installiert asmcli
das istio-ingressgateway
nicht. Wir empfehlen, die Steuerungsebene und die Gateways separat bereitzustellen und zu verwalten.
Weitere Informationen finden Sie unter Gateways installieren und aktualisieren. Wenn Sie das standardmäßige istio-ingressgateway
für die clusterinterne Steuerungsebene installieren möchten, fügen Sie das Argument --option legacy-default-ingressgateway
ein.