Prepararsi all'arresto dell'agente di avvio del container

L'agente di avvio dei container (konlet) che esegue il deployment dei container sulle istanze Compute Engine durante la creazione delle VM è deprecato.

Questo documento descrive come pianificare la migrazione dei container creati durante la creazione delle VM ad altri Google Cloud servizi.

Informazioni generali

Che cos'è un agente di avvio dei container in Compute Engine?
L'agente di avvio dei container consente di eseguire il deployment e la configurazione dei container su Compute Engine istanze o su istanze in un gruppo di istanze gestite (MIG) durante la creazione delle VM e avvia un container Docker.
Perché l'agente di avvio dei container è deprecato?

In base al feedback dei clienti, Google Cloud migliora le opzioni di deployment dei container. Abbiamo ritirato l'agente di avvio dei container per poterti offrire opzioni più flessibili per il deployment dei container.

Per ulteriori informazioni sulle opzioni ritirate, consulta Opzioni ritirate per la configurazione dei container sulle VM.

Quali sono le tappe fondamentali di questo ritiro e cosa succede se non intervengo entro la scadenza?

A partire dal 31 luglio 2026, tutti i workflow che si basano sull'agente di avvio dei container o sui metadati dell'istanza gce-container-declaration non funzioneranno più.

A partire dal 31 luglio 2027, Google interromperà l'assistenza per l'agente di avvio dei container e non verranno forniti ulteriori aggiornamenti per le VM in esecuzione che utilizzano i gce-container-declaration metadati. Eseguirai i carichi di lavoro a tuo rischio e pericolo e ciò potrebbe influire sul tuo workflow.

Ti consigliamo di eseguire la migrazione dei container a soluzioni alternative molto prima di queste date per garantire una transizione senza problemi.

Quando non potrò più creare nuove VM o nuovi MIG con i container di cui è stato eseguito il deployment direttamente utilizzando i metadati gce-container-declaration?

12 mesi dopo la notifica iniziale di ritiro, ovvero il 31 luglio 2026.

Quando non potrò più eseguire i deployment dei container su VM o MIG che utilizzano i metadati gce-container-declaration?

Interromperemo il supporto per tutti i carichi di lavoro di cui è stato eseguito il deployment utilizzando l'agente di avvio dei container 24 mesi dopo la notifica iniziale di ritiro, ovvero il 31 luglio 2027.

In che modo questo ritiro influisce sulla mia configurazione di Terraform?

Se utilizzi Terraform o un'automazione simile per creare o aggiornare VM o MIG impostando esplicitamente la chiave dei metadati gce-container-declaration, il tuo workflow smetterà di funzionare il 31 luglio 2026. Per evitare interruzioni, aggiorna la configurazione di Terraform in modo da utilizzare uno script di avvio per il deployment dei container e rimuovi la dipendenza dalla chiave dei metadati gce-container-declaration. Per istruzioni dettagliate, consulta la guida alla migrazione.

Questo ritiro significa che le immagini Container-Optimized OS verranno ritirate?

No, le immagini Container-Optimized OS non verranno ritirate. La modifica riguarda la modalità di deployment dei container sulle VM che utilizzano Container-Optimized OS. Le versioni più recenti di Container-Optimized OS non supporteranno più konlet, l'agente di avvio dei container che utilizza la chiave dei metadati gce-container-declaration per eseguire il deployment dei container. Le immagini Container-Optimized OS continueranno a essere disponibili e supportate. Tuttavia, devi aggiornare la configurazione della VM in modo da utilizzare uno script di avvio o cloud-init per eseguire il deployment dei container anziché fare affidamento sulla chiave dei metadati gce-container-declaration.

Utilizzo cloud-init per eseguire i container sulle VM. Questa modifica mi riguarda?

No. Questo ritiro non influisce sulle VM configurate utilizzando cloud-init. Puoi continuare a utilizzare cloud-init per configurare le istanze. Per ulteriori informazioni, consulta Utilizzo di cloud-init con la configurazione cloud.

Come faccio a sapere se questa modifica mi riguarda?

Se esegui il deployment di un container su una VM durante la creazione della VM utilizzando l'agente di avvio dei container o specificando gce-container-declaration, questa modifica ti riguarda. Per verificare se sono presenti istanze interessate nel tuo progetto,esegui il seguente comando gcloud CLI:

gcloud compute instances list --filter="metadata.items.key:gce-container-declaration"

Questo comando fornisce un elenco di tutte le istanze VM nel tuo progetto che contengono la chiave dei metadati gce-container-declaration. La chiave dei metadati identifica in modo univoco le VM che rientrano nell'ambito del ritiro. Se utilizzi più progetti, esegui il comando in tutti i progetti attivi.

Per ulteriori informazioni sulla visualizzazione dei metadati del progetto, consulta la documentazione sui metadati.

Se hai un'istanza specifica che vuoi controllare, esegui il seguente comando gcloud CLI:

gcloud compute instances describe VM_NAME

Sostituisci VM_NAME con il nome dell'istanza VM. Questo comando fornisce tutte le informazioni per una determinata istanza, inclusi i metadati. Se nell'output del comando viene visualizzata la chiave dei metadati gce-container-declaration, la VM è interessata da questa modifica.

Esiste un modo per impedire la creazione di VM che utilizzano l'agente di avvio dei container?

Sì. Gli amministratori dell'organizzazione possono applicare il vincolo del criterio dell'organizzazione compute.managed.disableVmsWithContainerStartupAgent per disattivare la creazione di risorse che utilizzano l'agente di avvio dei container e la chiave dei metadati gce-container-declaration. Puoi anche applicare questo criterio in modalità di prova per monitorare l'utilizzo prima di bloccare la creazione delle risorse. Per ulteriori informazioni, consulta Impedire la creazione di VM che utilizzano i metadati dei container ritirati.

Esiste un rischio per la sicurezza o la privacy del progetto durante la migrazione?

No. La sicurezza e la privacy sono fondamentali in tutto ciò che facciamo in Google. Quando utilizzi i nostri script o le nostre soluzioni gestite, hai la flessibilità di configurare impostazioni specifiche di sicurezza e privacy per soddisfare i tuoi requisiti. Per ulteriori informazioni, consulta la guida alla migrazione.

Soluzioni alternative

Quali sono le soluzioni alternative consigliate per i container su Compute Engine e come faccio a scegliere quella giusta per le mie esigenze?

Puoi scegliere una delle seguenti opzioni per eseguire la migrazione del container:

  • Se vuoi continuare a eseguire il deployment dei container su VM o MIG, eseguire i container per test e sviluppo o eseguire un carico di lavoro costituito da una singola VM, utilizza gli script di avvio o cloud-init.
  • Se hai applicazioni containerizzate stateless e job di piccole e medie dimensioni, valuta la possibilità di utilizzare Cloud Run. Puoi anche utilizzare gli script di avvio.
  • Se il container è un job batch con uno stato finale definito e richiede risorse di computing aggiuntive, valuta la possibilità di utilizzare Batch. Puoi anche utilizzare gli script di avvio.
  • Se hai bisogno di un controllo e di una scalabilità avanzati o non riesci a soddisfare i tuoi requisiti con le altre opzioni, valuta la possibilità di utilizzare GKE.

Per indicazioni e consigli dettagliati sulle opzioni di migrazione, consulta la guida alla migrazione.

Perché dovrei prendere in considerazione la migrazione a un servizio gestito come Cloud Run, GKE o Batch anziché utilizzare uno script di avvio?

Ti consigliamo di prendere in considerazione la migrazione a soluzioni di container come Google Kubernetes Engine, Cloud Run e Batch. Questi servizi gestiti offrono vantaggi significativi rispetto ai deployment convenzionali basati su VM, tra cui scalabilità, flessibilità e funzionalità di gestione avanzate.

I vantaggi principali includono:

  • Riduzione del sovraccarico di gestione: in quanto servizi completamente gestiti,Google Cloud gestiscono l'infrastruttura sottostante (VM, applicazione di patch, scalabilità). Questo approccio libera tempo prezioso del personale e riduce il carico operativo.
  • Scalabilità automatica ed elasticità: questi servizi regolano automaticamente le risorse in base alla domanda. Ciò comporta un migliore utilizzo delle risorse e un potenziale risparmio sui costi rispetto al provisioning eccessivo delle VM.
  • Efficienza in termini di costi per i carichi inattivi: a differenza delle VM, che comportano costi anche quando sono inattive, i servizi gestiti possono essere più convenienti per le applicazioni con traffico fluttuante o basso.
  • Utilizzo della disponibilità del livello senza costi: GKE, Cloud Run e Batch offrono un livello senza costi, che ti consente di eseguire carichi di lavoro più piccoli o condurre test senza costi.

Per indicazioni dettagliate sulla migrazione, consulta la guida alla migrazione.

Quali sono le considerazioni sui costi per ogni soluzione alternativa e come si confrontano con la configurazione attuale?

Script di avvio o cloud-init per il deployment dei container: l'utilizzo di script di avvio o cloud-init come sostituzione diretta non modifica intrinsecamente i costi di Compute Engine. Continui a pagare per le risorse VM sottostanti.

Servizi gestiti: il passaggio a servizi come Cloud Run o Batch può offrire risparmi sui costi, soprattutto per le applicazioni con un utilizzo variabile. A differenza delle VM che vengono addebitate anche quando sono inattive, questi servizi gestiti possono essere più efficienti. Inoltre, i livelli senza costi possono ridurre ulteriormente i costi per i carichi di lavoro più piccoli e temporanei.

Per ulteriori informazioni, consulta Confrontare le opzioni di deployment dei container. I prezzi variano in base al servizio scelto e alla configurazione specifica. Utilizza il Calcolatore prezzi per una stima accurata.

Questo ritiro significa che le immagini Container-Optimized OS verranno ritirate e quindi, se vogliamo eseguire Docker sulle VM di Compute Engine, dovremo configurare il nostro modello di VM?

No,le immagini Container-Optimized OS non verranno ritirate. La modifica riguarda la modalità di avvio dei container sulle VM che utilizzano Container-Optimized OS. Le versioni più recenti di Container-Optimized OS non supporteranno più konlet, l'agente di avvio dei container che avvia i container utilizzando la chiave dei metadati gce-container-declaration. Ciò significa che le immagini Container-Optimized OS continueranno a essere disponibili e supportate. Tuttavia, devi aggiornare la VM in modo da utilizzare uno script di avvio o una configurazione cloud-init per eseguire il deployment dei container anziché utilizzare la chiave dei metadati gce-container-declaration.

Processo di migrazione

Qual è l'approccio consigliato per la migrazione dei container alle soluzioni alternative?

Ti consigliamo di seguire questi passaggi per la migrazione:

  • Comprendi le tue opzioni: consulta la guida alla migrazione per esplorare modi alternativi per eseguire i container.
  • Pianifica la migrazione in anticipo: per garantire una transizione senza problemi, inizia a pianificare la migrazione dei deployment dei container attuali molto prima del 31 luglio 2026.
  • Preparati per i nuovi carichi di lavoro: assicurati che i nuovi carichi di lavoro dei container siano pronti per l'esecuzione su soluzioni alternative entro il 31 luglio 2026, poiché il deployment diretto dei container su VM o MIG non è più possibile.
  • Scadenza finale della migrazione: assicurati che tutti i carichi di lavoro dei container esistenti siano migrati a soluzioni alternative entro il 31 luglio 2027, quando il metodo di deployment diretto verrà ritirato completamente.
Devo eseguire la migrazione a una delle soluzioni consigliate o esistono alternative che posso utilizzare?

Supportiamo la tua flessibilità nell'adottare qualsiasi soluzione che si allinei alle tue esigenze aziendali e sia supportata attivamente. Sono disponibili risorse come la guida alla migrazione per aiutarti a scegliere l'opzione più adatta.

Il backup o l'esportazione dei dati è richiesto nell'ambito del processo di migrazione?

Anche se l'esecuzione di un backup o di un'esportazione dei dati è sempre una best practice fondamentale per la sicurezza dei dati e la continuità operativa, non è un passaggio necessario per questo processo di migrazione.

Quanto tempo impiegherò per eseguire la migrazione a una delle alternative ed esistono fattori che potrebbero influire sul mio impegno di tempo?

Script di avvio per il deployment dei container: la configurazione iniziale e i test utilizzando gli script di avvio dovrebbero richiedere circa 1-2 ore. I deployment successivi dovrebbero richiedere solo pochi minuti ciascuno.

Servizi gestiti: la scelta di Google Cloud soluzioni come Cloud Run, Batch o GKE, che sono offerte PaaS serverless e completamente gestite, potrebbe comportare un maggiore investimento iniziale di tempo e impegno. Ciò è dovuto al cambiamento fondamentale da un approccio incentrato sulla VM (IaaS) in cui gestisci l'infrastruttura a un modello PaaS in cui la piattaforma gestisce gran parte di questa. Questo adattamento potrebbe richiedere modifiche all'applicazione, ad esempio assicurarsi che sia stateless, ma i vantaggi a lungo termine possono includere notevoli miglioramenti in termini di efficienza operativa, scalabilità e convenienza.

Per indicazioni su questa transizione, consulta la guida alla migrazione.

Se scelgo di eseguire la migrazione a un'alternativa, sono previste interruzioni o tempi di inattività per Google Cloud progetti, VM, servizi e app?

In genere, la transizione alla soluzione alternativa consigliata è progettata per essere un processo senza tempi di inattività.

Per la migrazione dei container a lunga esecuzione sulle VM di Compute Engine, per evitare interruzioni, ti consigliamo di configurare nuove VM con la configurazione alternativa e di trasferire il traffico una volta testate.

In che modo questa migrazione influisce sulla mia configurazione di Terraform?

Se utilizzi Terraform o un'automazione simile per creare o aggiornare VM o MIG con i container impostando esplicitamente la chiave dei metadati gce-container-declaration, il tuo workflow smetterà di funzionare il 31 luglio 2026. Per evitare interruzioni, devi aggiornare la configurazione in modo da includere uno script di avvio per il deployment dei container e rimuovere la dipendenza dalla chiave dei metadati gce-container-declaration. Per istruzioni dettagliate su come implementare questa modifica, consulta Eseguire la migrazione dei container di cui è stato eseguito il deployment sulle VM durante la creazione delle VM.

Richiedere assistenza

A chi devo rivolgermi in Compute Engine se ho domande sul processo di migrazione?
Per qualsiasi domanda o se hai bisogno di aiuto, contatta l'assistenza Google Cloud.
Quali risorse sono disponibili per supportarmi nella migrazione e fornire indicazioni tecniche?
Questa pagina di domande frequenti, una guida alla migrazione e l'assistenza Google Cloud sono disponibili per supportarti nel processo di migrazione.