Releasekanäle von Managed Cloud Service Mesh

Cloud Service Mesh veröffentlicht häufig Updates, um Sicherheitsupdates bereitzustellen, bekannten Problemen und neue Funktionen. Release-Versionen bieten die Möglichkeit, ein Gleichgewicht zwischen Stabilität und dem Feature-Set der Cloud Service Mesh-Version zu finden. Cloud Service Mesh-Release-Versionen sind an Google Kubernetes Engine (GKE)-Release-Versionen gebunden. Google verwaltet automatisch die Version und den Aktualisierungsrhythmus für jeden Release Kanal.

In diesem Dokument werden Vergleiche von Release-Kanälen 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 Cloud Service Mesh Attribute
Rapid Nach jedem Cloud Service Mesh-Release Holen Sie sich so früh wie möglich die neueste Cloud Service Mesh-Version. können neue Funktionen sofort nutzen, sobald sie in einer Veröffentlichung 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 Cloud Service Mesh-Versionen und APIs in Vorproduktionsumgebungen.
Regulär Rapid wird zu Regular* hochgestuft. Greifen Sie auf Cloud 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 Cloud 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 Cloud 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 Cloud 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 Cloud Service Mesh-Kanal Ihres Clusters wird durch seine GKE bestimmt Clusterkanal.

GKE-Kanal Cloud Service Mesh-Kanal
Rapid Rapid
Regulär Regulär
Stabile Version Stabile Version
(kein Kanal) Regulär

Cloud Service Mesh-Versionen pro Kanal

Ihr Cloud Service Mesh-Kanal wird von Ihrem GKE-Cluster bestimmt Kanal zum Zeitpunkt der Bereitstellung des verwalteten Cloud Service Mesh. Wenn Sie den GKE-Clusterkanal später ändern, bleibt der ursprüngliche Cloud Service Mesh-Kanal erhalten.

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

Kanal Cloud Service Mesh-Version
Rapid 1.19
Regulär 1.19
Stabile Version 1.18

Standardkanal

In einem neu installierten Cloud 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 Cloud 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 Cloud Service Mesh die Arbeitslasten in einem bestimmten Namespace verwalten kann, muss der Namespace mit einem Label versehen werden, das dem installierten Kanal entspricht. Verwaltetes Cloud 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. Wenn beispielsweise Migration von Istio OSS oder von nicht verwalteten Cloud Service Mesh zum verwalteten Cloud Service Mesh, da keine weisen Sie jedem Namespace ein individuelles Label zu. Wo in der Cloud Service Mesh-Dokumentation angezeigt wird das Namespace-Label istio.io/rev für die Injektion zu verwenden, ist es möglich, das Label istio-injection=enabled.

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 Cloud Service Mesh-Release die nicht verwalteten Proxys für Ihre und Gateways. Obwohl das Service Mesh in Ordnung ist, die Steuerungsebene und die Proxys unterschiedliche Versionen haben, empfehlen wir, Proxys aktualisieren, sodass sie mit dem neuen Cloud Service Mesh konfiguriert sind Version.

  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