Überarbeitungen der Anthos 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. Bis Version 1.6.8 hat der Standardinstallationsvorgang für Anthos Service Mesh keine Überarbeitungen der Steuerungsebene verwendet. Die Einführung von Überarbeitungen erfordert möglicherweise etwas Aufwand und Änderungen an Ihren Installationsverfahrenn. Wir empfehlen jedoch dringend, diese Funktion zu verwenden, da sie erhebliche Vorteile mit sich bringt.

Grundlagen von Service Mesh

Die Installation von Anthos Service Mesh besteht aus zwei Hauptteilen: Zuerst verwenden Sie das istioctl-Befehlszeilentool oder das install_asm-Skript zum Installieren einer clusterinternen Steuerungsebene oder konfigurieren die von Google verwaltete Steuerungsebene. Die Steuerungsebene besteht aus einer Reihe von Systemdiensten, die für die Verwaltung der Mesh-Netzwerk-Konfiguration zuständig sind. 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.

Wenn Sie vor der Version Anthos Service Mesh 1.6 ein Upgrade ausgeführt haben, wurde eine neue Version der Steuerungsebene installiert, durch die die alte Version sofort ersetzt wurde. Dieses Verfahren wird als direktes Upgrade bezeichnet und ist riskant, weil es bei Fehlern zu einem Rollback kommen 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 konnte der gesamte Upgradeprozess eine Stunde oder länger dauern. Direkte Upgrades können zu Ausfallzeiten führen und sollten in Wartungsfenstern geplant werden.

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.

Ebenso können Sie das Risiko minimieren, das mit der Aktualisierung des Service Mesh selbst einhergeht. Anthos Service Mesh 1.6 und höher unterstützt Canary-Upgrades mithilfe von Überarbeitungen der Steuerungsebene. Mit einem Canary-Upgrade installieren Sie eine neue, 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 mit der neuen Überarbeitung der Steuerungsebene. Nachdem Sie einen Namespace mit der neuen Überarbeitung benannt haben, starten Sie die Arbeitslast-Pods neu, damit neue Sidecars 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.

1. Die 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 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, z. B. Git-Tags, Docker-Tags und Knative-Überarbeitungen.

Bis zu Anthos Service Mesh Version 1.6.8 haben die Standardinstallationsverfahren eine Konvention für die Konfiguration des Namespace-Selektoren im Webhook eingerichtet, die das Label istio-injection=enabled verwendete.

Beim aktuellen Anthos 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, aber der Wert des Überarbeitungslabels unterscheidet sich für die von Google verwaltete Steuerungsebene und die clusterinternen Steuerungsebenen.

• Bei clusterinternen Steuerungsebenen haben der istiod-Service und das Deployment in der Regel ein Überarbeitungslabel ähnlich wie istio.io/rev=asm-198-6, wobei asm-198-6 die Anthos Service Mesh-Version identifiziert. Die Überarbeitung wird Teil des Dienstnamens, z. B. istiod-asm-198-6.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

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

Canary-Upgrade

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

Im Folgenden wird beschrieben, wie der Vorgang funktioniert:

1. Beginnen Sie mit einer vorhandenen Anthos 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 Anthos 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 in den Upgrade-Leitfäden.

Details zur Änderung der Webhook-Konfiguration

Die beste Methode, den Webhook für die automatische Sidecar-Injektion zu verstehen, besteht darin, die Konfiguration selbst anzusehen. 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-173-6

Der Selektor kann je nach Version von Anthos 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-173-6
        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: '*'

Fazit

Die Verwendung von Überarbeitungslabels in Ihren Namespaces zum Aktivieren der automatischen Injektion mag zwar etwas gewöhnungsbedürftig sein, sie lohnt sich aber um so mehr für die Bereitstellung sicherer Canary-Upgrades.

Nächste Schritte

• Installationsanleitungen
• Sidecar-Proxys einfügen