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 è destinata 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à operativa di GKE e Confrontare GKE Autopilot e Standard.
Come funziona la migrazione
I cluster Autopilot automatizzano molte delle funzionalità e delle caratteristiche opzionali 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 molti suggerimenti di GKE. 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 assicurarti che siano compatibili con i cluster Autopilot, ad esempio assicurandoti che i manifest richiedano l'infrastruttura di cui normalmente dovresti eseguire il provisioning autonomamente.
Per preparare ed eseguire una migrazione riuscita, svolgi le seguenti attività di alto livello:
- Esegui un controllo pre-volo sul cluster Standard esistente per confermare la compatibilità con Autopilot.
- Se applicabile, modifica i manifest del workload per renderli compatibili con Autopilot.
- Esegui una prova generale per verificare che i tuoi 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à,
installala e poi
inizializza
gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione
eseguendo
gcloud components update.
- Assicurati di avere un cluster Standard esistente con carichi di lavoro in esecuzione.
- Assicurati di avere un cluster Autopilot senza workload per eseguire le prove generali. Per creare un nuovo cluster Autopilot, consulta Crea un cluster Autopilot.
Abilita il componente di controllo pre-volo nel cluster
In GKE versione 1.31.6-gke.1027000 e successive, il componente di controllo pre-volo di Autopilot è disattivato per impostazione predefinita. Devi attivare il componente di controllo preflight prima di poter eseguire il controllo in un cluster. Se il cluster esegue una versione di GKE precedente alla 1.31.6-gke.1027000, passa alla sezione successiva.
Abilita il componente di controllo preflight nel cluster:
gcloud container clusters update CLUSTER_NAME \ --location=LOCATION \ --enable-autopilot-compatibility-auditingSostituisci quanto segue:
CLUSTER_NAME: il nome del tuo cluster Standard.LOCATION: la posizione del cluster Standard, ad esempious-central1.
Il completamento dell'operazione di aggiornamento richiede fino a 30 minuti.
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 incompatibilità con i cluster Autopilot. Questo strumento è disponibile in GKE versione 1.26 e successive.
- Per utilizzare questo strumento dalla riga di comando, esegui il comando seguente:
gcloud container clusters check-autopilot-compatibility CLUSTER_NAME
Sostituisci CLUSTER_NAME con il nome del tuo cluster Standard. (Facoltativo) Aggiungi --format=json a questo comando per ottenere l'output in un file JSON.
L'output contiene i risultati per tutti i tuoi workload Standard in esecuzione, classificati e con consigli pratici per garantire la compatibilità con Autopilot, ove applicabile. La seguente tabella descrive le categorie:
| Risultati dello strumento di pre-flight | |
|---|---|
Passed |
Il workload verrà eseguito come previsto senza alcuna configurazione necessaria 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 una configurazione predefinita. Ad esempio, se il tuo workload veniva eseguito su macchine N2 in modalità Standard, GKE applica la classe di computing per uso generico 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 workload non verrà eseguito su Autopilot a meno che tu 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 devi abilitare NET_ADMIN sul cluster prima di eseguire il deployment del workload. |
Incompatibility |
Il workload non verrà eseguito su Autopilot perché utilizza funzionalità non supportate da Autopilot. Ad esempio, i cluster Autopilot rifiutano i pod privilegiati
( |
Modifica le specifiche del workload in base ai risultati del controllo preliminare
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 suggerimenti di configurazione facoltativi. Ogni risultato fornisce anche un link alla documentazione che mostra l'aspetto che dovrebbe avere la specifica del workload.
La differenza più importante tra Autopilot e Standard è che la configurazione dell'infrastruttura in Autopilot è automatizzata in base alla specifica del workload. I controlli di pianificazione di Kubernetes, come le incompatibilità e le tolleranze dei nodi, vengono aggiunti automaticamente ai workload in esecuzione. Se necessario, devi anche modificare le configurazioni di infrastruttura come codice, ad esempio i grafici Helm o le sovrapposizioni Kustomize, in modo che corrispondano.
Alcune modifiche comuni alla configurazione che dovrai apportare includono le seguenti:
| Modifiche comuni alla configurazione per Autopilot | |
|---|---|
| Configurazione di calcolo e architettura | I cluster Autopilot utilizzano il tipo di macchina della serie E per impostazione predefinita. 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 questi pod su nodi che utilizzano tipi di macchine o architetture specifici. Per i dettagli, vedi Classi di computing 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, vedi Esegui il deployment dei carichi di lavoro GPU in Autopilot. |
| Richieste di risorse | Tutti i carichi di lavoro Autopilot devono specificare i valori per
Per i dettagli, vedi Richieste di risorse in Autopilot. |
| Carichi di lavoro a tolleranza di errore sulle VM spot | Se i tuoi workload vengono eseguiti su VM spot in Standard,
richiedi pod spot nella configurazione del workload impostando un
selettore di nodi per Per maggiori dettagli, vedi Pod Spot. |
Esegui una simulazione su un cluster Autopilot di staging
Dopo aver modificato ogni manifest del workload, esegui un'implementazione di prova su un nuovo cluster Autopilot di staging per assicurarti che il workload 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 workload modificato.
IDE
Se utilizzi l'editor di Cloud Shell, il comando dry-run è integrato e viene eseguito su tutti i manifest aperti. Se utilizzi gli 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 generale, ad esempio nell'immagine seguente, che mostra una prova generale non riuscita per un manifest che specificava privileged: 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.
Utilizza le best practice per l'onboarding a GKE per i requisiti di configurazione di base. Poi, leggi 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 di VPC, pertanto non consigliamo la migrazione ad Autopilot dai 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 Cilium NetworkPolicies. Le NetworkPolicy di Calico non sono supportate.
- Se vuoi utilizzare l'accesso mascherato degli IP in Autopilot, utilizza una policy NAT in uscita.
- Specifica l'intervallo IPv4 primario per il cluster durante la creazione del cluster, con le stesse dimensioni dell'intervallo del cluster standard.
- Scopri le differenze di quota tra le modalità, soprattutto 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, utilizza Crea un cluster Autopilot. Tutti i cluster Autopilot sono regionali 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 tuo fornitore preferito e modifica le configurazioni.
Scegliere un approccio di migrazione
Il metodo di migrazione che utilizzi dipende dal tuo singolo workload e dalla tua familiarità con i concetti di networking come i servizi multi-cluster e l'ingress multi-cluster, nonché da come gestisci lo stato degli oggetti Kubernetes nel tuo cluster.
| Tipo di workload | Risultati dello strumento di pre-flight | Approccio alla migrazione |
|---|---|---|
| Stateless |
|
Per i carichi di lavoro |
| Stateful |
|
Utilizza uno dei seguenti metodi:
|
| È necessaria una configurazione aggiuntiva | Aggiorna i manifest di Kubernetes ed esegui nuovamente il deployment su Autopilot durante i tempi di inattività pianificati. Per i passaggi di alto livello, vedi Eseguire la migrazione manuale dei carichi di lavoro stateful. |
Passaggi di migrazione di alto livello
Prima di iniziare una migrazione, assicurati di aver risolto eventuali problemi Incompatible o Additional configuration required rilevati dal controllo preliminare. Se esegui il deployment dei workload con questi risultati su Autopilot senza modifiche, i workload non verranno eseguiti.
Le sezioni seguenti forniscono una panoramica generale di una migrazione ipotetica. I passaggi effettivi variano a seconda dell'ambiente e di ciascun carico di lavoro. Pianifica, testa e ritesta i workload per verificare la presenza di 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 che stai migrando.
- Il tempo di inattività è obbligatorio durante la migrazione dei carichi di lavoro stateful.
- La migrazione manuale ti consente di concentrarti sui singoli workload 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 servizi, ingress e altri oggetti Kubernetes che facilitano la funzionalità dei tuoi carichi di lavoro stateless e stateful.
Migrazione di tutti i carichi di lavoro utilizzando Backup per GKE
Se tutti i workload (stateful e stateless) 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 Standard e dei workload e ripristinare il backup sul cluster Autopilot.
Questo approccio presenta i seguenti vantaggi:
- Puoi spostare tutti i workload da Standard ad Autopilot con una configurazione minima.
- Puoi spostare carichi di lavoro stateless e stateful e conservare le relazioni tra i carichi di lavoro, nonché i PersistentVolume associati.
- I rollback sono intuitivi e gestiti da Google. Puoi eseguire il rollback dell'intera migrazione o in modo selettivo di carichi di lavoro specifici.
- Puoi eseguire la migrazione dei carichi di lavoro stateful tra le Google Cloud regioni. 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 di pre-volo. Prima di eseguire la migrazione di questi carichi di lavoro, assicurati di
trovarti a tuo agio con questi valori predefiniti.
Esegui la migrazione manuale dei carichi di lavoro stateless senza tempi di inattività
Per eseguire la migrazione dei carichi di lavoro stateless senza tempi di inattività per i tuoi 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 garantire che i tuoi carichi di lavoro rimangano disponibili durante la migrazione.
- Abilita i servizi multi-cluster e Ingress multi-cluster per il cluster di origine e il cluster di destinazione. Per istruzioni, vedi Configurazione dei servizi multi-cluster e Configurazione di Ingress multi-cluster.
- Se hai dipendenze di backend come un carico di lavoro del database, esporta questi servizi dal cluster Standard utilizzando i servizi multicluster. In questo modo, i carichi di lavoro nel cluster Autopilot possono accedere alle dipendenze nel cluster Standard. Per le istruzioni, vedi Registrare un servizio per l'esportazione.
- Esegui il deployment di un servizio 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 che invii il traffico solo al cluster Standard. Per le istruzioni, vedi Deployment di Ingress in diversi cluster.
- Esegui il deployment dei carichi di lavoro stateless con i manifest aggiornati nel cluster Autopilot. I servizi multicluster 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, vedi Selezione dei cluster.
Ora i tuoi workload stateless vengono gestiti dal cluster Autopilot. Se nel cluster di origine avevi solo carichi di lavoro stateless e non rimangono dipendenze, procedi con Completa la migrazione. Se hai carichi di lavoro stateful, vai a Migrazione manuale dei carichi di lavoro stateful.
Esegui la migrazione manuale dei carichi di lavoro stateful
Dopo aver eseguito la migrazione dei workload stateless, devi sospendere e migrare i workload stateful dal cluster Standard. Questo passaggio richiede tempi di inattività per il cluster.
- Avvia il tempo di inattività dell'ambiente.
- Metti in pausa i carichi di lavoro stateful.
- Assicurati di aver modificato i manifest del workload per la compatibilità con Autopilot. Per maggiori dettagli, vedi Modificare le specifiche del workload in base ai risultati del controllo preliminare.
Esegui il deployment dei carichi di lavoro sul cluster Autopilot.
Esegui il deployment dei servizi per i tuoi carichi di lavoro stateful sul cluster Autopilot.
Aggiorna il networking in-cluster per consentire ai tuoi workload stateless di continuare a comunicare con i workload di backend:
- Se hai utilizzato un indirizzo IP statico nei servizi di backend del cluster Standard, riutilizza questo indirizzo IP in Autopilot.
- Se consenti a Kubernetes di assegnare un indirizzo IP, esegui il deployment dei servizi di backend, ottieni il nuovo indirizzo IP e aggiorna il DNS per utilizzare il nuovo indirizzo IP.
A questo punto, devono verificarsi le seguenti condizioni:
- Stai eseguendo tutti i carichi di lavoro stateless in Autopilot.
- Anche tutti i workload stateful di backend vengono eseguiti in Autopilot.
- I tuoi 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, vai a Completa la migrazione.
Alternativa: esegui la migrazione manuale di tutti i workload durante il tempo di inattività
Se non vuoi utilizzare i servizi multi-cluster e Ingress multi-cluster per eseguire la migrazione dei workload con tempi di inattività minimi, esegui la migrazione di tutti i workload durante i tempi di inattività. Questo metodo comporta tempi di inattività più lunghi per i tuoi servizi, ma non richiede l'utilizzo di funzionalità multi-cluster.
- Inizia il periodo di inattività.
- Esegui il deployment dei manifest stateless sul cluster Autopilot.
- Esegui manualmente la migrazione dei carichi di lavoro stateful. Per istruzioni, consulta la sezione Eseguire la migrazione manuale dei carichi di lavoro stateful.
- Modifica i record DNS per il traffico interno al cluster e in entrata esterno in modo che utilizzino i nuovi indirizzi IP dei servizi.
- Termina il tempo di inattività.
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 stabilizzi per una durata predeterminata. Quando sei soddisfatto dello stato della migrazione e sei sicuro di non doverla ripristinare, puoi pulire gli artefatti della migrazione e completarla.
(Facoltativo) Pulisci le funzionalità multi-cluster
Se hai utilizzato Ingress multi-cluster e servizi multi-cluster per la migrazione e non vuoi che il cluster Autopilot rimanga registrato in un parco risorse, procedi nel seguente modo:
- 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, vedi Ingress per i bilanciatori del carico delle applicazioni esterni.
- Per il traffico intra-cluster, ad esempio dai workload frontend alle dipendenze stateful, aggiorna i record DNS del cluster in modo che utilizzino gli indirizzi IP di questi servizi.
- Elimina le risorse Ingress multi-cluster e Service 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
Dopo un periodo di tempo sufficiente dal completamento della migrazione e quando sei soddisfatto dello stato del nuovo cluster, 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 backup durante la migrazione, ripristina i backup nel cluster Standard originale. Per istruzioni, vedi Ripristinare un backup.
Se hai eseguito la migrazione manuale dei carichi di lavoro, ripeti i passaggi di migrazione nelle sezioni precedenti con il cluster Standard come destinazione e il cluster Autopilot come origine. A livello generale, ciò comporta i seguenti passaggi:
- Avvia il tempo di riposo.
- Esegui manualmente la migrazione dei carichi di lavoro stateful al cluster Standard. Per istruzioni, consulta la sezione Eseguire la 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 dell'ingresso nel cluster Standard e esegui il cutover del DNS ai nuovi indirizzi IP per i servizi.
- Elimina il cluster Autopilot.
Passaggi successivi
- Pianificare le richieste di risorse di Autopilot
- Configurare il monitoraggio
- Configurare e utilizzare la dashboard della security posture