Überarbeitungen der Cloud Service Mesh-Steuerungsebene

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

Die Installation von Cloud Service Mesh besteht aus zwei Hauptphasen:

1. Installieren Sie zuerst mit dem asmcli-Tool eine clusterinterne 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 (Trafficsteuerungsebene) 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 geringes Risiko für das Rollback eingehen. Dieses Verfahren wird als Canary-Release bezeichnet und reduziert das Risiko bei neuen Bereitstellungen.

Hinweis: Ein alternativer Upgradetyp ist ein direktes Upgrade. Bei diesem Upgrade wird eine neue Version der Steuerungsebene installiert. Die neue Version der Steuerungsebene ersetzt sofort die alte Version. Direkte Upgrades sind riskant, da ein Rollback schwierig sein kann. Um die Proxys wieder einzufügen und mit der neuen Version der Steuerungsebene zu kommunizieren, mussten Sie alle Arbeitslasten in allen Namespaces neu starten. Je nach Anzahl der Arbeitslasten und Namespaces in Ihrem Mesh-Netzwerk könnte der gesamte Upgradeprozess eine Stunde oder länger dauern. Direkte Upgrades können zu Ausfallzeiten führen und sollten in Wartungsfenstern geplant werden.

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 ein Rollback ausführen und dafür die Arbeitslasten der ursprünglichen Steuerungsebene zuordnen.

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.

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, mit dem das Konzept des Taggings unterstützt wird. Labels werden häufig für das Tagging und für Überarbeitungen verwendet. Beispiele: Git-Tags, Docker-Tags und Knative-Überarbeitungen.

Beim aktuellen Cloud Service Mesh-Installationsprozess können Sie die installierte Steuerungsebene mit einem Überarbeitungsstring taggen. Das Installationsprogramm kennzeichnet jedes Objekt der Steuerungsebene mit der Überarbeitung. Der Schlüssel im Schlüssel/Wert-Paar ist istio.io/rev. Bei clusterinternen Steuerungsebenen haben der istiod-Dienst und das Deployment in der Regel ein Überarbeitungslabel ähnlich wie istio.io/rev=asm-1233-2, wobei asm-1233-2 die Cloud Service Mesh-Version identifiziert. Die Überarbeitung wird Teil des Dienstnamens, z. B. istiod-asm-1233-2.istio-system.

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-1233-2 wählt Pods in Namespaces mit dem Label istio.io/rev=asm-1233-2 aus und fügt Sidecars ein.

Canary-Upgrade

Überarbeitungslabels ermöglichen Canary-Upgrades und Rollbacks der Steuerungsebene im Cluster.

Im Folgenden wird beschrieben, wie der Vorgang funktioniert:

1. Beginnen Sie mit einer vorhandenen Cloud Service Mesh- oder Open-Source-Installation von Istio. 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.

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-1233-2

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-1233-2
        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: '*'