Überarbeitungen der Cloud Service Mesh-Steuerungsebene

Diese Seite bezieht sich auf den clusterinternen und verwalteten ISTIOD Implementierungen der Steuerungsebene. Diese Seite gilt nicht für die TRAFFIC_DIRECTOR-Steuerungsebene, eine mehrmandantenfähige, globale Steuerungsebene ohne individuelle Versionen.

Auf dieser Seite wird beschrieben, wie die Überarbeitungen der Steuerungsebene funktionieren und welchen Wert sie für sichere Service Mesh-Upgrades (und Rollbacks) haben.

Grundlagen der Service Mesh-Installation

Grundsätzlich besteht die Cloud Service Mesh-Installation aus zwei Hauptphasen:

  1. Zuerst verwenden Sie das asmcli-Tool, um ein Clusterinterne Steuerungsebene oder konfigurieren Sie die verwaltete Steuerungsebene. Die Steuerungsebene besteht aus einer Reihe von Systemdiensten, die für die Verwaltung der Mesh-Netzwerk-Konfiguration zuständig sind.

  2. Als Nächstes stellen Sie einen speziellen Sidecar-Proxy in Ihrer Umgebung bereit, der die Netzwerkkommunikation zu und von jeder Arbeitslast abfängt. Die Proxys kommunizieren mit der Steuerungsebene, um ihre Konfiguration zu erhalten. Dadurch können Sie den Traffic (Datenebenentraffic) im Mesh-Netzwerk leiten und steuern, ohne Änderungen an Ihren Arbeitslasten vorzunehmen.

    Zum Bereitstellen der Proxys verwenden Sie einen Prozess namens automatische Sidecar-Injektion (automatische Injektion), um einen Proxy als zusätzlichen Sidecar-Container in jedem Ihrer Arbeitslast-Pods auszuführen. Sie müssen die Kubernetes-Manifeste, mit denen Sie Ihre Arbeitslasten bereitstellen, nicht ändern. Sie müssen Ihren Namespaces jedoch ein Label hinzufügen und die Pods neu starten.

Mesh-Netzwerk mit Überarbeitungen auf sichere Weise aktualisieren

Die Möglichkeit, den Traffic zu steuern, ist einer der Hauptvorteile eines Service Mesh. Sie können beispielsweise den Traffic nach der Bereitstellung in der Produktion schrittweise auf die neue Version einer Anwendung verschieben. Wenn Sie während des Upgrades Probleme erkennen, können Sie den Traffic wieder auf die ursprüngliche Version zurückverschieben und so ein einfaches und geringes Risiko für das Rollback eingehen. Dieses Verfahren wird als Canary-Release bezeichnet und reduziert das Risiko bei neuen Bereitstellungen.

Mithilfe von Überarbeitungen der Steuerungsebene in einem Canary-Upgrade installieren Sie eine neue und separate Steuerungsebene und Konfiguration neben der vorhandenen Steuerungsebene. Das Installationsprogramm weist einen String namens „Überarbeitung“ zu, mit dem die neue Steuerungsebene identifiziert wird. Als Erstes erhalten die Sidecar-Proxys weiterhin die Konfiguration der vorherigen Version der Steuerungsebene. Sie verknüpfen Arbeitslasten schrittweise mit der neuen Steuerungsebene durch Benennung der Namespaces oder Pods mit der neuen Überarbeitung der Steuerungsebene. Nachdem Sie einen Namespace oder Pods mit der neuen Überarbeitung benannt haben, starten Sie die Arbeitslast-Pods neu, damit neue Sidecars automatisch eingefügt werden und ihre Konfiguration von der neuen Steuerungsebene erhalten. Bei Problemen können Sie auf einfache Weise einen Rollback ausführen. Dazu verknüpfen Sie die Arbeitslasten mit der ursprünglichen Steuerungsebene.

Wie funktioniert die automatische Injektion?

Die automatische Injektion nutzt ein Kubernetes-Feature namens Zugangssteuerung. Es wird ein mutierender Zugangs-Webhook registriert, der nach neu erstellten Pods sucht. Der Webhook wird mit einem Namespace-Selektor konfiguriert, sodass er nur Pods findet, die für Namespaces mit einem bestimmten Label bereitgestellt werden. Wenn ein Pod mit dem Namespace-Label übereinstimmt, fragt der Webhook einen von der Steuerungsebene bereitgestellten Injektionsdienst ab, um eine neue, geänderte Konfiguration für den Pod zu erhalten. Diese enthält die Container und Volumes, die zum Ausführen des Sidecar erforderlich sind.

Sidecar-Injektor

  1. Eine Webhook-Konfiguration wird während der Installation erstellt. Der Webhook wird beim Kubernetes API-Server registriert.
  2. Der Kubernetes API-Server überwacht Pod-Deployments in Namespaces, die dem Webhook namespaceSelector entsprechen.
  3. Ein Namespace ist mit einem Label versehen, das mit dem namespaceSelector übereinstimmen muss.
  4. Pods, die für den Namespace bereitgestellt werden, lösen den Webhook aus.
  5. Der von Istio bereitgestellte Dienst inject ändert die Pod-Spezifikationen, um die Sidecar-Datei automatisch einzufügen.

Was ist eine Überarbeitung?

Das für die automatische Injektion verwendete Label ist ein herkömmliches benutzerdefiniertes Kubernetes-Label. Ein Label ist im Wesentlichen ein Schlüssel/Wert-Paar, das zur Unterstützung des Konzept der Beschriftung. Labels werden häufig für Tagging und Überarbeitungen. z. B. Git-Tags, Docker-Tags und Knative-Überarbeitungen

Mit dem aktuellen Cloud Service Mesh-Installationsprozess können Sie die installierten Steuerungsebene mit einem Versionsstring. Das Installationsprogramm kennzeichnet jedes Objekt der Steuerungsebene mit der Überarbeitung. Der Schlüssel im Schlüssel/Wert-Paar ist istio.io/rev, aber der Wert des Überarbeitungslabels unterscheidet sich für die verwaltete Steuerungsebene und die clusterinternen Steuerungsebenen.

  • Bei Steuerungsebenen im Cluster werden der istiod-Dienst und das Deployment in der Regel haben ein Überarbeitungslabel ähnlich wie istio.io/rev=asm-1225-1, wobei asm-1225-1 identifiziert die Cloud Service Mesh-Version. Die Überarbeitung wird Teil des Dienstnamens, z. B. istiod-asm-1225-1.istio-system.

  • Für die von Google verwaltete Steuerungsebene entspricht das Überarbeitungslabel einer Release-Version:

    Überarbeitungslabel Kanal
    istio.io/rev=asm-managed Regulär
    istio.io/rev=asm-managed-rapid Rapid
    istio.io/rev=asm-managed-stable Stabile Version

Darüber hinaus haben Sie die Möglichkeit, Standard-Injektionslabels zu verwenden (z. B. istio-injection=enabled).

Wenn Sie die automatische Injektion aktivieren möchten, fügen Sie Ihren Namespaces ein Überarbeitungslabel hinzu, das mit dem Überarbeitungslabel auf der Steuerungsebene übereinstimmt. Beispiel: Eine Steuerungsebene mit der Überarbeitung istio.io/rev=asm-1225-1 wählt Pods in Namespaces mit dem Label istio.io/rev=asm-1225-1 aus und fügt Sidecars ein.

Canary-Upgrade

Überarbeitungslabels ermöglichen Canary-Upgrades und einfache Rollbacks der Steuerungsebene im Cluster. Die verwaltete Steuerung verwendet einen ähnlichen Prozess, aber der Cluster wird automatisch auf die neueste Version innerhalb dieser Version aktualisiert.

Canary-Upgrade

Im Folgenden wird beschrieben, wie der Vorgang funktioniert:

  1. Mit einem vorhandenen Cloud Service Mesh oder Open-Source-Istio beginnen Installation. Es spielt dabei keine Rolle, ob die Namespaces ein Überarbeitungslabel oder das Label istio-injection=enabled verwenden.
  2. Verwenden Sie einen Überarbeitungsstring, wenn Sie die neue Version der Steuerungsebene installieren. Durch den Überarbeitungsstring wird die neue Steuerungsebene zusätzlich zur vorhandenen Version installiert. Die neue Installation enthält eine neue Webhook-Konfiguration mit einem namespaceSelector, das nach Namespaces mit diesem speziellen Überarbeitungslabel sucht.
  3. Sie migrieren die Sidecar-Proxys zur neuen Steuerungsebene. Entfernen Sie dazu das alte Label aus dem Namespace, fügen Sie das neue Überarbeitungslabel hinzu und starten Sie die Pods dann neu. Wenn Sie Überarbeitungen mit Cloud Service Mesh verwenden, müssen Sie die Verwendung des Labels istio-injection=enabled einstellen. Eine Steuerungsebene mit einer Überarbeitung wählt keine Pods in Namespaces mit dem Label istio-injection aus, selbst wenn es ein Überarbeitungslabel gibt. Der Webhook für die neue Steuerungsebene fügt Sidecars in die Pods ein.
  4. Testen Sie die Arbeitslasten sorgfältig, die der aktualisierten Steuerungsebene zugeordnet sind, und führen Sie entweder das Upgrade fort oder führen Sie ein Rollback zur ursprünglichen Steuerungsebene aus.

Nach dem Zuordnen der Pods zur neuen Steuerungsebene sind die vorhandene Steuerungsebene und der Webhook weiterhin installiert. Der alte Webhook hat keine Auswirkungen auf Pods in Namespaces, die in die neue Steuerungsebene migriert wurden. Sie können die Pods in einem Namespace auf die ursprüngliche Steuerungsebene zurücksetzen. Dazu entfernen Sie das neue Überarbeitungslabel, fügen das ursprüngliche Label wieder hinzu und starten die Pods neu. Wenn Sie sicher sind, dass das Upgrade abgeschlossen ist, können Sie die alte Steuerungsebene entfernen.

Eine ausführliche Anleitung für das Upgrade mit Überarbeitungen finden Sie im Upgrade-Leitfaden.

Details zur Änderung der Webhook-Konfiguration

Untersuchen Sie die Konfiguration selbst, um den mutierenden Webhook für die automatische Sidecar-Einschleusung besser zu verstehen. Verwenden Sie den folgenden Befehl:

kubectl -n istio-system get mutatingwebhookconfiguration -l app=sidecar-injector -o yaml

Es sollte eine separate Konfiguration für jede installierte Steuerungsebene angezeigt werden. Ein Namespace-Selektor für eine überarbeitete Steuerungsebene sieht so aus:

 namespaceSelector:
    matchExpressions:
    - key: istio-injection
      operator: DoesNotExist
    - key: istio.io/rev
      operator: In
      values:
      - asm-1225-1

Der Selektor kann je nach Version von Cloud Service Mesh oder Istio unterschiedlich sein. Dieser Selektor gleicht Namespaces mit einem bestimmten Überarbeitungslabel ab, sofern sie nicht auch das Label istio-injection haben.

Wenn ein Pod in einem Namespace bereitgestellt wird, der mit dem Selektor übereinstimmt, wird seine Pod-Spezifikation zur Veränderung an den Injektordienst gesendet. Der aufzurufende Injektordienst wird so angegeben:

     service:
        name: istiod-asm-1225-1
        namespace: istio-system
        path: /inject
        port: 443

Der Dienst wird von der Steuerungsebene an Port 443 unter dem URL-Pfad inject bereitgestellt.

Der Abschnitt rules gibt an, dass der Webhook auf die Pod-Erstellung angewendet werden soll:

   rules:
    - apiGroups:
      - ""
      apiVersions:
      - v1
      operations:
      - CREATE
      resources:
      - pods
      scope: '*'

Nächste Schritte