Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Upgrade auf Istio 1.6 mit Operator durchführen

Ab Version 1.6 verwendet das Add-on „Istio on Google Kubernetes Engine“ den Istio-Operator für die Installation und Konfiguration. Der Istio-Operator entspricht dem Operatormuster für Kubernetes. Mit dem Operator können Sie Istio konfigurieren. Definieren Sie dazu eine benutzerdefinierte Ressourcendefinition von Kubernetes für die Istio-Installation. Der Operator verwendet dann einen Controller, um die Installation an die benutzerdefinierte Ressource anzupassen.

Wenn Sie Ihren Cluster auf Version 1.17.9-gke.6300 oder höher aktualisieren, werden der Istio 1.6-Operator und die Steuerungsebene zusammen mit der vorhandenen Istio-Steuerungsebene 1.4.x installiert. Das Upgrade erfordert eine Nutzeraktion und richtet sich nach dem Upgrade der Dual-Steuerungsebene (in der Istio-Dokumentation als Canary-Upgrades bezeichnet). Mit einem Upgrade auf zwei Steuerungsebenen können Sie auf die Version 1.6 migrieren. Legen Sie auf Ihren Arbeitslasten ein Label fest, das auf die neue Steuerungsebene verweist, und führen Sie einen fortlaufenden Neustart durch.

Wir geben keine Version 1.5 des Add-ons „Istio on GKE“ heraus. Version 1.6 ist die Version, die nach 1.4.10 veröffentlicht wird.

  • Wenn Sie den Cluster auf die GKE-Versionen 1.17 und höher aktualisieren, ist das integrierte Ingress-Gateway während des Upgrades etwa 5 Minuten lang nicht verfügbar. Alle Nutzeränderungen am Ingress-Deployment gehen dann verloren. Um dieses Problem zu vermeiden, empfehlen wir Ihnen, separate benutzerdefinierte Gateways zu installieren und zu verwalten, wie unter Gateways hinzufügen beschrieben.
  • Es gibt ein bekanntes Problem beim Upgrade von GKE 1.16 auf die Versionen 1.17 und 1.18 vor R33. Eine entsprechende Fehlerkorrektur ist in den Versionen 1.17.12-gke.1501 oder höher und 1.18.9-gke.1501 oder höher verfügbar. Das Problem führt dazu, dass alle benutzerdefinierten Ressourcen, die Sie im Namespace „istio-system“ erstellt haben, während des Upgrades gelöscht werden. Diese Ressourcen müssen manuell neu erstellt werden. Führen Sie nur ein Upgrade auf eine betroffene Version durch. Das Problem tritt nur während Upgrades auf, sodass keine neuen Cluster betroffen sind.

Vorteile des Istio Operator

Der Operator ermöglicht eine bessere Konfigurierbarkeit der Installation. In Versionen des Add-Ons vor 1.6 gleicht der GKE-Add-On-Manager alle Änderungen am Istio-Manifest ab und verhindert die meisten Arten von Konfigurationsänderungen. Für den Istio Operator gilt diese Einschränkung nicht. Der Operator generiert ein Istio-Installationsmanifest auf der Basis der benutzerdefinierten Istio-Ressource (CR), das Sie während der Installation bereitstellen. Diese CR befindet sich unter Ihrer Kontrolle und wird nie abgeglichen.

Nach dem Upgrade auf Istio 1.6 mit dem Operator können Sie vom Add-on „Istio on GKE“ zur Open-Source-Version von Istio migrieren.

Upgrade auf Istio 1.6 mit Operator durchführen

Sie müssen diese Schritte nur einmal ausführen, um auf den Operator umzustellen. Nachfolgende Upgrades folgen dem Upgrade-Prozess der dualen Steuerungsebene.

  1. Wählen Sie eine GKE-Version aus, die Istio 1.6 (1.17.7-gke.81+, 1.17.8-gke.6+) enthält, und aktualisieren Sie Ihren Cluster.

    Das Add-on „Istio on Google Kubernetes Engine“ mit Istio 1.6 installiert zwei Versionen von Istio:

    • Die statische Manifestversion, die vom Add-on-Manager gesteuert wird (die nach dem Upgrade des Clusters aktiv ist).

    • Die vom Operator gesteuerte Version 1.6 (die bis zur Aktivierung inaktiv ist). Die inaktive Version 1.6 stellt keine Verbindung zu Proxys her und nutzt keine verhandelbaren Clusterressourcen.

    Wenn sich die aktuell installierte Version von Istio von der Version im statischen Zielmanifest unterscheidet, führt das Upgrade des Clusters möglicherweise auch ein direktes Upgrade von Istio durch. Wenn in Ihrem Cluster derzeit Istio 1.4.6-gke.0 ausgeführt wird und Sie GKE-Cluster Version 1.17.7-gke.8 auswählen, wird Ihre Istio-Steuerungsebene als Teil des Upgrades auf 1.4.10-gke.0 (oder höher) aktualisiert.

  2. Prüfen Sie, ob die Version 1.6 von Istio installiert ist und ausgeführt wird:

    kubectl get pods -n istio-system
    

    Der istiod-Pod sollte in einem ausgeführten Zustand zusammen mit den 1.4-Steuerungskomponenten angezeigt werden, zum Beispiel:

    NAME                                             READY   STATUS      RESTARTS   AGE
    istio-citadel-78b9b5b589-52cqg                   1/1     Running     0          4m16s
    istio-galley-79bd448645-zxfjm                    1/1     Running     0          4m16s
    istio-ingressgateway-b4f8986c4-dbr6c             1/1     Running     0          4m27s
    istio-pilot-dc558d859-cnrqt                      2/2     Running     1          4m16s
    istio-policy-8664dd6c4-m42xs                     2/2     Running     1          4m15s
    istio-security-post-install-1.4.10-gke.4-255r6   0/1     Completed   0          4m15s
    istio-sidecar-injector-7f85d7f7c4-vt2x9          1/1     Running     0          4m15s
    istio-telemetry-69b6477c5f-4pr6v                 2/2     Running     2          4m15s
    <b>istiod-istio-163-5fccfcf4dd-2p9c8                1/1     Running     0          3m31s</b>
    prometheus-7d9f49d945-4nps2                      2/2     Running     0          3m17s
    promsd-696bcc5b96-ln2s8                          2/2     Running     1          4m15s
    
  3. Alle nicht unterstützten Konfigurationsobjekte der v1alpha1-Sicherheitsrichtlinie müssen migriert sein. Weitere Informationen finden Sie in den Istio-Upgrade-Hinweisen.

  4. Deaktivieren Sie die Konfigurationsvalidierung in der Steuerungsebene 1.4.x:

    1. Bearbeiten Sie die galley-Ressource ClusterRole:

      kubectl edit clusterrole -n istio-system istio-galley-istio-system
      
    2. Ändern Sie im folgenden Listeneintrag den Wert '*' in get:

      - apiGroups:
        - admissionregistration.k8s.io
        resources:
        - validatingwebhookconfigurations
        verbs:
        - '*' # change this to get
      

      Nach der Aktualisierung sollte der Code so aussehen:

      - apiGroups:
        - admissionregistration.k8s.io
        resources:
        - validatingwebhookconfigurations
        verbs:
        - get
      
    3. Löschen Sie die Galley ValidatingWebhookConfiguration:

      kubectl delete ValidatingWebhookConfiguration istio-galley -n istio-system
      

Namespace zu 1.6 migrieren

Die Installation der neuen Überarbeitung hat keine Auswirkungen auf die vorhandenen Sidecar-Proxys. Für ein Upgrade müssen Sie diese so konfigurieren, dass sie auf die neue Steuerungsebene verweisen. Dies wird während der Einfügung von Sidecar-Dateien mithilfe des Namespace-Labels istio.io/rev gesteuert.

  1. Ermitteln Sie die genaue Versionsnummer von Istio 1.6:

    kubectl -n istio-system get pods -lapp=istiod --show-labels

    Die Ausgabe dieses Befehls sieht in etwa so aus:

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-istio-163-5fccfcf4dd-2p9c8   1/1     Running   0          22h   app=istiod,istio.io/rev=istio-163,istio=istiod,pod-template-hash=5fccfcf4dd

    In diesem Beispiel lautet die Version: istio-163

  2. Kennzeichnen Sie den Namespace mit den Arbeitslasten neu, auf die Sie ein Upgrade durchführen möchten. Das Versionslabel muss der Version der Steuerungsebene entsprechen. Ersetzen Sie im folgenden Befehl VERSION durch die Version des vorherigen Befehls. Beispiel: istio-163.

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=VERSION --overwrite
  3. So führen Sie einen rollierenden Neustart der ausgewählten Arbeitslasten durch:

    kubectl rollout restart deployment DEPLOYMENT -n NAMESPACE
  4. Listen Sie die Pods im Namespace auf:

    kubectl get pods -n NAMESPACE
  5. Wählen Sie einen der Pods aus, um zu prüfen, ob die Arbeitslasten mit der Version 1.6 des Sidecar-Proxys eingefügt wurden:

    kubectl describe pod -n NAMESPACE YOUR_SELECTED_POD

    Die Ausgabe sollte den Proxy-Container in der Version 1.6 enthalten, zum Beispiel:

    ...
    istio-proxy:
      Container ID:  docker://22f62020ddcc6f8e02d800b5614e02aae2d082ce991c9e3eab9846d9f2cf90f5
      Image:         gcr.io/gke-release/istio/proxyv2:1.6.3-gke.0
    ...
    
  6. Schließen Sie die Migration aller Namespaces zur neuen Istio-Version ab. Wiederholen Sie die Schritte 3 bis 5 für alle Workload-Namespaces.

Wenn Sie eine Migration zu Anthos Service Mesh machen möchten, fahren Sie mit Alte Steuerungsebene herunterfahren fort.

Führen Sie die folgenden Schritte aus, um die Ingress-Gateways auf die neue Istio-Version zu migrieren, um auf dem Istio-Add-on zu bleiben.

  1. Bearbeiten Sie die IstioOperator-CR, um das Gateway für den eingehenden Traffic durch eine Version 1.6 zu ersetzen:

    kubectl edit istiooperators -n istio-system istio-1-6-3-gke-0
    
  2. Ändern Sie die Einstellung enabled für das Gateway in true:

    ...
    spec:
      components:
        ingressGateways:
        - enabled: false # change this to true
          name: istio-ingressgateway
    
  3. Der Gateway-Pod muss mit der neuen Version 1.6 neu erstellt werden.

    kubectl get pods -n istio-system -l app=istio-ingressgateway -o yaml | grep image
    

Alte Steuerungsebene herunterfahren

Nachdem alle Arbeitslastproxys die Steuerungsebene 1.6 verwenden, können Sie die alte Steuerungsebene herunterskalieren. Skalieren Sie dazu die Replikate jeder alten Komponente auf 0.

So skalieren Sie die Replikate herunter:

kubectl scale deploy -n istio-system --replicas=0 \
  istio-citadel istio-galley istio-pilot istio-policy istio-sidecar-injector istio-telemetry prometheus promsd

Die verbleibenden Istio-Ressourcen können im Cluster problemlos ausgeführt werden.

Wenn Sie auf Istio verbleiben, können Sie die IstioOperator-CR bearbeiten und den Operator gemäß Ihrem eigenen Zeitplan aktualisieren. Weitere Informationen finden Sie in der Dokumentation zu Operatoren.

Zu Anthos Service Mesh migrieren

Vor der Migration zu Anthos Service Mesh müssen Sie den Operator wie unten beschrieben deaktivieren. Nach der Migration konfigurieren Sie das Service Mesh weiterhin im selben IstioOperator-CR-Format wie der Operator. Sie tun dies jedoch mit dem Befehl istioctl install, wenn Sie den installierten Status ändern möchten, anstatt dass der Operator-Controller die IstioOperator-CR im Cluster kontinuierlich beobachtet.

Für die Migration zu Anthos Service Mesh verwenden Sie ein von Google bereitgestelltes Skript, das alle Details zur Vorbereitung Ihres Cloud-Projekts und -Clusters verarbeitet. Anschließend wird Anthos Service Mesh mithilfe der Anthos Service Mesh-Version von istioctl install installiert. Obwohl die Migration zu Anthos Service Mesh 1.7 empfohlen wird, können Sie mit der 1.6-Version des Skripts zu Anthos Service Mesh 1.6 migrieren.

Voraussetzungen

Achten Sie darauf, dass Ihr Cluster die folgenden Anforderungen erfüllt:

  • Ein Maschinentyp mit mindestens vier vCPUs, z. B. e2-standard-4. Wenn der Maschinentyp für Ihren Cluster nicht mindestens vier vCPUs hat, ändern Sie den Maschinentyp, wie unter Arbeitslasten zu anderen Maschinentypen migrieren beschrieben.

  • Die Mindestanzahl an Knoten hängt vom Maschinentyp ab. Anthos Service Mesh erfordert mindestens acht vCPUs. Wenn der Maschinentyp vier vCPUs hat, muss der Cluster mindestens zwei Knoten haben. Wenn der Maschinentyp acht vCPUs umfasst, benötigt der Cluster nur einen Knoten. Informationen zum Hinzufügen von Knoten finden Sie unter Größe eines Clusters anpassen.

  • Das Skript aktiviert Workload Identity in Ihrem Cluster. Workload Identity ist die empfohlene Methode zum Aufrufen von Google APIs. Wenn Sie Workload Identity aktivieren, ändert sich die Art und Weise, wie Aufrufe Ihrer Arbeitslasten an Google APIs gesichert werden. Weitere Informationen hierzu finden Sie unter Einschränkungen bei Workload Identity.

  • Für die Aufnahme in das Service Mesh müssen Dienstports benannt werden und der Name muss das Protokoll des Ports in der folgenden Syntax enthalten: name: protocol[-suffix], wobei die eckigen Klammern ein optionales Suffix angeben, das mit einem Bindestrich beginnen muss. Weitere Informationen finden Sie unter Dienstports benennen.

  • Wenn Sie Anthos Service Mesh in einem privaten Cluster installieren, müssen Sie Port 15017 in der Firewall öffnen, damit der Webhook mit automatischer Sidecar-Einfügung ordnungsgemäß funktioniert. Weitere Informationen finden Sie unter Port auf einem privaten Cluster öffnen.

  • Wenn Sie in Ihrer Organisation einen Dienstperimeter erstellt haben, müssen Sie möglicherweise den Mesh CA-Dienst dem Perimeter hinzufügen. Weitere Informationen finden Sie unter Mesh CA einem Dienstperimeter hinzufügen.

Migration planen

Informationen zur Planung der Migration finden Sie unter Migration von Istio vorbereiten.

Operator deaktivieren

Um zu verhindern, dass der Operator das von Anthos Service Mesh installierte istio-ingressgateway abgleichen kann, müssen Sie den Operator deaktivieren.

So deaktivieren Sie den Operator:

  1. Rufen Sie die Operator-Version ab:

    kubectl get istiooperators -n istio-system
    

    Die Ausgabe sieht etwa so aus:

    NAME                        REVISION     STATUS    AGE
    istio-1-6-11-gke-0          istio-1611   HEALTHY   12h

    In der Beispielausgabe lautet die Operator-Version istio-1-6-11-gke-0.

  2. Operator deaktivieren. Ersetzen Sie im folgenden Befehl VERSION durch die Operator-Version aus dem vorherigen Schritt:

    kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"disabled"}}' --type=merge
    

    Mit diesem Befehl wird der Operator daran gehindert, Änderungen am Cluster vorzunehmen.

Zu Anthos Service Mesh migrieren

In diesem Abschnitt wird beschrieben, wie Sie mit dem Skript install_asm zu Anthos Service Mesh migrieren. Wir empfehlen die Migration zu Anthos Service Mesh 1.7, aber die Migration zu Anthos Service Mesh 1.6 wird ebenfalls unterstützt.

Zu 1.7 migrieren

  1. Installieren Sie die erforderlichen Tools.

  2. Laden Sie das Skript install_asm herunter

  3. Prüfen Sie die Optionen und Flags des Skripts.

    Wenn Sie die Istio-Installation nicht angepasst haben und Citadel weiterhin als Zertifizierungsstelle (Certificate Authority – CA) verwenden möchten, können Sie mit den folgenden Argumenten zum Skript auf Anthos Service Mesh migrieren:

    ./install_asm \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME\
      --cluster_location CLUSTER_LOCATION \
      --mode migrate \
      --ca citadel \
      --enable_apis
    

    Anthos Service Mesh 1.7 stellt auch über GitHub verfügbare Overlay-Dateien für häufig genutzte Funktionen bereit, z. B. die Aktivierung des Egress-Gateways. Weitere Informationen finden Sie unter Optionale Funktionen aktivieren.

  4. Damit die Einrichtung von Anthos Service Mesh abgeschlossen werden kann, müssen Sie die automatische Sidecar-Injektion aktivieren und die Arbeitslasten (noch einmal) bereitstellen.

Zu 1.6 migrieren

  1. Installieren Sie die erforderlichen Tools.

  2. Laden Sie das Skript install_asm herunter

  3. Prüfen Sie die Optionen und Flags des Skripts.

    Wenn Sie die Istio-Installation nicht angepasst haben und Citadel weiterhin als Zertifizierungsstelle (Certificate Authority – CA) verwenden möchten, können Sie mit den folgenden Argumenten zum Skript auf Anthos Service Mesh migrieren:

    ./install_asm \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME\
      --cluster_location CLUSTER_LOCATION \
      --mode migrate \
      --ca citadel \
      --enable_apis
    
  4. Damit die Einrichtung von Anthos Service Mesh abgeschlossen werden kann, müssen Sie die automatische Sidecar-Injektion aktivieren und die Arbeitslasten (noch einmal) bereitstellen.

Nach der Migration

Führen Sie den folgenden Befehl aus und ersetzen Sie VERSION durch die Operator-Version, die Sie zuvor zum Deaktivieren des Operators verwendet haben:

kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"empty"}}'

Mit diesem Befehl wird der Operator mit einem empty-Profil wieder aktiviert. Dadurch werden die zuvor aus dem Cluster installierten Ressourcen entfernt. Dies umfasst nicht die Gateways oder Steuerungsebenenelemente, die vom Skript install_asm installiert wurden.