Upgrade planen

w

Diese Seite enthält Informationen zur Planung eines Cloud Service Mesh-Upgrades. Wir empfehlen Ihnen außerdem, die Hinweise zu Istio-Upgrades zu lesen.

Informationen zu Canary-Upgrades

Wir empfehlen, für ein Upgrade von Cloud 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.

So migrieren Sie Arbeitslasten zur neuen Steuerungsebene:

1. Legen Sie das Label revision der neuen Steuerungsebene in einem Ihrer Namespaces fest.

2. Führen Sie einen rollierenden Neustart durch. Der Neustart fügt die Sidecar-Proxys wieder in die Pods ein, damit die Proxys die neue Steuerungsebene verwenden.

3. Prüfen Sie die Auswirkungen des Upgrades auf die Arbeitslasten. Wiederholen Sie gegebenenfalls die vorherigen Schritte, um die Anwendung zu testen.

4. Nachdem Sie Ihre Anwendung getestet haben, können Sie den gesamten Traffic zur neuen Steuerungsebene migrieren oder ein Rollback zur alten Steuerungsebene durchführen.

Ein Canary-Upgrade ist wesentlich sicherer als ein direktes Upgrade, bei dem die neue Steuerungsebene die alte Steuerungsebene ersetzt. Eine ausführliche Anleitung finden Sie unter Zur neuen Steuerungsebene wechseln.

Steuerungsebene anpassen

Wenn Sie die vorherige Installation angepasst haben, benötigen Sie die gleichen Anpassungen beim Upgrade von Cloud Service Mesh. 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 die Option --custom_overlay mit dem Dateinamen verwenden, wenn Sie asmcli ausführen.

Achtung: Wird die Overlay-Datei weggelassen, führt dies trotzdem zu einer erfolgreichen Installation. Ihr Service Mesh hat jedoch eine andere Konfiguration als beabsichtigt, da die ausgelassenen Werte auf die Standardeinstellungen zurückgesetzt werden, wenn die Steuerungsebene noch einmal bereitgestellt wird.

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 der Dateien sind erforderlich, um optionale Cloud 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 Cloud Service Mesh mit asmcli install installieren, können Sie eine oder mehrere Overlay-Dateien mit --option oder --custom_overlay 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 Cloud Service Mesh-Installation die Cloud Service Mesh-Zertifizierungsstelle als Zertifizierungsstelle für das Ausstellen von gegenseitigen TLS-Zertifikaten (mTLS) verwendet, empfehlen wir aus den folgenden Gründen, weiterhin die Cloud Service Mesh-Zertifizierungsstelle zu verwenden:

• Die Cloud Service Mesh-Zertifizierungsstelle ist ein äußerst zuverlässiger und skalierbarer Dienst, der für dynamisch skalierte Arbeitslasten optimiert ist.
• Mit der Cloud Service Mesh-Zertifizierungsstelle verwaltet Google die Sicherheit und Verfügbarkeit des CA-Back-Ends.
• Mit der Cloud Service Mesh-Zertifizierungsstelle können Sie sich clusterübergreifend auf eine einzige Root of Trust verlassen.

Wenn Ihre aktuelle Cloud Service Mesh-Installation Istio CA (früher „Citadel“) verwendet, können Sie beim Upgrade zur Cloud Service Mesh-Zertifizierungsstelle wechseln, müssen dann aber Ausfallzeiten einplanen. Während des Upgrades wird der mTLS-Traffic unterbrochen, bis alle Arbeitslasten auf die neue Steuerungsebene mit der Cloud Service Mesh-Zertifizierungsstelle umgestellt wurden.

Hinweis zur Plattform: CA Service wird nur auf den folgenden Plattformen unterstützt: GKE-Cluster in Google Cloud, Google Distributed Cloud und Distributed Cloud. Wenn Sie asmcli install ausführen und --ca gcp_cas auf anderen Plattformen angeben, wird die Installation als erfolgreich angezeigt. Ihre Arbeitslasten können jedoch nicht gestartet werden.

Zertifikate der Cloud Service Mesh-Zertifizierungsstelle enthalten die folgenden Daten zu den Diensten Ihrer Anwendung:

• Die Google Cloud-Projekt-ID
• Der GKE-Namespace
• Der Name des GKE-Dienstkontos

Wichtig: Die von Mesh CA ausgestellten Zertifikate sollten nur verwendet werden, um eine sichere Dienst-zu-Dienst-Kommunikation innerhalb Ihres Service Mesh zu ermöglichen, und sollten nicht für andere Zwecke verwendet werden. Diese Zertifikate werden gesendet, wenn Dienste versuchen, über gegenseitiges TLS miteinander zu kommunizieren. Achten Sie darauf, nicht versehentlich vertrauliche Informationen preiszugeben, wenn Sie diese Zertifikate bei der Kommunikation außerhalb Ihres Service Mesh verwenden.

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:

1. Rufen Sie eine Liste der Pods aus einem Ihrer Namespaces ab:

   kubectl get pods -n NAMESPACE
   

2. 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 Cloud Service Mesh-Zertifizierungsstelle für den Namespace aktiviert ist, wird die folgende Ausgabe angezeigt:

   - name: CA_ADDR
     value: meshca.googleapis.com:443
   

Gateway-Konfiguration vorbereiten

Cloud 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.

asmcli installiert die istio-ingressgateway nicht. Wir empfehlen, die Steuerungsebene und die Gateways separat bereitzustellen und zu verwalten. Weitere Informationen finden Sie unter Gateways installieren und aktualisieren.

Plattform upgraden (optional)

Als Best Practice sollten Sie Cloud Service Mesh auf die neueste unterstützte Version aktualisieren, die auch Ihre aktuelle Plattform unterstützt. Führen Sie dann ein Upgrade Ihrer Umgebung durch, damit sie innerhalb der Reichweite der unterstützten Plattformen und Kubernetes-Versionen ist. Führen Sie schließlich bei Bedarf ein Upgrade auf die neueste unterstützte Version von Cloud Service Mesh durch.

Nächste Schritte

• Abhängige Tools installieren und Cluster validieren