Canali di rilascio di Cloud Service Mesh gestito
Google CloudCloud Service Mesh rilascia spesso aggiornamenti per fornire aggiornamenti della sicurezza, correggere problemi noti e introdurre nuove funzionalità. I canali di rilascio trovano un equilibrio tra la stabilità e il set di funzionalità della versione di Cloud Service Mesh. I canali di rilascio di Cloud Service Mesh sono collegati ai canali di rilascio di Google Kubernetes Engine (GKE). Google gestisce automaticamente la versione e la cadenza di upgrade per ogni canale di rilascio.
Questo documento illustra i confronti tra i canali di rilascio e come aggiornare i proxy non gestiti.
Canali di rilascio disponibili
Sono disponibili i seguenti canali di rilascio. Ogni canale offre un compromesso tra la disponibilità delle funzionalità e la frequenza degli aggiornamenti. Le funzionalità di ogni canale hanno un livello di maturità diverso. Le patch di sicurezza critiche vengono distribuite a tutti i canali di rilascio per proteggere i cluster e l'infrastruttura di Google.
| Canale | Nuova disponibilità di Cloud Service Mesh gestito | Proprietà |
|---|---|---|
| Rapido | Dopo ogni rilascio di Cloud Service Mesh | Ottieni l'ultima release di Cloud Service Mesh il prima possibile e potrai utilizzare le nuove funzionalità non appena vengono incluse in una release. Il control plane viene aggiornato di frequente per rimanere alla versione patch più recente disponibile e fornire funzionalità più recenti. Il canale rapido è ideale per testare le versioni e le API più recenti di Cloud Service Mesh su ambienti di pre-produzione. |
| Normale | Il canale rapido viene promosso a normale* | Accedi alle funzionalità di Cloud Service Mesh e Istio in tempi ragionevolmente rapidi dopo il lancio, ma su una versione che è stata qualificata per un periodo di tempo più lungo. Offre un buon compromesso tra disponibilità di funzionalità e stabilità di release ed è l'opzione che consigliamo alla maggior parte degli utenti. |
| Stabile | Il canale normale viene promosso a stabile* | Dai priorità alla stabilità rispetto alle nuove funzionalità. Le modifiche e le nuove versioni in questo canale vengono implementate per ultime, dopo essere state convalidate nei canali rapido e normale, dedicando ancora più tempo alla convalida. |
*La pianificazione della promozione al canale successivo dipende da diversi fattori, tra cui la release di Istio open source, la release di Anthos e la pianificazione delle patch, pertanto è soggetta a modifiche. Per rimanere aggiornato con le
ultime informazioni, aggiungi l'URL delle note di rilascio di Cloud Service Mesh al
tuo lettore di feed o aggiungi direttamente l'URL del feed:
https://cloud.google.com/feeds/servicemesh-release-notes.xml
|
||
Quando una versione secondaria di Cloud Service Mesh gestito ha un utilizzo sufficiente e una stabilità dimostrata nel canale rapido, viene promossa al canale normale. Alla fine, la versione secondaria viene promossa al canale stabile, che riceve solo aggiornamenti e patch di sicurezza ad alta priorità. Ogni promozione indica un livello di stabilità e preparazione alla produzione crescente, in base alle prestazioni osservate del control plane che esegue quella versione.
Tutti i canali sono basati su una release in disponibilità generale (GA), anche se le singole funzionalità potrebbero non essere sempre in GA, come indicato. Le nuove versioni di Cloud Service Mesh vengono rilasciate prima nel canale rapido e, nel tempo, vengono promosse al canale normale e stabile. In questo modo, puoi selezionare un canale che soddisfi le esigenze della tua attività, di stabilità e di funzionalità.
Il canale Cloud Service Mesh del cluster è determinato dal canale del cluster GKE.
| Canale GKE | Canale Cloud Service Mesh |
|---|---|
| Rapido | Rapido |
| Normale | Normale |
| Stabile | Stabile |
| (nessun canale) | Normale |
Versioni di Cloud Service Mesh per canale
Il canale Cloud Service Mesh viene determinato dal canale del cluster GKE al momento del provisioning di Cloud Service Mesh gestito. Se in un secondo momento modifichi il canale del cluster GKE, mantieni il canale Cloud Service Mesh originale.
La tabella seguente mostra il mapping corrente tra canale e versione di Cloud Service Mesh:
| Canale | Versione di Cloud Service Mesh |
|---|---|
| Rapido | 1.21 |
| Normale | 1.20 |
| Stabile | 1.19 |
Canale predefinito
In un'installazione di Cloud Service Mesh appena eseguita in cui è installato un singolo canale gestito in un cluster, questo canale sarà il canale predefinito per quel cluster.
Se i cluster con un'installazione esistente di Istio o Cloud Service Mesh hanno configurato il tag predefinito, questo deve puntare alla revisione gestita. In caso contrario, non è necessario alcun intervento.
Puoi utilizzare l'etichetta istio-injection=enabled come alias che indirizza l'inserimento alle altre etichette utilizzate per il canale, ad esempio la revisione predefinita. Ovunque la nostra documentazione indichi di utilizzare l'etichetta dello spazio dei nomi istio.io/rev per l'inserimento, è possibile utilizzare invece l'etichetta istio-injection=enabled.
Etichette di inserimento
Per consentire a Cloud Service Mesh di gestire i workload in un determinato spazio dei nomi, lo spazio dei nomi deve essere etichettato con un'etichetta corrispondente al canale installato. Cloud Service Mesh gestito supporta due tipi di etichette:
- Etichette di revisione standard ,
ovvero
asm-managed-stable,asm-managed,asm-managed-rapid, corrispondenti ai canalistable,regular, erapid. - Etichetta di inserimento predefinita
(ad esempio,
istio-injection=enabled), corrispondente al canale predefinito per quel cluster. L'utilizzo dell'etichetta di inserimento predefinita semplifica la migrazione tra le revisioni. Ad esempio, quando esegui la migrazione da Istio OSS o da Cloud Service Mesh non gestito a Cloud Service Mesh gestito, non è necessario rietichettare ogni spazio dei nomi singolarmente. Ovunque la documentazione di Cloud Service Mesh indichi di utilizzare l'etichetta dello spazio dei nomiistio.io/revper l'inserimento, è possibile utilizzare invece l'etichettaistio-injection=enabled.
Altri esempi di etichette di inserimento includono l'etichettatura dei workload con sidecar.istio.io/inject (comunemente utilizzata per i gateway) e istio.io/rev, che funziona sia per gli spazi dei nomi sia per i workload.
Etichette di inserimento predefinite
Per applicare l'etichetta di inserimento predefinita a uno spazio dei nomi:
kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite
Etichette di revisione
Come le altre etichette di Kubernetes, un'etichetta di revisione è una coppia chiave-valore.
La chiave in un'etichetta di revisione è sempre istio.io/rev, ma il valore varia.
Per selezionare un canale di rilascio, applica uno dei seguenti nomi di revisione agli spazi dei nomi:
| Nome revisione | Canale |
|---|---|
asm-managed |
Regolare |
asm-managed-rapid |
Rapido |
asm-managed-stable |
Stabile |
Ad esempio, per applicare il canale di rilascio normale a uno spazio dei nomi:
kubectl label namespace NAMESPACE istio.io/rev=asm-managed --overwrite
Ti consigliamo di utilizzare lo stesso canale di rilascio utilizzato dal cluster.
Per vedere quale canale di rilascio utilizza uno spazio dei nomi:
kubectl get namespace NAMESPACE -o jsonpath='{.metadata.labels.istio\.io/rev}{"\n"}'
Aggiorna i proxy non gestiti
Dopo ogni rilascio di Cloud Service Mesh, riavvia i proxy non gestiti per i servizi e i gateway. Sebbene il mesh di servizi funzioni correttamente quando il control plane e i proxy hanno versioni diverse, ti consigliamo di aggiornare i proxy in modo che siano configurati con la nuova versione di Cloud Service Mesh.
Controlla la versione del control plane e del proxy.
Se la versione del control plane è più recente della versione del proxy, riavvia i proxy non gestiti per i servizi e i gateway.
kubectl rollout restart deployment -n NAMESPACE