Prepararsi alla chiusura dell'agente di avvio

L'agente di avvio del container che esegue il deployment dei container sulle istanze Compute Engine durante la creazione della VM è deprecato.

Questo documento descrive come pianificare la migrazione dei container creati durante la creazione della VM ad altri servizi Trusted Cloud by S3NS .

Informazioni generali

Che cos'è un agente di avvio del contenitore in Compute Engine?

L'agente di avvio del container consente di eseguire il deployment e configurare i container su istanze Compute Engine o su istanze in un gruppo di istanze gestite (MIG) durante la creazione della VM e avvia un container Docker.

Perché l'agente di avvio del container è deprecato?

In base al feedback dei clienti, Trusted Cloud by S3NS migliora le opzioni di deployment dei container. Abbiamo ritirato l'agente di avvio del container per offrirti opzioni più flessibili per il deployment dei container.

Per saperne di più 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 flussi di lavoro che si basano sull'agente di avvio del container o sui metadati dell'istanza gce-container-declaration smetteranno di funzionare.

A partire dal 31 luglio 2027, Google non supporterà più l'agente di avvio del container e non verranno forniti ulteriori aggiornamenti per le VM in esecuzione che utilizzano i metadati gce-container-declaration. Esegui i carichi di lavoro a tuo rischio e pericolo e ciò può influire sul tuo flusso di lavoro.

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 container di cui è stato eseguito il deployment direttamente utilizzando i metadati gce-container-declaration?

12 mesi dalla notifica iniziale del ritiro, ovvero il 31 luglio 2026.

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

Non supporteremo più i carichi di lavoro di cui è stato eseguito il deployment utilizzando l'agente di avvio dei container 24 mesi dopo la notifica di ritiro iniziale, ovvero a partire dal 31 luglio 2027.

Utilizzo cloud-init per eseguire container sulle VM. Am I impacted by this change?

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 Cloud Config.

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 deprecazione ti riguarda. Per verificare se ci sono 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 di 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 vedi la chiave dei metadati gce-container-declaration nell'output comando, la tua VM è interessata da questa modifica.

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 ai 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 contenitore:

• Se vuoi continuare a eseguire il deployment di container su VM o MIG oppure eseguire container per test e sviluppo o un workload costituito da una singola VM, utilizza gli script di avvio o cloud-init.
• Se hai applicazioni container stateless e job di piccole e medie dimensioni, valuta Cloud Run. Puoi anche utilizzare gli script di avvio.
• Se il tuo container è un job batch con uno stato finale definito e richiede risorse di calcolo aggiuntive, valuta Batch. Puoi anche utilizzare script di avvio.
• Se hai bisogno di controllo e 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, leggi 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 valutare 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 qualità di servizi completamente gestiti,Trusted Cloud gestisce l'infrastruttura sottostante (VM, applicazione di patch, scalabilità). Questo approccio libera tempo prezioso per il personale e riduce il carico operativo.
• Scalabilità automatica e garanzia di 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.
• Ottieni 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.
• Utilizza la disponibilità del livello gratuito: GKE, Cloud Run e Batch offrono un livello gratuito, che ti consente di eseguire carichi di lavoro più piccoli o condurre test senza costi potenziali.

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 del deployment dei container o cloud-init: l'utilizzo di script di avvio o di 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 utilizzo variabile. A differenza delle VM che vengono addebitate anche quando sono inattive, questi servizi gestiti possono essere più efficienti. Inoltre, i livelli gratuiti possono ridurre ulteriormente i costi per i workload più piccoli e temporanei.

Per saperne di più, vedi Confrontare le opzioni di deployment dei container. I prezzi variano in base al servizio scelto e alla tua 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 Compute Engine, dovremo configurare il nostro modello di VM?

No,le immagini Container-Optimized OS non sono in fase di ritiro. La modifica riguarda l'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 che avvia i container utilizzando la chiave di metadati gce-container-declaration. Ciò significa che le immagini Container-Optimized OS saranno ancora disponibili e supportate. Tuttavia, devi aggiornare la VM in modo che utilizzi uno script di avvio o la configurazione cloud-init per eseguire il deployment dei container anziché utilizzare la chiave di metadati gce-container-declaration.

Processo di migrazione

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

Ti consigliamo di procedere nel seguente modo 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 delle implementazioni 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é non sarà più possibile il deployment diretto dei container su VM o MIG.
• Scadenza finale della migrazione: assicurati che tutti i carichi di lavoro dei container esistenti vengano 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 in linea con le tue esigenze aziendali e 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 sono necessari nell'ambito del processo di migrazione?

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

Quanto tempo mi servirà per eseguire la migrazione a una delle alternative e quali fattori potrebbero influire sul mio impegno di tempo?

Script di avvio del deployment del container: La configurazione iniziale e il 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 Trusted Cloud by S3NS 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 sulle VM (IaaS) in cui gestisci l'infrastruttura a un modello PaaS in cui la piattaforma gestisce gran parte di questo. Questo adattamento potrebbe richiedere modifiche alla tua applicazione, ad esempio assicurandoti che sia senza stato, ma i vantaggi a lungo termine possono includere notevoli miglioramenti in termini di efficienza operativa, scalabilità ed economicità.

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

Se scelgo di eseguire la migrazione a un'alternativa, si verificano interruzioni o tempi di inattività per Trusted Cloud by S3NS progetti, VM, servizi e app?

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

Per la migrazione di container a esecuzione prolungata 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 Terraform?

Se utilizzi Terraform o un'automazione simile per creare o aggiornare VM o MIG con container impostando esplicitamente la chiave di metadati gce-container-declaration, il tuo flusso di lavoro 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 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 in caso di 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?

Queste domande frequenti, una guida alla migrazione e l'assistenza Google Cloud sono disponibili per supportarti nel processo di migrazione.