Questa pagina fornisce considerazioni e consigli che ti aiuteranno a: di eseguire la migrazione dei carichi di lavoro dai cluster Google Kubernetes Engine (GKE) standard Autopilot con interruzioni minime dei tuoi servizi. Questa pagina è rivolto agli amministratori di cluster che hanno già deciso di eseguire la migrazione a Autopilot. Se hai bisogno di ulteriori informazioni prima di decidere di eseguire la migrazione, vedi Scegli una modalità operativa GKE e Confronta 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 di GKE per impostazione predefinita. Autopilot usa un modello di attribuzione di configurazione di Kubernetes, in cui richiedi ciò di cui hai bisogno nel tuo 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 correttamente una migrazione, segui questi passaggi di alto livello:
- Esegui un controllo pre-flight sul cluster Standard esistente per per verificare 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 i tuoi strumenti Infrastructure as Code.
- 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 un cluster Standard esistente con esecuzione carichi di lavoro con scale out impegnativi.
- Assicurati di avere un cluster Autopilot senza carichi di lavoro per eseguire delle prove. Per creare un nuovo cluster Autopilot, Crea un cluster Autopilot.
Esegui un controllo pre-flight sul cluster Standard
Google Cloud CLI e l'API Google Kubernetes Engine forniscono un controllo pre-flight di convalida delle specifiche dei carichi di lavoro 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 standard
in un cluster Kubernetes. 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. Le seguenti vengono descritte 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 su Autopilot, ma puoi rendere facoltativo modifiche 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 era in esecuzione su macchine N2 in In modalità Standard, GKE applica la classe di computing 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 È stata migliorata la sicurezza, quindi dovrai abilitare NET_ADMIN nel cluster prima di eseguire il deployment del carico di lavoro. |
Incompatibility |
Il carico di lavoro non verrà eseguito su Autopilot perché utilizza 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 precedenti al periodo di pubblicazione
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 documentazione che mostra l'aspetto della specifica del carico di lavoro.
La differenza più importante tra Autopilot e Standard è che la configurazione dell'infrastruttura in Autopilot è automatizzata in base la 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.
Alcune modifiche comuni alla configurazione da apportare includono i seguenti seguenti:
| Modifiche comuni alla configurazione per Autopilot | |
|---|---|
| Configurazione di computing e architettura | I cluster Autopilot utilizzano il tipo di macchina E-Series predefinito. 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, vedi Esegui il deployment dei carichi di lavoro GPU in Autopilot. |
| Richieste di risorse | Tutti i carichi di lavoro Autopilot devono specificare valori per
Per maggiori dettagli, vedi Richieste di risorse in Autopilot. |
| Carichi di lavoro a tolleranza di errore sulle VM spot | Se i carichi di lavoro vengono eseguiti su VM spot in Standard,
per richiedere i pod Spot nella configurazione del carico di lavoro impostando
selettore di nodi per Per maggiori dettagli, vedi 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 della modifica
del carico di lavoro.
IDE
Se utilizzi l'editor di Cloud Shell, il comando dry-run è integrato ed esegue 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 e i file manifest.
Il riquadro Problemi nell'IDE mostra eventuali problemi di prova, ad esempio
l'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 Autopilot per i tuoi carichi di lavoro. Questo cluster è diverso Cluster Autopilot che hai utilizzato per testare le modifiche del manifest nella sezione precedente.
Utilizza le funzionalità di Best practice per l'onboarding in GKE per i requisiti di configurazione di base. Poi leggi le Panoramica di Autopilot, che fornisce informazioni specifiche per il tuo caso d'uso su diversi livelli.
Inoltre, considera quanto segue:
- I cluster Autopilot sono nativi di VPC, consiglia di eseguire la migrazione ad Autopilot da un modello Standard basato su route cluster.
- Usa lo stesso VPC o un VPC simile per Autopilot cluster e il cluster Standard, incluse eventuali regole firewall personalizzate e le 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, usa Criterio NAT in uscita.
- Se hai un cluster Standard privato, crea 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, usa Crea un cluster Autopilot. Tutti i cluster Autopilot sono a livello di regione e vengono registrati automaticamente in un canale di rilascio, sebbene sia possibile specificare il canale e la versione del cluster. Me consiglia di eseguire il deployment di un piccolo carico di lavoro di esempio nel cluster per attivare il nodo il provisioning automatico 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 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 Kubernetes ed esegui di nuovo il deployment su Autopilot durante il tempo di inattività pianificato. Per conoscere i passaggi dettagliati, vedi Eseguire manualmente la migrazione dei carichi di lavoro stateful. |
Passaggi generali per la migrazione
Prima di iniziare una migrazione, assicurati di aver risolto eventuali Incompatible o
Additional configuration required risultati del controllo pre-flight. Se
il deployment dei carichi di lavoro con questi risultati
su Autopilot senza modifiche,
l'errore 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 i 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.
- Durante 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 ogni caso, assicurati di eseguire la migrazione di servizi, risorse in entrata e altre Oggetti Kubernetes che facilitano la funzionalità dei tuoi oggetti carichi di lavoro 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 in
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
eseguire il backup dell'intero stato del cluster e dei carichi di lavoro standard
e ripristinare il backup nel cluster Autopilot.
Questo approccio offre i seguenti vantaggi:
- Puoi spostare tutti i carichi di lavoro 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 e gli oggetti PersistentVolume associati.
- I rollback sono intuitivi e gestiti da Google. Puoi eseguire il rollback o eseguire il rollback selettivo di carichi di lavoro specifici.
- Puoi eseguire la migrazione dei carichi di lavoro stateful tra regioni Google Cloud. Manuale La migrazione dei carichi di lavoro stateful può avvenire solo nella stessa regione.
Quando usi 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 ritieni di poter utilizzare queste 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 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 istruzioni, vedi Configurazione di servizi multi-cluster e Configurazione di 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. Ciò consente ai carichi di lavoro nel tuo cluster Autopilot di accedere delle 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 per di inviare traffico solo al cluster Standard. Per istruzioni, vedi Deployment di Ingress in diversi cluster.
- Esegui il deployment dei carichi di lavoro stateless con manifest aggiornati 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, vedi Selezione del 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 uscire ed eseguire la migrazione per i 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 sul tuo cluster Autopilot.
Esegui il deployment dei servizi per i carichi di lavoro stateful su Autopilot in un cluster Kubernetes.
Aggiorna il networking in-cluster per consentire ai carichi di lavoro stateless di continuare per 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 tuoi servizi di backend, ottenere il nuovo indirizzo IP e 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 tuo Autopilot.
Dopo aver migrato tutti i carichi di lavoro e gli oggetti Kubernetes nel nuovo cluster, procedi a Completare 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 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 nel cluster Autopilot.
- Esegui manualmente la migrazione dei carichi di lavoro stateful. Per istruzioni, vedi Sezione Eseguire manualmente la migrazione dei carichi di lavoro stateful.
- Modifica i record DNS per il traffico intra-cluster e esterno in entrata verso usano 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 una durata predeterminata. Se lo stato della migrazione ti soddisfa e sei sicuro di non dover eseguire il rollback della migrazione, puoi eseguire la gli artefatti di migrazione 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 che il cluster Autopilot rimanga registrato in un parco risorse, le seguenti:
- 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 istruzioni, vedi In entrata per bilanciatori del carico delle applicazioni esterni.
- Per il traffico tra cluster, ad esempio dai carichi di lavoro frontend allo stato stateful , aggiorna i record DNS del cluster in modo che utilizzino i relativi indirizzi IP Servizi.
- Elimina la risorsa Ingress multi-cluster e 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
Una volta trascorso un periodo di tempo sufficiente dopo il completamento della migrazione, se sarà tutto soddisfacente con lo stato del nuovo cluster, 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 backup durante la migrazione, e ripristinare 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 della migrazione precedente in cui il cluster Standard è la destinazione Autopilot come origine. A livello generale, ciò comporta 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 stateless nel cluster Standard utilizzando 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