Questa pagina fornisce considerazioni e suggerimenti che ti aiuteranno a eseguire la migrazione dei carichi di lavoro dai cluster Google Kubernetes Engine (GKE) standard ai cluster Autopilot con interruzioni minime dei servizi. Questa pagina è rivolta agli amministratori di cluster che hanno già deciso di eseguire la migrazione ad Autopilot. Se hai bisogno di ulteriori informazioni prima di decidere di eseguire la migrazione, consulta Scegliere una modalità operativa GKE e Confrontare GKE Autopilot e Standard.
Come funziona la migrazione
I cluster Autopilot automatizzano molte delle caratteristiche e funzionalità facoltative che richiedono la configurazione manuale nei cluster Standard. Inoltre, i cluster Autopilot applicano configurazioni predefinite più sicure per consentire alle applicazioni di fornire un ambiente più pronto per la produzione e ridurre l'overhead di gestione richiesto rispetto alla modalità Standard. I cluster Autopilot applicano molti suggerimenti e best practice GKE per impostazione predefinita. Autopilot utilizza un modello di configurazione incentrato sul carico di lavoro, in cui richiedi ciò di cui hai bisogno nei manifest Kubernetes e GKE esegue il provisioning dell'infrastruttura corrispondente.
Quando esegui la migrazione dei carichi di lavoro standard ad Autopilot, devi preparare i manifest dei carichi di lavoro per garantirne la compatibilità con i cluster Autopilot, ad esempio assicurandoti che i tuoi manifest richiedano l'infrastruttura di cui normalmente dovresti eseguire il provisioning.
Per preparare ed eseguire correttamente una migrazione, dovrai svolgere le seguenti attività di alto livello:
- Esegui un controllo pre-flight sul cluster Standard esistente per confermare la compatibilità con Autopilot.
- Se applicabile, modifica i manifest del carico di lavoro per renderli compatibili con Autopilot.
- Esegui una prova per controllare che i carichi di lavoro funzionino correttamente su Autopilot.
- Pianifica e crea il cluster Autopilot.
- Se applicabile, aggiorna i tuoi strumenti Infrastructure as Code.
- Esegui la migrazione.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
- Abilita l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività, installa e quindi initialize gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo
gcloud components update.
- Assicurati di avere un cluster Standard esistente con carichi di lavoro in esecuzione.
- Assicurati di avere un cluster Autopilot senza carichi di lavoro per eseguire le prove. Per creare un nuovo cluster Autopilot, consulta Creare un cluster Autopilot.
Esegui un controllo pre-flight sul cluster Standard
Google Cloud CLI e l'API Google Kubernetes Engine forniscono uno strumento di controllo pre-flight che convalida le specifiche dei carichi di lavoro standard in esecuzione per identificare le incompatibilità con i cluster Autopilot. Questo strumento è disponibile in GKE 1.26 e versioni successive.
- Per utilizzare questo strumento dalla riga di comando, esegui questo comando:
gcloud container clusters check-autopilot-compatibility CLUSTER_NAME
Sostituisci CLUSTER_NAME con il nome del tuo cluster standard. Facoltativamente, aggiungi --format=json a questo comando per ottenere l'output in un
file JSON.
L'output contiene risultati per tutti i carichi di lavoro standard in esecuzione, classificati e con suggerimenti strategici per garantire la compatibilità con Autopilot, ove applicabile. Nella tabella seguente sono descritte le categorie:
| Risultati dello strumento pre-flight | |
|---|---|
Passed |
Il carico di lavoro verrà eseguito come previsto senza necessità di configurazione per Autopilot. |
Passed with optional configuration |
Il carico di lavoro verrà eseguito su Autopilot, ma puoi apportare modifiche facoltative alla configurazione per ottimizzare l'esperienza. Se non apporti modifiche alla configurazione, Autopilot applica automaticamente una configurazione predefinita. Ad esempio, se il carico di lavoro era in esecuzione su macchine N2 in modalità Standard, GKE applica la classe di computing per uso generico per Autopilot. Facoltativamente, puoi modificare il carico di lavoro per richiedere la classe di computing bilanciata, supportata dalle macchine N2. |
Additional configuration required |
Il carico di lavoro non verrà eseguito su Autopilot a meno che non apporti una modifica alla configurazione. Ad esempio, considera un container che utilizza la funzionalità NET_ADMIN in Standard. Autopilot elimina questa funzionalità per impostazione predefinita per una maggiore sicurezza, quindi dovrai abilitare NET_ADMIN sul cluster prima di eseguire il deployment del carico di lavoro. |
Incompatibility |
Il carico di lavoro non verrà eseguito su Autopilot perché utilizza funzionalità che Autopilot non supporta. Ad esempio, i cluster Autopilot rifiutano i pod con privilegi ( |
Modifica le specifiche del carico di lavoro in base ai risultati precedenti al periodo di pubblicazione
Dopo aver eseguito il controllo pre-flight, segui l'output JSON e identifica i carichi di lavoro che devono modificare. Consigliamo di implementare anche i suggerimenti di configurazione facoltativi. Ogni risultato fornisce anche un link alla documentazione che mostra come dovrebbe essere la specifica del carico di lavoro.
La differenza più importante tra Autopilot e Standard è che la configurazione dell'infrastruttura in Autopilot è automatizzata in base alle specifiche del carico di lavoro. I controlli di pianificazione di Kubernetes, come le incompatibilità e le tolleranze dei nodi, vengono aggiunti automaticamente ai carichi di lavoro in esecuzione. Se necessario, devi anche modificare le configurazioni Infrastructure as Code, ad esempio i grafici Helm o gli overlay Kustomize, in modo che corrispondano.
Ecco alcune modifiche comuni alla configurazione:
| Modifiche comuni alla configurazione per Autopilot | |
|---|---|
| Configurazione di computing e architettura | I cluster Autopilot utilizzano il tipo di macchina E-Series per impostazione predefinita. Se hai bisogno di altri tipi di macchine, la specifica del carico di lavoro deve richiedere una classe di computing, che indica ad Autopilot di posizionare quei pod su nodi che utilizzano architetture o tipi di macchine specifici. Per maggiori dettagli, vedi Classi di calcolo in Autopilot. |
| Acceleratori | I carichi di lavoro basati su GPU devono richiedere GPU nella specifica dei carichi di lavoro. Autopilot esegue automaticamente il provisioning dei nodi con il tipo di macchina e gli acceleratori richiesti. Per maggiori dettagli, consulta Eseguire il deployment dei carichi di lavoro GPU in Autopilot. |
| Richieste di risorse | Tutti i carichi di lavoro Autopilot devono specificare i valori per Per maggiori dettagli, consulta Richieste di risorse in Autopilot. |
| Carichi di lavoro a tolleranza di errore sulle VM spot | Se i tuoi carichi di lavoro vengono eseguiti su VM spot in Standard, richiedi pod spot nella configurazione del carico di lavoro impostando un selettore di nodi per Per maggiori dettagli, consulta Pod spot. |
Esegui una prova su un cluster Autopilot di gestione temporanea
Dopo aver modificato il manifest di ogni carico di lavoro, esegui un deployment di prova su un nuovo cluster Autopilot per assicurarti che il carico di lavoro venga eseguito come previsto.
Riga di comando
Esegui questo comando:
kubectl create --dry-run=server -f=PATH_TO_MANIFEST
Sostituisci PATH_TO_MANIFEST con il percorso del manifest del carico di lavoro modificato.
IDE
Se utilizzi l'editor di Cloud Shell, il comando dry-run è integrato e viene eseguito su qualsiasi manifest aperto. Se utilizzi gli IDE Visual Studio Code o Intellij, installa l'estensione Cloud Code per eseguire automaticamente il dry run su qualsiasi manifest aperto.
Il riquadro Problemi nell'IDE mostra eventuali problemi di dry run, ad esempio nell'immagine seguente che mostra un dry run non riuscito per un manifest che ha specificato privileged: true.
Pianifica il cluster Autopilot di destinazione
Quando la prova non mostra più problemi, pianifica e crea il nuovo cluster Autopilot per i tuoi carichi di lavoro. Questo cluster è diverso dal cluster Autopilot che hai utilizzato per testare le modifiche del manifest nella sezione precedente.
Utilizza le best practice per l'onboarding in GKE per i requisiti di configurazione di base. Quindi, leggi la panoramica di Autopilot, che fornisce informazioni specifiche per il tuo caso d'uso a diversi livelli.
Inoltre, considera quanto segue:
- I cluster Autopilot sono nativi di VPC, perciò non consigliamo di eseguire la migrazione ad Autopilot da cluster standard basati su route.
- Utilizza lo stesso VPC o un VPC simile per il cluster Autopilot e Standard, incluse eventuali regole firewall personalizzate e impostazioni VPC.
- I cluster Autopilot utilizzano GKE Dataplane V2 e supportano solo Cilium NetworkPolicies. I criteri NetworkPolicies di Calico non sono supportati.
- Se vuoi utilizzare il mascheramento IP in Autopilot, utilizza un criterio NAT in uscita.
- Se hai un cluster Standard privato, crea un cluster Autopilot privato con impostazioni di isolamento simili.
- Specifica l'intervallo IPv4 principale per il cluster durante la creazione del cluster, con la stessa dimensione dell'intervallo del cluster Standard.
- Scopri di più sulle differenze di quota tra le modalità, soprattutto se hai cluster di grandi dimensioni.
- Scopri i massimi di pod per nodo per Autopilot, che sono diversi da Standard. Questo è più importante se utilizzi spesso l'affinità nodo o pod.
- Tutti i cluster Autopilot utilizzano Cloud DNS.
Crea il cluster Autopilot
Quando è tutto pronto per creare il cluster, usa Crea un cluster Autopilot. Tutti i cluster Autopilot sono a livello di regione e vengono registrati automaticamente in un canale di rilascio, anche se puoi specificare il canale e la versione del cluster. Consigliamo di eseguire il deployment nel cluster di un piccolo carico di lavoro di esempio per attivare il provisioning automatico dei nodi in modo che i carichi di lavoro di produzione possano essere pianificati immediatamente.
Aggiorna i tuoi strumenti Infrastructure as Code
I seguenti provider Infrastructure as Code supportano Autopilot:
Leggi la documentazione del tuo fornitore preferito e modifica le tue configurazioni.
Scegli un approccio alla migrazione
Il metodo di migrazione da utilizzare dipende dal singolo carico di lavoro e dal livello di dimestichezza con i concetti di networking, ad esempio i servizi multi-cluster e l'Ingress multi-cluster, nonché il modo in cui gestisci lo stato degli oggetti Kubernetes nel tuo cluster.
| Tipo di carico di lavoro | Risultati dello strumento pre-flight | Approccio alla migrazione |
|---|---|---|
| Stateless |
|
Per i carichi di lavoro |
| Stateful |
|
Utilizza uno dei seguenti metodi:
|
| Configurazione aggiuntiva richiesta | Aggiorna i manifest Kubernetes ed esegui di nuovo il deployment su Autopilot durante il tempo di inattività pianificato. Per i passaggi generali, consulta Eseguire manualmente la migrazione dei carichi di lavoro stateful. |
Passaggi generali per la migrazione
Prima di iniziare una migrazione, assicurati di aver risolto eventuali risultati di Incompatible o
Additional configuration required del controllo pre-flight. Se esegui il deployment dei carichi di lavoro con questi risultati su Autopilot senza modifiche, i carichi di lavoro non riusciranno.
Le seguenti sezioni sono una panoramica generale di una migrazione ipotetica. I passaggi effettivi variano a seconda dell'ambiente e di ciascuno dei carichi di lavoro. Pianifica, testa e ripeti i test dei carichi di lavoro per rilevare eventuali problemi prima di eseguire la migrazione di un ambiente di produzione. Ecco alcune considerazioni:
- La durata del processo di migrazione dipende dal numero di carichi di lavoro di cui viene eseguita la migrazione.
- Quando esegui la migrazione dei carichi di lavoro stateful, è richiesto un tempo di inattività.
- La migrazione manuale ti consente di concentrarti sui singoli carichi di lavoro durante la migrazione, in modo da poter risolvere i problemi in tempo reale caso per caso.
- In tutti i casi, assicurati di eseguire la migrazione di Service, Ingress e altri oggetti Kubernetes che facilitano la funzionalità dei tuoi carichi di lavoro stateless e stateful.
Esegui la migrazione di tutti i carichi di lavoro utilizzando Backup per GKE
Se tutti i carichi di lavoro (stateful e stateless) in esecuzione nel cluster Standard sono compatibili con Autopilot e lo strumento preflight restituisce Passed o Passed with optional configuration per ogni carico di lavoro, puoi utilizzare Backup per GKE per eseguire il backup dell'intero stato del cluster e dei carichi di lavoro Standard e ripristinare il backup sul cluster Autopilot.
Questo approccio presenta i seguenti vantaggi:
- È possibile spostare tutti i carichi di lavoro dall'uso standard ad Autopilot con una configurazione minima.
- È possibile spostare carichi di lavoro stateless e stateful e conservare le relazioni tra i carichi di lavoro e gli oggetti PersistentVolume associati.
- I rollback sono intuitivi e gestiti da Google. Puoi eseguire il rollback dell'intera migrazione o eseguire il rollback selettivo di carichi di lavoro specifici.
- Puoi eseguire la migrazione dei carichi di lavoro stateful tra regioni Google Cloud. La migrazione manuale dei carichi di lavoro stateful può avvenire solo nella stessa regione.
Quando utilizzi questo metodo, GKE applica le configurazioni predefinite di Autopilot ai carichi di lavoro che hanno ricevuto un risultato Passed with optional configuration dallo strumento pre-flight. Prima di eseguire la migrazione di questi carichi
di lavoro, assicurati di avere scelto le impostazioni predefinite.
Esegui manualmente la migrazione dei carichi di lavoro stateless senza tempi di inattività
Per eseguire la migrazione di carichi di lavoro stateless senza tempi di inattività per i servizi, devi registrare i cluster di origine e di destinazione in un parco risorse GKE e utilizzare i servizi multi-cluster e Ingress multi-cluster per assicurarti che i carichi di lavoro rimangano disponibili durante la migrazione.
- Abilita i servizi multi-cluster e Ingress multi-cluster per il tuo cluster di origine e il tuo cluster di destinazione. Per le istruzioni, consulta Configurazione di servizi multi-cluster e Configurazione di Ingress multi-cluster.
- Se hai dipendenze di backend, ad esempio un carico di lavoro di database, esporta questi servizi dal cluster Standard utilizzando i servizi multi-cluster. Ciò consente ai carichi di lavoro nel cluster Autopilot di accedere alle dipendenze nel cluster Standard. Per le istruzioni, consulta Registrare un servizio per l'esportazione.
- Esegui il deployment di una risorsa Ingress multi-cluster e di un servizio multi-cluster per controllare il traffico in entrata tra i cluster. Configura il servizio multi-cluster in modo in modo da inviare traffico solo al cluster Standard. Per le istruzioni, consulta Deployment di Ingress in più cluster.
- Esegui il deployment dei carichi di lavoro stateless nel cluster Autopilot con manifest aggiornati. I servizi multi-cluster esportati abbinano e inviano automaticamente il traffico ai carichi di lavoro stateful corrispondenti.
- Aggiorna il servizio multi-cluster per indirizzare il traffico in entrata al cluster Autopilot. Per le istruzioni, vedi Selezione del cluster.
Ora gestisci i tuoi carichi di lavoro stateless dal cluster Autopilot. Se nel cluster di origine avevi solo carichi di lavoro stateless e non sono rimaste dipendenze, vai a Completa la migrazione. Se hai carichi di lavoro stateful, passa alla sezione Eseguire manualmente la migrazione dei carichi di lavoro stateful.
Esegui manualmente la migrazione dei carichi di lavoro stateful
Dopo aver eseguito la migrazione dei carichi di lavoro stateless, devi uscire ed eseguire la migrazione dei carichi di lavoro stateful dal cluster Standard. Questo passaggio richiede un tempo di inattività per il cluster.
- Avvia il tempo di inattività dell'ambiente.
- Disattiva i carichi di lavoro stateful.
- Assicurati di aver modificato i manifest del carico di lavoro per garantire la compatibilità con Autopilot. Per maggiori dettagli, consulta Modificare le specifiche del carico di lavoro in base ai risultati precedenti al periodo di pubblicazione.
Esegui il deployment dei carichi di lavoro sul tuo cluster Autopilot.
Esegui il deployment dei servizi per i carichi di lavoro stateful nel cluster Autopilot.
Aggiorna il networking in-cluster per consentire ai carichi di lavoro stateless di continuare a comunicare con i carichi di lavoro di backend:
- Se hai utilizzato un indirizzo IP statico nei servizi di backend del cluster Standard, riutilizzalo in Autopilot.
- Se consenti a Kubernetes di assegnare un indirizzo IP, di eseguire il deployment dei servizi di backend, di ottenere il nuovo indirizzo IP e di aggiornare il DNS in modo che utilizzi il nuovo indirizzo IP.
In questa fase si deve verificare quanto segue:
- Stai eseguendo tutti i tuoi carichi di lavoro stateless in Autopilot.
- Anche tutti i carichi di lavoro stateful di backend sono in esecuzione in Autopilot.
- I carichi di lavoro stateless e stateful possono comunicare tra loro.
- Il servizio multi-cluster indirizza tutto il traffico in entrata al cluster Autopilot.
Dopo aver eseguito la migrazione di tutti i carichi di lavoro e degli oggetti Kubernetes nel nuovo cluster, vai a Completa la migrazione.
Alternativa: esegui la migrazione manuale di tutti i carichi di lavoro durante il tempo di inattività
Se non vuoi utilizzare i servizi multi-cluster e Ingress multi-cluster per eseguire la migrazione dei carichi di lavoro con tempi di inattività minimi, esegui la migrazione di tutti i carichi di lavoro durante il tempo di inattività. Questo metodo comporta tempi di inattività più lunghi per i servizi, ma non richiede l'utilizzo di funzionalità multi-cluster.
- Inizia il tuo tempo di riposo.
- Esegui il deployment dei manifest stateless nel cluster Autopilot.
- Esegui manualmente la migrazione dei carichi di lavoro stateful. Per le istruzioni, consulta la sezione Eseguire manualmente la migrazione dei carichi di lavoro stateful.
- Modificare i record DNS per il traffico esterno in entrata e tra cluster in modo da utilizzare i nuovi indirizzi IP dei servizi.
- Termina il tuo tempo di riposo.
Completare la migrazione
Dopo aver spostato tutti i carichi di lavoro e i servizi nel nuovo cluster Autopilot, termina il tempo di inattività e lascia che l'ambiente si impieghi per una durata predeterminata. Quando lo stato della migrazione ti soddisfa e hai la certezza che non sarà necessario eseguirne il rollback, puoi eseguire la pulizia degli artefatti e completare la migrazione.
(Facoltativo) Eseguire la pulizia delle caratteristiche multi-cluster
Se hai utilizzato Ingress multi-cluster e servizi multi-cluster per la migrazione e non vuoi che il tuo cluster Autopilot rimanga registrato in un parco risorse, procedi nel seguente modo:
- Per il traffico esterno in entrata, esegui il deployment di una risorsa Ingress e impostala sull'indirizzo IP dei servizi che espongono i tuoi carichi di lavoro. Per le istruzioni, consulta Ingress per bilanciatori del carico delle applicazioni esterni.
- Per il traffico tra cluster, ad esempio dai carichi di lavoro frontend alle dipendenze stateful, aggiorna i record DNS del cluster in modo che utilizzino gli indirizzi IP di questi servizi.
- Elimina la risorsa Ingress multi-cluster e le risorse di servizio multi-cluster che hai creato durante la migrazione.
- Disabilita Ingress multi-cluster e i servizi multi-cluster.
- Annulla la registrazione del cluster Autopilot dal parco risorse.
Elimina il cluster Standard
Se è trascorso un periodo di tempo sufficiente dopo il completamento della migrazione e se lo stato del nuovo cluster ti soddisfa, elimina il cluster Standard. Ti consigliamo di conservare i file manifest Standard di cui hai eseguito il backup.
Esegui il rollback di una migrazione errata
Se riscontri problemi e vuoi tornare al cluster Standard, esegui una delle seguenti operazioni, a seconda di come hai eseguito la migrazione:
Se hai utilizzato Backup per GKE per creare backup durante la migrazione, ripristina i backup nel cluster Standard originale. Per le istruzioni, vedi Ripristinare un backup.
Se hai eseguito manualmente la migrazione dei carichi di lavoro, ripeti i passaggi della migrazione nelle sezioni precedenti con il cluster Standard come destinazione e il cluster Autopilot come origine. A livello generale, sono necessari i seguenti passaggi:
- Avvia il tempo di riposo.
- Esegui manualmente la migrazione dei carichi di lavoro stateful nel cluster Standard. Per le istruzioni, consulta la sezione relativa alla migrazione manuale dei carichi di lavoro stateful.
- Sposta i carichi di lavoro stateless nel cluster Standard utilizzando i manifest originali di cui hai eseguito il backup prima della migrazione.
- Esegui il deployment della tua risorsa Ingress nel cluster Standard e esegui il cutover del tuo DNS ai nuovi indirizzi IP per i servizi.
- Elimina il cluster Autopilot.
Passaggi successivi
- Pianificare le richieste di risorse Autopilot
- Configura il monitoraggio
- Configura e utilizza la dashboard della security posture