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 Hauptelementen, die in der Regel mit dem install_asm-Skript automatisiert werden. Verwenden Sie zuerst das istioctl-Befehlszeilentool und die IstioOperator-YAML-Dateien, um die Steuerungsebene und ihre Konfiguration zu installieren. Die Steuerungsebene (auch als istiod bezeichnet) besteht aus einer Reihe von Systemdiensten, die für die Verwaltung der Mesh-Konfiguration zuständig sind. Als Nächstes stellen Sie einen speziellen Sidecar-Proxy in Ihrer Umgebung bereit, der die Netzwerkkommunikation mit 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.
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 Istio 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.
- Die Webhook-Konfiguration wird während der Installation erstellt. Der Webhook wird beim Kubernetes API-Server registriert.
- Der Kubernetes API-Server überwacht Pod-Deployments in Namespaces, die dem Webhook
namespaceSelectorentsprechen. - Ein Namespace ist mit einem Label versehen, das mit dem
namespaceSelectorübereinstimmen muss. - Pods, die für den Namespace bereitgestellt werden, lösen den Webhook aus.
- 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.
Bei der aktuellen Installation von Anthos Service Mesh können Sie die installierte Steuerungsebene mit einem Überarbeitungsstring taggen, sowohl als revision-Argument in istioctl-Befehlen als auch als Feld in der benutzerdefinierten IstioOperator-Ressource. Das Installationsprogramm benennt jedes Steuerungsebenenobjekt mit der Überarbeitung, einschließlich istiod-Dienst und Deployment. Die Überarbeitung wird Teil des Dienstnamens, z. B. istiod-asm-173-6.istio-system.
Der entsprechende Labelschlüssel für Namespaces ist istio.io/rev und mit dem Wert wird in der Regel die Version des Mesh-Netzwerks angegeben. Beispiel: Eine Steuerungsebene mit der Überarbeitung asm-173-6 wählt Pods in Namespaces mit dem Label istio.io/rev=asm-173-6 aus und fügt Sidecars ein.
Canary-Upgrade
Überarbeitungslabels ermöglichen die Durchführung von Canary-Upgrades und einfachen Rollbacks der Steuerungsebene.
Im Folgenden wird beschrieben, wie der Vorgang funktioniert:
- 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=enabledverwenden. - 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. - 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=enabledeinstellen. Eine Steuerungsebene mit einer Überarbeitung wählt keine Pods in Namespaces mit dem Labelistio-injectionaus, selbst wenn es ein Überarbeitungslabel gibt. Der Webhook für die neue Steuerungsebene fügt Sidecars in die Pods ein. - 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 istiod an Port 443 unter der URL 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.