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 di 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 e che richiedono la configurazione manuale nei cluster Standard. Inoltre, i cluster Autopilot applicano criteri più sicuri per le applicazioni al fine di fornire un ambiente più pronto per la produzione, e ridurre l'overhead richiesto per la gestione rispetto alla modalità Standard. I cluster Autopilot applicano molte best practice e consigli GKE per impostazione predefinita. 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 del carico di lavoro per garantirne la compatibilità Autopilot, ad esempio assicurandoti che i tuoi manifest richiedano l'infrastruttura di cui normalmente dovresti eseguire il provisioning.
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 diventino Autopilot compatibili.
- Esegui una prova per controllare che i carichi di lavoro funzionino correttamente 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 attività:
- Attiva l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività,
install e poi
inizializzare
con gcloud CLI. Se hai già installato gcloud CLI, scarica 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 delle prove. Per creare un nuovo cluster Autopilot, consulta Creare un cluster Autopilot.
Esegui un controllo preliminare sul cluster standard
Google Cloud CLI e l'API Google Kubernetes Engine forniscono un controllo pre-flight di convalida delle specifiche del deployment per identificare le incompatibilità con i cluster Autopilot. Questo è 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. Se vuoi, aggiungi --format=json a questo comando per ottenere l'output in un
JSON.
L'output contiene risultati per tutti i pod Carichi di lavoro standard, classificati e con suggerimenti strategici per garantire la compatibilità con Autopilot, ove applicabile. La tabella seguente descrive le categorie:
| Risultati dello strumento pre-flight | |
|---|---|
Passed |
Il carico di lavoro verrà eseguito come previsto, senza necessità di configurazione 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 effettui alla configurazione automatica, Autopilot applica una configurazione per te. Ad esempio, se il carico di lavoro veniva eseguito su macchine N2 in modalità standard, GKE applica la classe di calcolo generica 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 crei una una modifica alla configurazione. Considera ad esempio un container che utilizza la funzionalità NET_ADMIN in Standard. Autopilot elimina questa funzionalità per impostazione predefinita per una maggiore 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 pre-flight, segui l'output JSON e identifica carichi di lavoro che devono cambiare. Ti consigliamo di implementare anche di configurazione. 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, ad esempio le incompatibilità dei nodi e tolleranze, vengono aggiunti automaticamente ai carichi di lavoro in esecuzione. Se necessario, devi anche modificare le configurazioni Infrastructure as Code, ad esempio Helm grafici o overlay Kustomize.
Ecco alcune modifiche di configurazione comuni che dovrai apportare:
| Modifiche comuni alla configurazione per Autopilot | |
|---|---|
| Configurazione di computing 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 computing, che indica ad Autopilot di collocarle 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 tipo di macchina e acceleratori. 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, vedi Richieste di risorse in Autopilot. |
| Carichi di lavoro a tolleranza di errore su VM spot | Se i carichi di lavoro vengono eseguiti su VM spot in Standard,
richiedere pod Spot nella configurazione dei carichi di lavoro impostando
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 una nuova Autopilot per garantire 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 ed esegue su qualsiasi manifest aperto. 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 prova non mostra più problemi, pianifica e crea il nuovo 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 funzionalità di 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, considera 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 Cilium NetworkPolicies. I NetworkPolicies di Calico non sono supportati.
- Se vuoi utilizzare l'accesso mascherato degli 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 intervallo IPv4 principale per il cluster durante la creazione, con le stesse dimensioni dell'intervallo Cluster standard.
- Scopri di più sulla differenze di quota tra le modalità, soprattutto se se disponi di cluster di grandi dimensioni.
- Scopri di più sulla Numero massimo di pod per nodo per Autopilot, che sono diversi da Standard. Questo è più importante se utilizzi spesso l'affinità di nodi o 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 Infrastructure as Code supportano Autopilot:
Leggi la documentazione del tuo fornitore preferito e modifica le tue configurazioni.
Scegli un approccio di migrazione
Il metodo di migrazione che utilizzi dipende dal singolo carico di lavoro e da come a cui ti senti a tuo agio con i concetti di networking, Servizi multi-cluster e Ingress multi-cluster, e come gestire lo stato degli oggetti Kubernetes nel tuo cluster.
| Tipo di carico di lavoro | Risultati dello strumento pre-flight | Approccio alla migrazione |
|---|---|---|
| Stateless |
|
Per |
| 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 generali per la migrazione
Prima di iniziare una migrazione, assicurati di aver risolto eventuali risultati Incompatible o
Additional configuration required del controllo preliminare. Se
il deployment dei carichi di lavoro con questi risultati
su Autopilot senza modifiche,
l'arresto dei carichi di lavoro.
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 il test dei carichi di lavoro per rilevare eventuali problemi prima di eseguire la migrazione di un ambiente di produzione completamente gestito di Google Cloud. Ecco alcune considerazioni:
- La durata del processo di migrazione dipende dal numero di carichi di lavoro 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 poter 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 for GKE
Se tutti i carichi di lavoro (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 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 offre i seguenti vantaggi:
- Puoi spostare tutti i carichi di lavoro dall'operazione Standard ad Autopilot con una configurazione minima.
- Puoi 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 di carichi di lavoro specifici in modo selettivo.
- Puoi eseguire la migrazione dei carichi di lavoro con stato tra le regioni Google Cloud. Manuale La migrazione dei carichi di lavoro stateful può avvenire solo nella stessa regione.
Quando utilizzi questo metodo, GKE applica la modalità Autopilot predefinita
configurazioni ai carichi di lavoro che hanno ricevuto un Passed with optional configuration
il risultato dello strumento pre-flight. Prima di eseguire la migrazione di questi carichi di lavoro, assicurati che
che soddisfano le tue esigenze.
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 tuoi servizi, devi registrarti tra i cluster di origine e di destinazione Parco risorse GKE e utilizzare i servizi multi-cluster e Ingress multi-cluster per assicurarti rimangono disponibili durante la migrazione.
- Abilita servizi multi-cluster e Ingress multi-cluster per la tua origine cluster e nel 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, esportale Servizi del tuo cluster Standard mediante servizi multi-cluster. In questo modo, i carichi di lavoro nel cluster Autopilot possono accedere alle dipendenze nel cluster standard. Per istruzioni, vedi Registrazione di un Servizio per l'esportazione.
- Esegui il deployment di una risorsa Ingress multi-cluster e di un servizio multi-cluster per controllare del 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 tuoi 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 Autopilot. Per istruzioni, consulta Selezione dei cluster.
Ora gestisci i tuoi carichi di lavoro stateless dal cluster Autopilot. Se avessi solo carichi di lavoro stateless nel cluster di origine e nessuna dipendenza rimanenti, vai a Completa la migrazione. Se disponi per i carichi di lavoro stateful, procedi 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 eseguire la messa in stato di riposo e la migrazione dei carichi di lavoro stateful dal cluster standard. Questo passaggio richiede per il tuo 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 Autopilot la compatibilità. Per maggiori dettagli, vedi Modifica le specifiche del carico di lavoro in base ai risultati precedenti al periodo di pubblicazione.
Esegui il deployment dei carichi di lavoro nel cluster Autopilot.
Esegui il deployment dei servizi per i carichi di lavoro stateful sul cluster Autopilot.
Aggiorna la rete all'interno del 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 nel backend del cluster Standard Services, riutilizza l'indirizzo IP 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:
- Stai eseguendo tutti i tuoi 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 tuo Autopilot.
Dopo aver eseguito la migrazione di tutti i carichi di lavoro e gli oggetti Kubernetes al nuovo cluster, procedi con Completare la migrazione.
Alternativa: esegui manualmente la migrazione di tutti i carichi di lavoro durante il tempo di riposo
Se non vuoi utilizzare i servizi multi-cluster e Ingress multi-cluster per esegui la migrazione dei carichi di lavoro con tempi di inattività minimi, o un tempo di inattività. Questo metodo comporta tempi di inattività più lunghi per i tuoi servizi, ma richiedono l'uso di caratteristiche multi-cluster.
- Inizia il tuo tempo di riposo.
- Esegui il deployment dei manifest stateless sul cluster Autopilot.
- Esegui la migrazione manuale dei carichi di lavoro stateful. Per istruzioni, vedi Sezione Eseguire manualmente la migrazione dei carichi di lavoro stateful.
- 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 tuo tempo di riposo.
Completare la migrazione
Dopo aver spostato tutti i carichi di lavoro e i servizi nella nuova modalità Autopilot un cluster, terminare il tempo di inattività e consentire al tuo ambiente di 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 elementi della migrazione e completarla.
(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, 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, vedi In entrata per bilanciatori del carico delle applicazioni esterni.
- Per il traffico all'interno del cluster, ad esempio dai carichi di lavoro 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. Me 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, uno dei seguenti, 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 istruzioni, vedi Ripristinare un backup.
Se hai eseguito la migrazione manuale dei carichi di lavoro, ripeti i passaggi della migrazione precedente in cui il cluster Standard è la destinazione Autopilot come origine. In linea generale, sono previsti i seguenti passaggi:
- Avvia il tempo di riposo.
- Esegui manualmente la migrazione dei carichi di lavoro stateful nel cluster Standard. Per istruzioni, consulta le Sezione Migrazione manuale dei carichi di lavoro stateful.
- 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
- Configura e utilizza la dashboard della security posture