Releasekanäle von Managed Cloud Service Mesh

Cloud Service Mesh veröffentlicht häufig Updates, um Sicherheitsupdates bereitzustellen, bekannten Problemen und neue Funktionen. Guthaben der Release-Versionen zwischen der Cloud Service Mesh-Version. Cloud-Service-Mesh Release-Kanäle sind mit GKE-Release-Versionen (Google Kubernetes Engine) Google verwaltet automatisch die Version und den Aktualisierungsrhythmus für jeden Release Kanal.

In diesem Dokument werden die Release-Versionen verglichen und es wird erklärt, wie Sie Updates nicht verwalteten Proxys.

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 der 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 Tests, neuere Cloud Service Mesh-Versionen und APIs in Vorproduktionsumgebungen.
Regulär Rapid wird zu Regular* hochgestuft. Zugriff auf Cloud Service Mesh- und Istio-Features in angemessener Zeit, nachdem sie aber in einer Version, die seit längerer Zeit qualifiziert ist, . 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. Um über die fügen Sie die URL der Versionshinweise zum Cloud Service Mesh unter Feedreader öffnen oder die Feed-URL direkt hinzufügen: https://cloud.google.com/feeds/servicemesh-release-notes.xml

Wenn eine Nebenversion des verwalteten Cloud Service Mesh ausreichend genutzt und im Rapid Channel nachgewiesen, wird er zum regulären Kanal Kanal. 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. Neues Cloud Service Mesh Versionen werden zuerst im Rapid Channel veröffentlicht und im Laufe der Zeit zu Regular und Stable Channel. 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 die Einstellung GKE-Cluster-Channel später, dann behalten Sie die ursprüngliche Cloud Service Mesh-Kanal.

Die folgende Tabelle zeigt die Zuordnung der aktuellen Version zu Cloud Service Mesh:

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

Standardkanal

In einem neu installierten Cloud Service Mesh mit einem einzelnen verwalteten Kanal in einem Cluster installiert ist, ist dieser Kanal der Standardkanal für diese Cluster.

Wenn Cluster mit einer vorhandenen Istio- oder Cloud Service Mesh-Installation die Standard-Tag konfiguriert ist, muss es auf die verwaltete Version verweisen. Andernfalls ist keine Bearbeitung erforderlich.

Sie können das Label istio-injection=enabled als Alias verwenden, der auf Einfügen in die anderen Labels, die Sie für den Kanal verwenden, Standardversion. 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, Namespace muss mit einem Label gekennzeichnet sein, das dem installierten Kanal entspricht. Managed 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-Injection-Label (z. B. istio-injection=enabled), entspricht dem Standardkanal für diesen Cluster. 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