Informazioni sui canali di rilascio

Utilizza i canali di rilascio per Google Kubernetes Engine (GKE) per scegliere le versioni dei tuoi cluster per bilanciare la disponibilità e la stabilità delle funzionalità.

GKE esegue automaticamente l'upgrade di tutti i cluster nel tempo, inclusi quelli non registrati in un canale di rilascio, per garantire che ricevano aggiornamenti della sicurezza, correzioni di problemi noti, nuove funzionalità ed eseguano una versione di Kubernetes supportata. Puoi controllare la tempistica degli upgrade con periodi di manutenzione ed esclusioni.

Ti consigliamo di registrare il cluster in un canale di rilascio, in quanto questo ti offre il massimo controllo per quanto riguarda l'ambito delle esclusioni di manutenzione, impedendo tipi specifici di upgrade anziché tutti gli upgrade, e la sequenza dell'implementazione degli upgrade del cluster. I cluster Autopilot possono essere registrati solo in un canale di rilascio.

Se non registri il cluster Standard in un canale di rilascio, tutti i control plane dei cluster vengono comunque aggiornati automaticamente e, quando una versione raggiunge la fine del supporto, i control plane e i nodi del cluster vengono aggiornati automaticamente indipendentemente dalla registrazione al canale di rilascio. Per scoprire di più, consulta il confronto tra i cluster registrati e non registrati in un canale di rilascio.

Quali canali sono disponibili

La tabella seguente illustra le proprietà dei canali di rilascio disponibili, ognuno dei quali offre un compromesso tra disponibilità delle funzionalità e stabilità. Tutti i canali offrono versioni supportate di GKE e sono considerati in disponibilità generale (GA), anche se le singole funzionalità potrebbero non essere sempre GA, come indicato. Le release di Kubernetes in questi canali sono release ufficiali di Kubernetes e includono API Kubernetes GA e beta.

Canale Disponibilità della versione secondaria Imposta come destinazione di upgrade automatico Quando utilizzare questo canale
Rapido

1-2 settimane dopo la disponibilità generale dell'open source upstream

Le versioni patch alpha sono disponibili solo per i cluster alpha fino a quattro mesi prima che GKE renda la versione secondaria disponibile per tutti i cluster in Rapid.

 1-2 mesi dopo il rilascio su Rilascio rapido

Ricevi l'ultima release di Kubernetes il prima possibile e potrai utilizzare le nuove funzionalità di GKE non appena diventano disponibili a livello generale. GKE esegue l'upgrade del cluster di frequente per rimanere aggiornato con la versione patch più recente disponibile e fornire funzionalità di Kubernetes più recenti. I cluster iscritti al canale rapido utilizzano le versioni GA, ma ti consigliamo di utilizzare il canale rapido per testare le versioni e le API più recenti di Kubernetes su ambienti di pre-produzione.

Il canale rapido è consigliato per i cluster alpha, che abilitano tutti i feature gate delle funzionalità alpha di Kubernetes e le API alpha per i test. I cluster alpha nel canale rapido possono eseguire versioni patch alpha delle prossime versioni secondarie fino a quattro mesi prima che GKE renda disponibile la versione secondaria per tutti i cluster in Rapid.
Regolare (predefinito) Circa 2 mesi dopo il rilascio su Rapid Circa 3 mesi dopo il rilascio nel canale regolare Accedi alle funzionalità di GKE e Kubernetes subito dopo la loro disponibilità generale, ma su una versione qualificata per un periodo di tempo più lungo. Offre un giusto equilibrio tra la disponibilità delle funzionalità e la stabilità di rilascio ed è l'opzione che consigliamo alla maggior parte degli utenti.
Stabile 3-4 mesi dopo l'uscita, da Novità a Regolare Circa 2 mesi dopo il rilascio nel canale stabile Dai priorità alla stabilità rispetto alle nuove funzionalità. GKE implementa le modifiche e le nuove versioni in questo canale per ultimo, dopo averle convalidate nel canale rapido e in quello regolare, il che consente ancora più tempo per la convalida.
Esteso Allineato al canale regolare In linea con il canale regolare Utilizza questo canale per ricevere assistenza a lungo termine, mantenendo un cluster in esecuzione con una versione secondaria il più a lungo possibile. Per scoprire di più, consulta Ricevi assistenza a lungo termine con il canale Esteso.
Nessun canale (deprecato) In linea con il canale regolare In linea con il canale stabile L'upgrade automatico del control plane e dei nodi viene eseguito in linea con i canali Rapido e Stabile. Se devi disattivare gli upgrade automatici dei nodi a livello di pool di nodi, puoi utilizzare un canale di rilascio ed eseguire una delle seguenti operazioni: Per saperne di più su Nessun canale, consulta il confronto tra i cluster registrati e non registrati in un canale di rilascio.

Quando registri un cluster in un canale di rilascio, viene eseguito l'upgrade automatico del cluster a partire dalla data specificata nella colonna Upgrade automatico del programma di rilascio di GKE.

Quando una versione ha accumulato un utilizzo e dimostrato stabilità tra i cluster nel canale Rapido, viene promossa al canale Regolare. Alla fine, la versione viene promossa al canale Stabile, che riceve solo aggiornamenti ad alta priorità. Ogni promozione indica un livello crescente di stabilità e idoneità alla produzione, in base alle prestazioni osservate dei cluster che eseguono quella versione.

Le patch di sicurezza critiche vengono distribuite a tutti i canali di rilascio per proteggere i tuoi cluster e l'infrastruttura di Google. In rare situazioni di emergenza, GKE potrebbe eseguire l'upgrade automatico dei cluster a versioni non ancora disponibili nel relativo canale di rilascio.

Quali versioni sono disponibili in un canale

Ogni canale di rilascio offre più versioni secondarie. Queste versioni soddisfano gli standard di qualificazione per quel canale specifico. Questo insieme di versioni disponibili include una versione predefinita per la creazione del cluster, che viene selezionata da un insieme di versioni disponibili di quel canale. Per vedere quali versioni sono disponibili in un canale di rilascio, segui le istruzioni per visualizzare le versioni predefinite e disponibili per i canali di rilascio.

  • Le nuove versioni delle patch diventano disponibili nel seguente periodo di tempo:
    • Almeno una settimana prima di diventare un target di upgrade automatico nel rispettivo canale
    • Almeno due settimane dopo essere stato reso disponibile nel canale precedente
  • Le nuove versioni secondarie diventano disponibili nel seguente periodo di tempo:
    • Almeno quattro settimane prima di diventare un target di upgrade automatico nel canale rapido
    • Almeno otto settimane prima di diventare un target di upgrade automatico nei canali Regular e Stable

Se ti interessa testare le prossime versioni secondarie di Kubernetes, le versioni patch alpha diventano disponibili nel canale rapido fino a quattro mesi prima che GKE renda disponibile la versione secondaria a tutti i cluster nel canale rapido. Le versioni patch alpha sono esclusive dei cluster alpha.

Puoi testare una nuova versione di GKE disponibile prima di eseguire l'upgrade dell'ambiente di produzione. Ad esempio, puoi iscriverti alle notifiche di upgrade per ricevere informazioni sulle nuove versioni disponibili e poi eseguire l'upgrade proattivo di un ambiente di pre-produzione alla nuova versione prima che diventi la destinazione dell'upgrade automatico per i cluster nel tuo ambiente di produzione.

Se devi mantenere un cluster su una versione specifica, ad esempio per convalidare o testare le versioni più recenti prima dell'upgrade, ti consigliamo di utilizzare le esclusioni dalla manutenzione.

Una volta resa disponibile una versione secondaria in un canale di rilascio, questa rimarrà disponibile in quel canale per i cluster nuovi o esistenti fino al raggiungimento della data di fine del supporto.

Cosa succede quando una versione diventa un target di upgrade automatico in un canale di rilascio

GKE esegue automaticamente l'upgrade dei cluster nel tempo ai nuovi target di upgrade automatico. Quando sono disponibili nuovi target di upgrade automatico, GKE valuta se il tuo cluster specifico deve essere sottoposto all'upgrade a quella nuova versione. GKE considera se il tuo cluster ha policy di manutenzione o altri vincoli che impediscono gli upgrade automatici e non ignorerà questi motivi, tranne in rare situazioni di emergenza.

Puoi trovare le destinazioni di upgrade automatico per i tuoi cluster nei seguenti modi:

Se sono trascorsi 10 giorni da quando una nuova versione è diventata un target di upgrade automatico per la versione secondaria del tuo cluster nel canale di rilascio e gli upgrade automatici non sono stati avviati per il tuo cluster, il ritardo potrebbe essere dovuto a uno dei seguenti motivi:

  • Il tuo cluster non è temporaneamente idoneo per gli upgrade automatici. Ciò potrebbe verificarsi perché:
    • Il cluster non rientra nel periodo di un periodo di manutenzione configurato.
    • Il cluster rientra nel periodo di tempo di un'esclusione di manutenzione.
    • Gli upgrade automatici sono in pausa perché il tuo cluster utilizza funzionalità di Kubernetes deprecate che sono state rimosse nella versione secondaria successiva.
    • È stato eseguito l'upgrade automatico del cluster a una versione patch meno di 24 ore fa.
    • È stato eseguito l'upgrade automatico del cluster a una versione secondaria meno di 30 giorni fa e la destinazione dell'upgrade automatico è una nuova versione secondaria.
  • GKE ha messo in pausa l'implementazione del nuovo target di upgrade automatico per motivi tecnici o aziendali:
    • Sono stati rilevati problemi tecnici con la nuova versione.
    • È in vigore un blocco della produzione a causa di una stagione aziendale critica, ad esempio il Black Friday.

La destinazione di upgrade automatico consigliata è la versione a cui GKE esegue gradualmente l'upgrade dei cluster nel tempo. Tra tutti i target di upgrade automatico in un canale di rilascio, GKE avvicina i cluster a questa versione quando esegue gli upgrade automatici.

Nel corso di più upgrade automatici, salvo vincoli che li impediscono, GKE esegue l'upgrade dei cluster in modo progressivo fino a raggiungere il target di upgrade automatico consigliato del canale di rilascio. Una volta raggiunto il target, il cluster utilizza continuamente il target di upgrade automatico consigliato esistente e passa al nuovo target consigliato quando viene rilasciato.

Che cos'è la versione predefinita?

Quando crei un cluster in un canale di rilascio, per impostazione predefinita il cluster utilizza la versione patch predefinita per la creazione del cluster nel canale di rilascio selezionato. Tuttavia, puoi specificare una versione disponibile diversa quando crei un cluster nel canale di rilascio.

I canali di rilascio hanno più versioni secondarie disponibili in un canale di rilascio e la versione predefinita a volte può essere una delle destinazioni dell'upgrade automatico per un canale di rilascio.

Informazioni su come ottenere le versioni delle patch in anticipo

Puoi ottenere le versioni patch in anticipo con gli upgrade automatici o manuali utilizzando i metodi descritti in questa sezione.

Upgrade automatici delle patch accelerati

GKE introduce per prima una nuova versione patch in un canale di rilascio rendendola disponibile per la creazione di nuovi cluster e gli upgrade manuali. Dopo che GKE ha stabilito che la versione patch è qualificata, la imposta come target di upgrade automatico, il che significa che GKE inizia a eseguire automaticamente l'upgrade dei cluster a questa nuova versione patch. Il periodo di tempo che intercorre tra la disponibilità della versione e gli upgrade automatici è in genere di almeno una settimana, ma dipende dal canale di rilascio e dalle circostanze specifiche di qualificazione della versione.

Per ulteriori informazioni sulla disponibilità della versione attuale, procedi nel seguente modo:

Se vuoi ricevere gli upgrade delle patch non appena la versione è disponibile e prima che GKE imposti la versione come target dell'upgrade automatico nel canale, puoi utilizzare gli upgrade automatici delle patch accelerati. Questa impostazione può essere utile se vuoi ricevere le patch di sicurezza il prima possibile tramite gli upgrade automatici.

Devi comprendere i rischi associati all'upgrade automatico del cluster in base a una pianificazione accelerata prima che GKE determini che i cluster nel canale devono essere aggiornati automaticamente alla nuova versione della patch. Questa pianificazione accelerata salta un passaggio nella procedura di qualifica per le versioni patch nei canali di rilascio. Con questa pianificazione accelerata viene eseguito l'upgrade di tutte le versioni patch, non solo di quelle con patch di sicurezza. Questa impostazione non influisce sugli upgrade delle versioni secondarie ed è disponibile solo per i cluster registrati in un canale di rilascio.

Questa impostazione influisce solo sulla tempistica dell'upgrade automatico di GKE di un cluster a una nuova versione patch. GKE rispetta comunque i periodi di manutenzione e le esclusioni, segue l'ordine di una sequenza di implementazione e applica qualsiasi altra pratica standard in genere utilizzata per gli upgrade automatici.

Per maggiori informazioni sull'impostazione di questa funzionalità, vedi Utilizzare gli aggiornamenti automatici delle patch accelerati.

In alternativa, puoi eseguire manualmente l'upgrade dei cluster se vuoi eseguire l'upgrade a una versione patch specifica non appena è disponibile e prima che venga impostata come destinazione dell'upgrade automatico.

Esegui le versioni patch da un canale più recente

Oltre alle versioni patch disponibili elencate per un canale di rilascio, puoi eseguire versioni patch di canali di rilascio più recenti rispetto a quello in cui è registrato il tuo cluster se la versione secondaria è disponibile nel canale di rilascio del cluster e utilizzi gcloud CLI o l'API GKE.

Ad esempio, se le seguenti versioni fossero disponibili nei canali rapido e normale:

  • Rapido: 1.23.2-gke.700, 1.22.4-gke.1500
  • Regolare: 1.21.4-gke.400, 1.22.1-gke.400

Un cluster registrato nel canale regolare che esegue GKE versione 1.22.1-gke.400 potrebbe eseguire l'upgrade manualmente alla versione 1.22.4-gke.1500, ma non alla versione 1.23.2-gke.700, poiché si tratta di una versione secondaria diversa.

Per eseguire manualmente l'upgrade a una versione patch su un canale più recente, il control plane del cluster deve eseguire una release patch con la stessa versione secondaria. Ad esempio, se il cluster esegue la versione 1.21.3-gke.200, devi prima eseguire manualmente l'upgrade del cluster a una versione patch disponibile nel canale di rilascio attuale, 1.22.1-gke.400. Puoi quindi eseguire l'upgrade del cluster alla versione 1.22.4-gke.1500.

Puoi anche creare un nuovo cluster che esegue la versione 1.22.4-gke.1500 e registrato al canale regolare.

GKE mantiene il cluster sulla versione patch del canale più recente finché non diventa disponibile un target di upgrade automatico più recente nel canale registrato per il cluster.

Scopri le novità di un canale

Per scoprire le novità di un canale di rilascio, consulta le note di rilascio. Esistono note di rilascio separate per ogni canale di rilascio, oltre alle note di rilascio generali.

Canale di rilascio Note di rilascio
Canale rapido HTML o feed Atom.
Canale regolare HTML o feed Atom.
Canale stabile HTML o feed Atom.

Scegliere il miglior canale di rilascio per il cluster

Ogni canale rappresenta un livello diverso di qualità e maturità delle release di Kubernetes e GKE. Il seguente diagramma illustra il ciclo di adozione per i canali di rilascio:

Ciclo di adozione dei canali di rilascio

Come mostra questo diagramma, i canali di rilascio disponibili utilizzano versioni nel mezzo del ciclo di adozione, tra cui Early adopter (canale rapido), Early majority (canale regolare) e Majority (canale stabile). La prima parte del ciclo di adozione è costituita dagli innovatori, che testano le funzionalità più recenti utilizzando la release di Kubernetes upstream. L'ultima parte del ciclo di adozione è la maggioranza tardiva, in cui utilizzi una versione che sta per essere ritirata e devi eseguire la transizione a una versione supportata.

Negli ambienti di pre-produzione, utilizza il canale rapido per le versioni più recenti in cui puoi testare le funzionalità non appena sono disponibili a livello generale.

Per i workload di produzione che richiedono maturità rispetto alle funzionalità più recenti, consigliamo di utilizzare il canale regolare (predefinito) o il canale stabile.

  • Se devi monitorare attentamente le nuove funzionalità, ti consigliamo di utilizzare il canale Regular, che offre un equilibrio tra stabilità e aggiornamento della versione OSS di Kubernetes.
  • Se il tuo requisito è la maturità, soprattutto per i cluster di produzione, utilizza il canale stabilee.

GKE esegue l'upgrade dei cluster a una versione più recente che soddisfa gli standard di qualità del canale. Tuttavia, ti consigliamo di eseguire l'upgrade dei cluster in anticipo perché questo ti offre:

  • Migliore controllo degli upgrade e allineamento con l'orario di lavoro.
  • Migliore prevedibilità, perché GKE salta l'upgrade automatico dei cluster che soddisfano il target di rilascio (ovvero i cluster di cui è stato eseguito l'upgrade manuale alla versione target successiva). I nodi vengono aggiornati automaticamente alla versione consigliata nel canale selezionato per allinearsi alla versione del control plane e proteggerti da vulnerabilità e disallineamento delle versioni non supportato.

Ricevi assistenza a lungo termine con il canale esteso

GKE fornisce assistenza a lungo termine per le versioni secondarie di Kubernetes tramite il canale Esteso. Con questo canale, puoi rimanere con una versione secondaria per un massimo di 24 mesi. Dopo il periodo di assistenza standard di 14 mesi, il tuo cluster riceve patch di sicurezza per circa altri 10 mesi durante il periodo di assistenza estesa.

In che modo GKE esegue automaticamente l'upgrade dei cluster nel canale Extended

Per i cluster registrati nel canale Extended, GKE esegue automaticamente l'upgrade dei cluster nel seguente modo:

  • Durante il periodo di assistenza standard: GKE esegue l'upgrade dei cluster a versioni patch più recenti della stessa versione secondaria seguendo la stessa cadenza del canale regolare.
  • Durante il periodo di assistenza estesa: GKE continua a fornire aggiornamenti delle patch di sicurezza per la versione secondaria. Circa due mesi prima della fine del supporto esteso, GKE inizia l'upgrade dei cluster alla versione secondaria successiva, a meno che il cluster non utilizzi API o funzionalità deprecate. Puoi utilizzare le esclusioni dalla manutenzione per impedire gli upgrade delle versioni secondarie fino alla fine del supporto esteso.
  • Al termine del supporto esteso: GKE esegue l'upgrade di tutti i cluster in cui è ancora in esecuzione la versione secondaria non più supportata, indipendentemente dai problemi di blocco. Non puoi configurare le esclusioni dalla manutenzione dopo questa data, ad eccezione di una misura di emergenza temporanea con l'ambito "Nessun upgrade".

Per scoprire di più sui diversi periodi di disponibilità e sugli upgrade forniti da GKE durante il periodo di assistenza estesa, consulta Ciclo di vita delle versioni secondarie di GKE.

Limitazioni per la registrazione di un cluster nel canale esteso

Esamina le seguenti limitazioni per i cluster registrati nel canale Extended:

Prezzi del supporto esteso

Se vuoi registrare un cluster nel canale Extended, assicurati di aver esaminato i prezzi per l'assistenza estesa. I costi con pagamento in base al consumo sono applicati se il cluster è registrato nel canale esteso e per la versione secondaria del cluster inizia il periodo di assistenza esteso.

Best practice per il canale esteso

Esamina gli scenari seguenti per capire come utilizzare il canale Esteso per ridurre al minimo le interruzioni causate dagli upgrade delle versioni secondarie.

Gli scenari supportati richiedono alcune azioni manuali nel tempo per ottenere il massimo vantaggio dal canale. Non è consigliabile registrare un cluster nel canale senza prevedere di passare alla versione secondaria successiva, in quanto GKE alla fine eseguirà l'upgrade del cluster a versioni secondarie più recenti con la stessa frequenza degli altri canali e il tuo cluster potrebbe comportare costi maggiori e ricevere le nuove funzionalità per ultimo.

Scenari supportati e non supportati

Per scoprire di più sugli scenari supportati e non supportati, consulta la tabella seguente e vedi Utilizza il canale esteso quando hai bisogno di assistenza a lungo termine per maggiori dettagli. Un segno di spunta () indica uno scenario supportato:

Scenario di upgrade Supportato Riepilogo Tempo tra le modifiche delle versioni secondarie Azione manuale richiesta
Rimanere temporaneamente su una versione secondaria più a lungo Rimani con una versione secondaria per risolvere un problema che impedisce gli upgrade. Stessa frequenza media, con interruzione per tempo aggiuntivo su una versione secondaria.
  • Spostare temporaneamente un cluster da e verso il canale esteso.
  • Esegui manualmente l'upgrade del cluster alla nuova versione secondaria quando è pronta.
Esegui manualmente l'upgrade della versione secondaria 1-2 volte l'anno Ricevi nuove funzionalità, ma con upgrade secondari meno frequenti, quando è ottimale per i carichi di lavoro nel cluster. 1-2 volte all'anno.
  • Esegui manualmente l'upgrade del cluster a una versione secondaria più recente.
Non fare nulla e ricevere gli upgrade secondari con la stessa frequenza Ricevi gli upgrade delle versioni secondarie con la stessa frequenza degli altri canali e le nuove funzionalità il più tardi possibile. In media, ogni 4 mesi.
  • Monitoraggio degli upgrade automatici delle versioni secondarie dalle versioni non supportate.

Cluster non registrati in un canale di rilascio

Puoi scegliere di non registrare un cluster Standard in un canale di rilascio. Tuttavia, la mancata registrazione limita l'accesso del cluster a determinate funzionalità e questa è un'opzione di configurazione deprecata che verrà rimossa. Indipendentemente dalla registrazione al canale di rilascio, viene eseguito automaticamente l'upgrade dei control plane di tutti i cluster e, quando una versione raggiunge la fine del supporto, viene eseguito automaticamente l'upgrade dei control plane e dei nodi del cluster.

Per eseguire la migrazione da questa opzione di configurazione, vedi Registrare un cluster esistente.

Se stai valutando di non registrare un cluster in un canale di rilascio perché hai singoli pool di nodi di cui non è possibile eseguire l'upgrade automatico e devi eseguire l'upgrade manuale di questi nodi, puoi ottenere lo stesso comportamento con i canali di rilascio. Con i canali di rilascio, se devi disattivare gli upgrade automatici dei nodi per tutti i pool di nodi fino alla fine del supporto, puoi utilizzare un'esclusione della manutenzione del cluster con l'ambito "Nessun upgrade secondario o dei nodi". In alternativa, se hai un cluster in cui vuoi disabilitare gli upgrade automatici per alcuni node pool, ma non per tutti, utilizza un'esclusione dalla manutenzione del node pool.

Confronto tra i cluster registrati e non registrati in un canale di rilascio

Consulta la seguente tabella per comprendere le somiglianze e le differenze tra la registrazione e la mancata registrazione del cluster a un canale di rilascio:

Funzionalità Cluster registrato in un canale di rilascio Il cluster non è registrato in un canale di rilascio
Comportamento dell'upgrade condiviso
Tempistiche dell'upgrade Allineato al rispettivo canale di rilascio
  • Stessa data di inizio dell'upgrade automatico del canale stabile per le versioni secondarie
  • Stesse versioni secondarie disponibili, versioni di upgrade automatico delle patch e versione predefinita del canale regolare
  • Le stesse versioni patch disponibili del canale rapido per le versioni secondarie disponibili nel canale regolare
Upgrade automatici delle patch accelerati Disponibile Non disponibile
Controllo dell'interruzione del pool di nodi
Periodi di manutenzione Disponibile Disponibile
Esclusioni dalla manutenzione Limitato all'ambito "Nessun upgrade" (fino a 90 giorni)
Sequenza di implementazione Disponibile Non disponibile
Assistenza a lungo termine Disponibile solo con il canale di rilascio Esteso Non disponibile
Autopilot Disponibile Non disponibile

Scegliere il canale rapido per i cluster alpha

Il canale rapido fornisce al tuo cluster GKE l'accesso alle nuove versioni il prima possibile, incluse le versioni patch alpha delle prossime versioni secondarie. I cluster alpha ti consentono di testare nuove funzionalità che diventano disponibili per la prima volta nelle versioni più recenti. In un cluster alpha, tutte le API Kubernetes, incluse le API alpha, sono abilitate. Tutti i feature gate delle funzionalità alfa di Kubernetes sono abilitati per impostazione predefinita e puoi attivare o disattivare feature gate di funzionalità alfa e beta specifici. Prima di eseguire il deployment dei cluster alpha, consulta le limitazioni.

Puoi anche registrare il tuo cluster alpha nei canali di rilascio Regular o Stable, ma non puoi accedere alle ultime versioni di Kubernetes, incluse le patch alpha, in questi canali. La scelta di non registrare il cluster in un canale di rilascio è un'opzione di configurazione deprecata che verrà rimossa. Per maggiori informazioni, consulta la sezione precedente Cluster non registrati in un canale di rilascio.

Passaggi successivi