Verwaltete Anthos Service Mesh-Release-Versionen

Anthos Service Mesh veröffentlicht häufig Updates, um Sicherheitsupdates bereitzustellen, bekannte Probleme zu beheben und neue Features einzuführen. Releasekanäle sind ein Gleichgewicht zwischen der Stabilität und dem Feature-Set der Anthos Service Mesh-Version. Anthos Service Mesh-Release-Versionen sind mit den GKE-Release-Versionen (Google Kubernetes Engine) verknüpft. Google verwaltet automatisch den Versions- und Upgraderhythmus für jede Release-Version.

In diesem Dokument werden Vergleiche von Release-Versionen und die Aktualisierung nicht verwalteter Proxys beschrieben.

Verfügbare Release-Versionen

Die folgenden Releasekanäle sind verfügbar. Jeder Kanal bietet einen Kompromiss zwischen der Verfügbarkeit von Funktionen und der Aktualisierung von Abwanderungen. Die Features in den einzelnen Versionen haben unterschiedliche Reifestufen. Alle Releasekanäle erhalten wichtige Sicherheitspatches, um Ihre Cluster und die Infrastruktur von Google zu schützen.

Channel Verfügbarkeit des neuen verwalteten Anthos Service Mesh Attribute
Rapid Nach jedem Anthos Service Mesh-Release Laden Sie den neuesten Anthos Service Mesh-Release so früh wie möglich herunter und nutzen Sie neue Features, sobald sie in einem Release enthalten sind. Ihre Steuerungsebene wird häufig aktualisiert, um auf der neuesten verfügbaren Patchversion zu bleiben, und bietet neuere Funktionen. Der Rapid Channel eignet sich am besten für das Testen neuer Anthos Service Mesh-Versionen und APIs in Vorproduktionsumgebungen.
Regular Rapid wird zu Regular* hochgestuft. Greifen Sie auf Anthos Service Mesh- und Istio-Features kurz nach ihrer Einführung zu, jedoch in einer Version, die über einen längeren Zeitraum qualifiziert war. Bietet ein Gleichgewicht von Feature-Verfügbarkeit und Release-Stabilität. Dieses Vorgehen wird für die meisten Nutzer empfohlen.
Stabile Version Regular wird zu Stable* hochgestuft. Stabilität hat Vorrang vor neuen Features. Änderungen und neue Versionen in dieser Version werden zuletzt eingeführt, nachdem sie in den Versionen „Rapid“ und „Regular“ validiert wurden. Dadurch bleibt noch mehr Zeit für die Validierung.
* Der Hochstufungszeitplan für die nächste Version hängt von mehreren Faktoren ab, einschließlich des Open-Source-Istio-Release, des Anthos-Release und des Patching-Zeitplans. Daher kann er Änderungen unterworfen sein. Fügen Sie die URL der Anthos Service Mesh-Versionshinweise in den Feedreader ein oder fügen Sie die Feed-URL direkt hinzu, um über die neuesten Informationen auf dem Laufenden zu bleiben: https://cloud.google.com/feeds/servicemesh-release-notes.xml.

Wenn eine Nebenversion des verwalteten Anthos Service Mesh über ausreichende Nutzung und hohe Stabilität im Rapid Channel verfügt, wird sie zum Regular Channel hochgestuft. Schließlich wird die Nebenversion zum Stable Channel hochgestuft, der nur Updates mit hoher Priorität und Sicherheitspatches erhält. Jede Hochstufung signalisiert ein abgestuftes Maß an Stabilität und Produktionsbereitschaft, basierend auf der beobachteten Leistung der Steuerungsebene, auf der diese Version ausgeführt wird.

Alle Versionen basieren auf einem allgemein verfügbaren Release (GA-Release). Einzelne Features sind wie angegeben jedoch nicht immer allgemein verfügbar. Neue Anthos Service Mesh-Versionen werden zuerst im Rapid Channel veröffentlicht und im Laufe der Zeit zum Regular Channel und Stable Channel hochgestuft. So können Sie einen Kanal auswählen, der Ihren geschäftlichen, stabilitätsbezogenen und funktionalen Anforderungen entspricht.

Der Anthos Service Mesh-Kanal Ihres Clusters wird durch seinen GKE-Clusterkanal bestimmt.

GKE-Kanal Anthos Service Mesh-Kanal
Schnell Schnell
Regulär Regulär
Stabil Stabil
(kein Kanal) Regulär

Anthos Service Mesh-Versionen pro Version

Ihr Anthos Service Mesh-Kanal wird zum Zeitpunkt der Bereitstellung des verwalteten Anthos Service Mesh durch Ihren GKE-Clusterkanal bestimmt. Wenn Sie den GKE-Clusterkanal später ändern, behalten Sie den ursprünglichen Anthos Service Mesh-Kanal bei.

Die folgende Tabelle zeigt die Zuordnung des aktuellen Kanals zur Anthos Service Mesh-Version:

Channel Anthos Service Mesh-Version
Rapid 1.19
Regulär 1.19
Stabil 1.19

Standardkanal

In einem neu installierten Anthos Service Mesh, in dem ein einzelner verwalteter Kanal in einem Cluster installiert ist, ist dieser Kanal der Standardkanal für diesen Cluster.

Wenn bei Clustern mit einer vorhandenen Istio- oder Anthos Service Mesh-Installation das Standard-Tag konfiguriert ist, muss es auf die verwaltete Überarbeitung verweisen. Andernfalls ist keine Bearbeitung erforderlich.

Sie können das Label istio-injection=enabled als Alias verwenden, der die Injektion auf die anderen Labels verweist, die Sie für den Kanal verwenden, z. B. die Standardüberarbeitung. Wenn in unserer Dokumentation das Namespace-Label istio.io/rev für die Injektion verwendet wird, kann stattdessen das Label istio-injection=enabled verwendet werden.

Injektionslabels

Damit Anthos Service Mesh die Arbeitslasten in einem bestimmten Namespace verwalten kann, muss der Namespace mit einem Label versehen werden, das dem installierten Kanal entspricht. Verwaltetes Anthos Service Mesh unterstützt zwei Arten von Labels:

  • Standard-Überarbeitungslabels, nämlich asm-managed-stable, asm-managed und asm-managed-rapid, die den Kanälen stable, regular und rapid entsprechen.
  • Standard-Injektionslabel (z. B. istio-injection=enabled), das dem Standardkanal für diesen Cluster entspricht. Das Standard-Inkjektionslabel vereinfacht die Migration zwischen Überarbeitungen. Zum Beispiel bei der Migration von Istio OSS oder von nicht verwaltetem Anthos Service Mesh zu verwaltetem Anthos Service Mesh, da nicht jeder Namespace einzeln mit einem Label versehen werden muss. Wenn in der Anthos Service Mesh-Dokumentation das Namespace-Label istio.io/rev für die Injektion verwendet wird, kann stattdessen das Label istio-injection=enabled verwendet werden.

Andere Beispiele für Injektionslabels sind das Labeling von Arbeitslasten mit sidecar.istio.io/inject (allgemein für Gateways verwendet) und istio.io/rev, die sowohl für Namespaces als auch für Arbeitslasten funktionieren.

Standard-Injektionslabels

So wenden Sie das Standard-Injektionslabel auf einen Namespace an:

kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite

Überarbeitungslabels

Wie andere Kubernetes-Labels ist ein Überarbeitungslabel ein Schlüssel/Wert-Paar. Der Schlüssel in einem Überarbeitungslabel ist immer istio.io/rev, aber der Wert variiert. Zur Auswahl einer Release-Version wenden Sie einen der folgenden Überarbeitungsnamen auf die Namespaces an:

Revisionsname Channel
asm-managed Regulär
asm-managed-rapid Rapid
asm-managed-stable Stabile Version

So wenden Sie beispielsweise die Release-Version "Regular" auf einen Namespace an:

kubectl label namespace NAMESPACE istio.io/rev=asm-managed --overwrite

Wir empfehlen, denselben Releasekanal wie der Cluster zu verwenden.

So sehen Sie, welche Release-Version ein Namespace verwendet:

kubectl get namespace NAMESPACE -o jsonpath='{.metadata.labels.istio\.io/rev}{"\n"}'

Nicht verwaltete Proxys aktualisieren

Starten Sie nach jedem Anthos Service Mesh-Release die nicht verwalteten Proxys für Ihre Dienste und Gateways neu. Das Service Mesh ist in Ordnung, wenn sich die Steuerungsebene und die Proxys in verschiedenen Versionen befinden. Wir empfehlen jedoch, die Proxys so zu aktualisieren, dass sie mit der neuen Anthos Service Mesh-Version konfiguriert werden.

  1. Prüfen Sie die Steuerungsebene und Proxyversion.

  2. Wenn die Version der Steuerungsebene neuer als die Proxyversion ist, starten Sie die nicht verwalteten Proxys für Ihre Dienste und Gateways neu.

    kubectl rollout restart deployment -n NAMESPACE