Questa pagina fornisce considerazioni e consigli 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 tuoi servizi. Questa pagina è rivolta agli amministratori dei cluster che hanno già deciso di eseguire la migrazione ad Autopilot. Se hai bisogno di maggiori informazioni prima di decidere di eseguire la migrazione, consulta Scegliere una modalità di funzionamento di GKE e Confrontare GKE Autopilot e Standard.
Come funziona la migrazione
I cluster Autopilot automatizzano molte delle funzionalità facoltative che richiedono la configurazione manuale nei cluster standard. Inoltre, i cluster Autopilot applicano configurazioni predefinite più sicure per le applicazioni per fornire un ambiente più pronto per la produzione e ridurre l'overhead di gestione richiesto rispetto alla modalità standard. I cluster Autopilot applicano per impostazione predefinita molte best practice e consigli di GKE. Autopilot utilizza un modello di configurazione incentrato sul carico di lavoro, in cui richiedi ciò che ti serve nei manifest di 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 assicurarti che siano compatibili con i cluster Autopilot, ad esempio assicurandoti che i manifest richiedano l'infrastruttura che normalmente dovresti eseguire il provisioning autonomamente.
Per preparare ed eseguire una migrazione riuscita, 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 dei carichi di lavoro in modo che siano compatibili con Autopilot.
- Esegui una prova simulata per verificare che i carichi di lavoro funzionino correttamente su Autopilot.
- Pianifica e crea il cluster Autopilot.
- Se applicabile, aggiorna gli strumenti di infrastruttura come codice.
- Esegui la migrazione.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:
- Attiva l'API Google Kubernetes Engine. Attiva l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività,
installa e poi
inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo
gcloud components update.
- Assicurati di avere già un cluster standard con carichi di lavoro in esecuzione.
- Assicurati di avere un cluster Autopilot senza carichi di lavoro per eseguire prove senza esecuzione. Per creare un nuovo cluster Autopilot, consulta Creare un cluster Autopilot.
Esegui un controllo preliminare sul cluster standard
L'interfaccia a riga di comando Google Cloud e l'API Google Kubernetes Engine forniscono uno strumento di controllo preliminare che convalida le specifiche dei carichi di lavoro standard in esecuzione per identificare le incompatibilità con i cluster Autopilot. Questo strumento è disponibile in GKE versione 1.26 e successive.
- Per utilizzare questo strumento sulla riga di comando, esegui il seguente comando:
gcloud container clusters check-autopilot-compatibility CLUSTER_NAME
Sostituisci CLUSTER_NAME con il nome del tuo cluster
standard. Se vuoi, aggiungi --format=json a questo comando per visualizzare l'output in un
file JSON.
L'output contiene i risultati relativi a tutti i carichi di lavoro standard in esecuzione, classificati e con consigli utili per garantire la compatibilità con Autopilot, se applicabile. La tabella seguente descrive le categorie:
| Risultati dello strumento di preflight | |
|---|---|
Passed |
Il carico di lavoro verrà eseguito come previsto senza alcuna configurazione necessaria per Autopilot. |
Passed with optional configuration |
Il carico di lavoro verrà eseguito in Autopilot, ma puoi apportare modifiche facoltative alla configurazione per ottimizzare l'esperienza. Se non apporti modifiche alla configurazione, Autopilot ne applica una predefinita. Ad esempio, se il carico di lavoro veniva eseguito su macchine N2 in modalità standard, GKE applica la classe di calcolo generica per Autopilot. Se vuoi, puoi modificare il carico di lavoro per richiedere la classe di calcolo 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, prendi in considerazione un contenitore che utilizza la funzionalità NET_ADMIN in Standard. Autopilot elimina questa funzionalità per impostazione predefinita per migliorare la sicurezza, pertanto 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à non supportate da Autopilot. Ad esempio, i cluster Autopilot rifiutano i pod con privilegi
( |
Modifica le specifiche del carico di lavoro in base ai risultati del preflight
Dopo aver eseguito il controllo preliminare, esamina l'output JSON e identifica i carichi di lavoro che devono essere modificati. Ti consigliamo di implementare anche i consigli 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 alla specifica 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 di infrastruttura come codice, ad esempio i grafici Helm o gli overlay Kustomize, in modo che corrispondano.
Ecco alcune modifiche di configurazione comuni che dovrai apportare:
| Modifiche di configurazione comuni per Autopilot | |
|---|---|
| Configurazione di calcolo e architettura | Per impostazione predefinita, i cluster Autopilot utilizzano il tipo di macchina serie E. Se hai bisogno di altri tipi di macchine, la specifica del carico di lavoro deve richiedere una classe di calcolo, che indica ad Autopilot di posizionare i pod su nodi che utilizzano architetture o tipi di macchine specifici. Per maggiori dettagli, consulta Classi di calcolo in Autopilot. |
| Acceleratori | I carichi di lavoro basati su GPU devono richiedere le GPU nella specifica del carico 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 su VM spot | Se i tuoi carichi di lavoro vengono eseguiti su VM spot in Standard,
richiedi i 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 staging
Dopo aver modificato ogni manifest del carico di lavoro, esegui un'esecuzione di prova su un nuovo cluster Autopilot di staging per assicurarti che il carico di lavoro funzioni 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 workload modificato.
IDE
Se utilizzi l'editor di Cloud Shell, il comando di prova secca è integrato ed eseguito su tutti i manifest aperti. Se utilizzi IDE Visual Studio Code o Intellij, installa l'estensione Cloud Code per eseguire automaticamente la simulazione su tutti i manifest aperti.
Il riquadro Problemi nell'IDE mostra eventuali problemi di prova simulata, come nell'immagine seguente che mostra una prova simulata non riuscita per un manifest che ha specificatoprivileged: true.
Pianifica il cluster Autopilot di destinazione
Quando la simulazione 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 al manifest nella sezione precedente.
Consulta le best practice per l'onboarding in GKE per i requisiti di configurazione di base. Poi, consulta la panoramica di Autopilot, che fornisce informazioni specifiche per il tuo caso d'uso a diversi livelli.
Inoltre, tieni presente quanto segue:
- I cluster Autopilot sono nativi VPC, pertanto 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 il cluster Standard, incluse eventuali regole firewall personalizzate e impostazioni VPC.
- I cluster Autopilot utilizzano GKE Dataplane V2 e supportano solo NetworkPolicies di Cilium. Le NetworkPolicies di Calico non sono supportate.
- Se vuoi utilizzare l'accesso mascherato degli IP in Autopilot, utilizza un criterio NAT in uscita.
- Specifica l'intervallo IPv4 principale per il cluster durante la creazione, con la stessa dimensione dell'intervallo del cluster standard.
- Scopri le differenze di quota tra le modalità, in particolare se hai cluster di grandi dimensioni.
- Scopri di più sui valori massimi di pod per nodo per Autopilot, che sono diversi da quelli di Standard. Questo è più importante se utilizzi spesso l'affinità dei nodi o dei pod.
- Tutti i cluster Autopilot utilizzano Cloud DNS.
Crea il cluster Autopilot
Quando è tutto pronto per creare il cluster, consulta Creare 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. Ti consigliamo di eseguire il deployment di un piccolo carico di lavoro di esempio nel cluster per attivare il provisioning automatico dei nodi in modo che i carichi di lavoro di produzione possano essere pianificati immediatamente.
Aggiorna gli strumenti di infrastruttura come codice
I seguenti provider di Infrastructure as Code supportano Autopilot:
Leggi la documentazione del fornitore che preferisci e modifica le configurazioni.
Scegli un approccio di migrazione
Il metodo di migrazione che utilizzi dipende dal tuo singolo carico di lavoro e dalla tua familiarità con i concetti di networking come i servizi multi-cluster e Ingress multi-cluster, nonché da come gestisci lo stato degli oggetti Kubernetes nel tuo cluster.
| Tipo di workload | Risultati dello strumento di preflight | Approccio alla migrazione |
|---|---|---|
| Stateless |
|
Per i carichi di lavoro |
| Stateful |
|
Utilizza uno dei seguenti metodi:
|
| Configurazione aggiuntiva richiesta | Aggiorna i manifest di Kubernetes e esegui nuovamente il deployment su Autopilot durante il tempo di riposo programmato. Per i passaggi di alto livello, consulta Eseguire manualmente la migrazione dei carichi di lavoro stateful. |
Passaggi di migrazione di alto livello
Prima di iniziare una migrazione, assicurati di aver risolto eventuali risultati Incompatible o
Additional configuration required del controllo preliminare. Se esegui il deployment dei carichi di lavoro con questi risultati su Autopilot senza modifiche, i carichi di lavoro non andranno a buon fine.
Le sezioni seguenti sono una panoramica generale di una migrazione ipotetica. I passaggi effettivi variano a seconda dell'ambiente e di ciascun carico di lavoro. Pianifica, testa e testa di nuovo i carichi di lavoro per rilevare eventuali problemi prima di eseguire la migrazione di un ambiente di produzione. Le considerazioni includono:
- La durata del processo di migrazione dipende dal numero di carichi di lavoro sottoposti a migrazione.
- Il tempo di riposo è obbligatorio durante la migrazione dei carichi di lavoro stateful.
- La migrazione manuale ti consente di concentrarti sui singoli carichi di lavoro durante la migrazione in modo da risolvere i problemi in tempo reale caso per caso.
- In ogni caso, assicurati di eseguire la migrazione di servizi, ingressi e altri oggetti Kubernetes che facilitano la funzionalità dei carichi di lavoro stateless e stateful.
Esegui la migrazione di tutti i carichi di lavoro utilizzando Backup per GKE
Se tutti i workload (con stato e senza stato) in esecuzione nel cluster standard sono compatibili con Autopilot e lo strumento di preflight restituisce Passed o Passed with optional configuration per ogni workload, puoi utilizzare Backup per GKE per eseguire il backup dell'intero stato del cluster e dei workload standard e ripristinare il backup sul cluster Autopilot.
Questo approccio presenta i seguenti vantaggi:
- Puoi spostare tutti i carichi di lavoro dall'operazione standard ad Autopilot con una configurazione minima.
- Puoi spostare i carichi di lavoro stateless e stateful e mantenere le relazioni tra i carichi di lavoro, nonché i volumi persistenti associati.
- I rollback sono intuitivi e gestiti da Google. Puoi eseguire il rollback dell'intera migrazione o di carichi di lavoro specifici in modo selettivo.
- Puoi eseguire la migrazione dei carichi di lavoro stateful tra le Google Cloud regioni. La migrazione manuale dei carichi di lavoro con stato 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
dall'utilità di preflight. Prima di eseguire la migrazione di questi carichi di lavoro, assicurati di conoscere bene i valori predefiniti.
Esegui la migrazione manuale dei carichi di lavoro stateless senza tempi di inattività
Per eseguire la migrazione dei carichi di lavoro senza stato senza tempi di inattività per i servizi, registra i cluster di origine e di destinazione in un parco risorse GKE e utilizza 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 cluster di origine e per il cluster di destinazione. Per le istruzioni, consulta Configurare i servizi multi-cluster e Configurare Ingress multi-cluster.
- Se hai dipendenze di backend, ad esempio un carico di lavoro del database, esporta i servizi dal tuo cluster standard utilizzando i servizi multi-cluster. In questo modo, i carichi di lavoro nel cluster Autopilot possono accedere alle dipendenze nel cluster standard. Per le istruzioni, consulta Registrare un servizio per l'esportazione.
- Esegui il deployment di un 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 da inviare il traffico solo al cluster standard. Per le istruzioni, consulta Deployment di Ingress in diversi cluster.
- Esegui il deployment dei carichi di lavoro stateless con manifest aggiornati nel cluster Autopilot. I servizi multi-cluster esportati corrispondono automaticamente e inviano il traffico ai carichi di lavoro stateful corrispondenti.
- Aggiorna il servizio multi-cluster per indirizzare il traffico in entrata al cluster Autopilot. Per istruzioni, consulta Selezione dei cluster.
Ora puoi pubblicare i carichi di lavoro stateless dal cluster Autopilot. Se nel cluster di origine erano presenti solo carichi di lavoro senza stato e non rimangono dipendenze, vai a Completare la migrazione. Se hai carichi di lavoro stateful, vai a Eseguire la migrazione manuale dei carichi di lavoro stateful.
Esegui la migrazione manuale dei carichi di lavoro stateful
Dopo aver eseguito la migrazione dei carichi di lavoro stateless, devi eseguire la messa in stato di riposo e la migrazione dei carichi di lavoro stateful dal cluster standard. Questo passaggio richiede il tempo di riposo del cluster.
- Avvia il tempo di riposo dell'ambiente.
- Metti in stato di attesa i carichi di lavoro stateful.
- Assicurati di aver modificato i manifest dei carichi di lavoro per la compatibilità con Autopilot. Per maggiori dettagli, consulta Modificare le specifiche del carico di lavoro in base ai risultati del pre-flight.
Esegui il deployment dei carichi di lavoro nel cluster Autopilot.
Esegui il deployment dei servizi per i tuoi carichi di lavoro stateful sul cluster Autopilot.
Aggiorna la rete all'interno del cluster per consentire ai carichi di lavoro senza stato 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, esegui il deployment dei servizi di backend, recupera il nuovo indirizzo IP e aggiorna il DNS in modo da utilizzarlo.
A questo punto, deve essere vero quanto segue:
- Esegui tutti i carichi di lavoro stateless in Autopilot.
- Anche i carichi di lavoro stateful di backend vengono eseguiti 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 workload e gli oggetti Kubernetes al nuovo cluster, procedi con Completare la migrazione.
Alternativa: esegui manualmente la migrazione di tutti i workload durante il tempo di riposo
Se non vuoi utilizzare i servizi multi-cluster e Ingress multi-cluster per eseguire la migrazione dei workload con un tempo di inattività minimo, esegui la migrazione di tutti i workload durante il tempo di inattività. Questo metodo comporta un tempo di riposo più lungo per i servizi, ma non richiede l'utilizzo di funzionalità multi-cluster.
- Avvia il tempo di riposo.
- Esegui il deployment dei manifest stateless sul cluster Autopilot.
- Esegui la migrazione manuale dei carichi di lavoro stateful. Per le istruzioni, consulta la sezione Eseguire manualmente la migrazione dei carichi di lavoro con stato.
- Modifica i record DNS sia per il traffico intra-cluster sia per quello esterno in entrata in modo da utilizzare i nuovi indirizzi IP dei servizi.
- Termina il tempo di riposo.
Completare la migrazione
Dopo aver spostato tutti i tuoi carichi di lavoro e servizi nel nuovo cluster Autopilot, termina il tempo di riposo e lascia che l'ambiente si assesti per una durata predeterminata. Quando ritieni che lo stato della migrazione sia soddisfacente e hai la certezza di non dover eseguire il rollback della migrazione, puoi ripulire gli artefatti della migrazione e completarla.
(Facoltativo) Ripulisci le funzionalità 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, svolgi i seguenti passaggi:
- Per il traffico esterno in entrata, esegui il deployment di un Ingress e impostalo sull'indirizzo IP dei servizi che espongono i tuoi carichi di lavoro. Per istruzioni, consulta Ingress per i bilanciatori del carico delle applicazioni esterni.
- Per il traffico all'interno del cluster, ad esempio dai workload frontend alle dipendenze stateful, aggiorna i record DNS del cluster in modo da utilizzare gli indirizzi IP di questi servizi.
- Elimina le risorse Ingress e Service multi-cluster che hai creato durante la migrazione.
- Disattiva Ingress e i servizi multi-cluster.
- Annulla la registrazione del cluster Autopilot dal parco risorse.
Elimina il cluster standard
Dopo che è trascorso un tempo sufficiente dal completamento della migrazione e lo stato del nuovo cluster ti soddisfa, elimina il cluster standard. Ti consigliamo di conservare i manifest standard di cui hai eseguito il backup.
Eseguire il rollback di una migrazione errata
Se riscontri problemi e vuoi ripristinare il cluster standard, esegui una delle seguenti operazioni, a seconda di come hai eseguito la migrazione:
Se hai utilizzato Backup per GKE per creare i backup durante la migrazione, ripristinali nel cluster standard originale. Per le istruzioni, consulta Ripristinare un backup.
Se hai eseguito la migrazione manuale dei carichi di lavoro, ripeti i passaggi di migrazione descritti nelle sezioni precedenti con il cluster Standard come destinazione e il cluster Autopilot come origine. In linea generale, sono previsti i seguenti passaggi:
- Avvia il tempo di riposo.
- Esegui la migrazione manuale dei carichi di lavoro stateful al cluster standard. Per le istruzioni, consulta la sezione Eseguire manualmente la migrazione dei carichi di lavoro con stato.
- Sposta i carichi di lavoro senza stato nel cluster standard utilizzando i manifest originali di cui hai eseguito il backup prima della migrazione.
- Esegui il deployment di Ingress nel cluster standard e esegui il passaggio al DNS ai nuovi indirizzi IP per i servizi.
- Elimina il cluster Autopilot.
Passaggi successivi
- Pianificare le richieste di risorse Autopilot
- Configurare il monitoraggio
- Configurare e utilizzare la dashboard della security posture