Pianifica la migrazione del cluster alle funzionalità consigliate

Panoramica

Google Distributed Cloud si basa su Kubernetes e su molte altre tecnologie correlate, che vengono continuamente aggiornate e migliorate per fornire migliori funzionalità di scalabilità, prestazioni, sicurezza e integrazione. Di conseguenza, Google Distributed Cloud si adatta e migliora costantemente.

Nella versione 1.30, le modifiche e gli aggiornamenti hanno raggiunto un punto in cui ti consigliamo vivamente di eseguire la migrazione dei deployment legacy per sfruttare i miglioramenti significativi. Questa pagina descrive i vantaggi della migrazione dalle funzionalità obsolete alle funzionalità consigliate più recenti.

Per ogni area di funzionalità sono disponibili le seguenti opzioni:

Area della funzionalità Opzioni consigliate Opzioni originali
Container Network Interface (CNI)
  • Dataplane V2
    (enableDataplaneV2: true)
  • Dataplane V1 (Calico)
    (enableDataplaneV2: false)
Bilanciatore del carico
  • ManualLB (funziona con gli agenti F5 Big IP)
    (loadBalancer.kind: "ManualLB")
  • MetalLB
    (loadBalancer.kind: "MetalLB")
  • F5 Big IP integrato1
    (loadBalancer.kind: "F5BigIP")
  • Seesaw
    (loadBalancer.kind: "Seesaw")
Control plane del cluster di amministrazione
  • Cluster di amministrazione ad alta affidabilità (HA)
    (adminMaster.replicas: 3)
  • Cluster di amministrazione non ad alta affidabilità
    (adminMaster.replicas: 1)
Control plane del cluster utente
  • Controlplane V2
    (enableControlplaneV2: true)
  • Cluster utente Kubeception
    (enableControlplaneV2: false)

1 F5 BIG-IP integrato si riferisce a loadBalancer.kind: "F5BigIP" e alle impostazioni correlate nella sezione loadBalancer.f5BigIP del file di configurazione del cluster.

Le tabelle seguenti mostrano la matrice di supporto per queste funzionalità nei cluster di amministrazione e utente:

Tipo di cluster Funzionalità obsoleta Aggiungi per un nuovo cluster Consenti l'upgrade del cluster Migrazione alla nuova funzionalità
Versione 1.32 e successive
Amministratore Non HA No No N/D
Seesaw No No N/D
F5 Big IP integrato No No N/D
Utente Kubeception No No N/D
Seesaw No No N/D
F5 Big IP integrato No No N/D
Dataplane V1 No No N/D
Versioni 1.30 e 1.31
Amministratore Non HA No Sì Sì
Seesaw No Sì Sì
F5 Big IP integrato No Sì Sì
Utente Kubeception No Sì Sì
Seesaw No Sì Sì
F5 Big IP integrato No Sì Sì
Dataplane V1 No Sì Sì
Versione 1.29
Amministratore Non HA No Sì Sì (anteprima)
Seesaw No Sì Sì
F5 Big IP integrato Sì Sì Sì (anteprima)
Utente Kubeception Sì Sì Sì (anteprima)
Seesaw Sì Sì Sì
F5 Big IP integrato Sì Sì Sì (anteprima)
Dataplane V1 Sì Sì No
Versione 1.28
Amministratore Non HA No Sì No
Seesaw No Sì Sì
F5 Big IP integrato Sì Sì No
Utente Kubeception Sì Sì No
Seesaw Sì Sì Sì
F5 Big IP integrato Sì Sì No
Dataplane V1 Sì Sì No

Punti chiave:

  • A partire dalla versione 1.30, sono disponibili tutte le soluzioni di migrazione per eseguire la migrazione dei cluster alle alternative consigliate.

  • Quando crei nuovi cluster, ecco le versioni in cui le funzionalità originali non sono consentite:

    • Cluster di amministrazione:

      • Control plane non ad alta affidabilità: 1.28 e versioni successive
      • Bilanciamento del carico Seesaw: 1.28 e versioni successive
      • F5 Big IP integrato: 1.30 e versioni successive

    • Cluster utente:

      • Kubeception: 1.30 e versioni successive
      • Seesaw: 1.30 e versioni successive
      • F5 Big IP integrato: 1.30 e versioni successive
      • Dataplane V1: 1.30 e successive

  • Puoi comunque eseguire l'upgrade dei cluster esistenti con le funzionalità originali.

Esegui la migrazione dei cluster utente a Dataplane V2

Puoi scegliere un'interfaccia di rete container (CNI) che offre funzionalità di networking dei container, ovvero Calico o Dataplane V2. Dataplane V2, l'implementazione CNI di Google, si basa su Cilium e viene utilizzata sia in Google Kubernetes Engine (GKE) sia in Google Distributed Cloud.

Dataplane V2 offre un design ottimizzato e un utilizzo efficiente delle risorse, che si traducono in prestazioni di rete migliorate e una migliore scalabilità, in particolare per cluster di grandi dimensioni o ambienti con esigenze di traffico di rete elevate. Ti consigliamo vivamente di eseguire la migrazione dei cluster a Dataplane V2 per usufruire delle funzionalità, delle innovazioni di networking e delle capacità più recenti.

A partire dalla versione 1.30, Dataplane V2 è l'unica opzione CNI per la creazione di nuovi cluster.

La transizione da Calico a Dataplane V2 richiede pianificazione e coordinamento, ma è progettata per non comportare tempi di inattività per i workload esistenti. Eseguendo la migrazione proattiva a Dataplane V2, puoi usufruire di:

  • Prestazioni e scalabilità migliorate: il design ottimizzato e l'utilizzo efficiente delle risorse di Dataplane V2 possono migliorare le prestazioni della rete e la scalabilità, in particolare in cluster di grandi dimensioni o ambienti con un traffico di rete elevato. Questo è dovuto all'utilizzo di eBPF anziché di IPTables, che consente al cluster di scalare utilizzando le mappe BPF.

  • Gestione e assistenza semplificate: la standardizzazione su Dataplane V2 in Google Distributed Cloud e GKE può semplificare la gestione e la risoluzione dei problemi dei cluster, in quanto puoi fare affidamento su un insieme coerente di strumenti e documentazione.

  • Funzionalità di networking avanzate: EgressNAT e altre funzionalità di networking avanzate sono supportate solo su Dataplane V2. Eventuali richieste di networking future verranno implementate nel livello Dataplane V2.

Prima della migrazione Dopo la migrazione
kube-proxy Obbligatoria e con deployment automatico Non richiesto e non sottoposto a deployment
Routing kube-proxy + iptables eBPF

Rimuovi l'annotazione features.onprem.cluster.gke.io/dpv2-migration sia dalla risorsa personalizzata OnPremUserCluster sia dalla risorsa personalizzata OnPremAdminCluster (se è stata eseguita la migrazione del cluster di amministrazione da Calico durante l'upgrade dalla versione 1.29 alla 1.30) dopo aver verificato che la migrazione da Calico a Dataplane V2 è stata completata e non è necessario eseguire il rollback a Calico. La rimozione di questa annotazione prima di scalare o eseguire l'upgrade del cluster consente al controller del cluster di eliminare definitivamente i DaemonSet calico-node e calico-route-daemon inattivi. Non è necessario eseguire questo passaggio per i cluster creati con Dataplane V2 abilitato. Per saperne di più, consulta Rimuovi i DaemonSet Calico inattivi.

Esegui la migrazione del tipo di bilanciatore del carico

I tipi di bilanciatore del carico consigliati (loadBalancer.kind) sono "ManualLB" e "MetalLB". Utilizza "ManualLB" se hai un bilanciatore del carico di terze parti, ad esempio F5 BIG-IP o Citrix. Utilizza "MetalLB" per la nostra soluzione di bilanciamento del carico in bundle utilizzando il bilanciatore del carico MetalLB.

A partire dalla versione 1.30, queste sono le uniche opzioni per creare nuovi cluster. Per i cluster esistenti che utilizzano il bilanciatore del carico F5 Big IP integrato o Seesaw in bundle, forniamo guide alla migrazione per eseguire la migrazione delle impostazioni di configurazione di "F5BigIP" a "ManualLB" e per eseguire la migrazione del bilanciatore del carico in bundle da Seesaw a MetalLB.

Esegui la migrazione delle impostazioni di configurazione per il bilanciatore del carico F5 BIG-IP

Pianifica la migrazione di tutti i cluster che utilizzano F5 Big IP integrato a ManualLB. F5 BIG-IP integrato utilizza F5 BIG-IP con agenti del bilanciatore del carico, che sono costituiti dai seguenti due controller:

Il BIG-IP F5 integrato originale presenta le seguenti limitazioni:

  • Espressività limitata: l'integrazione di F5 BIG-IP limita il pieno potenziale di F5 BIG-IP limitando l'espressività dell'API Service. Ciò può impedirti di configurare il controller BIG-IP in base alle tue esigenze specifiche o di sfruttare le funzionalità avanzate di F5 che potrebbero essere fondamentali per la tua applicazione.
  • Componente legacy: l'implementazione attuale si basa su tecnologie precedenti come l'API ConfigMap CCCL e CIS 1.x. Questi componenti legacy potrebbero non essere compatibili con i progressi più recenti delle offerte di F5, il che potrebbe comportare la perdita di opportunità di miglioramento delle prestazioni e della sicurezza.

Le modifiche dopo la migrazione da BIG-IP di F5 integrato a ManualLB includono:

Prima della migrazione Dopo la migrazione
Componenti degli agenti F5
  • Controller F5
  • Controller CIS OSS
  • Controller F5 (nessuna variazione)
  • OSS CIS Controller (nessuna modifica)
Upgrade della versione del componente F5 Devi eseguire l'upgrade dei cluster per eseguire l'upgrade dei componenti F5. Le versioni dei componenti disponibili sono limitate, come spiegato in precedenza. Puoi eseguire l'upgrade delle versioni dei componenti F5 in base alle tue esigenze.
Creazione del servizio Gestite dagli agenti F5 Gestite dagli agenti F5 (nessuna modifica)

Esegui la migrazione da Seesaw a MetalLB

MetalLB offre i seguenti vantaggi rispetto a Seesaw:

  • Gestione semplificata e risorse ridotte: a differenza di Seesaw, MetalLB viene eseguito direttamente sui nodi del cluster, consentendo l'utilizzo dinamico delle risorse del cluster per il bilanciamento del carico.
  • Assegnazione automatica degli IP: il controller MetalLB gestisce gli indirizzi IP per i servizi, quindi non è necessario scegliere manualmente un indirizzo IP per ogni servizio.
  • Distribuzione del carico tra i nodi LB: le istanze attive di MetalLB per servizi diversi possono essere eseguite su nodi diversi.
  • Funzionalità avanzate e predisposizione per il futuro: lo sviluppo attivo di MetalLB e l'integrazione con l'ecosistema Kubernetes più ampio lo rendono una soluzione più predisposta per il futuro rispetto a Seesaw. L'utilizzo di MetalLB ti consente di sfruttare i progressi più recenti nella tecnologia di bilanciamento del carico.
Prima della migrazione Dopo la migrazione
Nodi LB VM Seesaw aggiuntive (all'esterno del cluster) Nodi LB nel cluster con scelte personalizzate
Conservazione dell'IP client Può essere ottenuto tramite externalTrafficPolicy: Local Può essere ottenuto tramite la modalità DSR di DataplaneV2
Creazione del servizio IP del servizio specificato manualmente IP del servizio assegnato automaticamente dal pool di indirizzi

Esegui la migrazione dei cluster utente a Controlplane V2 e dei cluster di amministrazione ad HA

Il control plane consigliato per i cluster utente è Controlplane V2. Con Controlplane V2, il control plane viene eseguito su uno o più nodi nel cluster utente stesso. Con il control plane legacy, denominato kubeception, il control plane di un cluster utente viene eseguito in un cluster di amministrazione. Per creare un cluster di amministrazione ad alta affidabilità (HA), i cluster utente devono avere Controlplane V2 abilitato.

A partire dalla versione 1.30, i nuovi cluster utente devono avere Controlplane V2 abilitato e i nuovi cluster di amministrazione saranno ad alta affidabilità. Gli upgrade dei cluster utente con il control plane legacy sono ancora supportati, così come gli upgrade dei cluster di amministrazione non ad alta affidabilità.

Esegui la migrazione dei cluster utente a Controlplane V2

Storicamente, i cluster utente utilizzavano kubeception. La versione 1.13 ha introdotto Controlplane V2 come funzionalità in anteprima, che è passata alla disponibilità generale nella versione 1.14. A partire dalla versione 1.15, il control plane V2 è l'opzione predefinita per la creazione dei cluster utente ed è l'unica opzione nella versione 1.30.

Rispetto a kubeception, i vantaggi di Controlplane V2 includono:

  • Coerenza dell'architettura: i cluster di amministrazione e i cluster utente utilizzano la stessa architettura.
  • Isolamento degli errori: un errore del cluster di amministrazione non influisce sui cluster utente.
  • Separazione operativa: un upgrade del cluster di amministrazione non causa tempi di inattività per i cluster utente.
  • Separazione del deployment: puoi inserire i cluster di amministrazione e utente in domini di topologia diversi o in più località. Ad esempio, in un modello di deployment di edge computing, un cluster utente potrebbe trovarsi in una posizione diversa rispetto al cluster di amministrazione.

Durante la migrazione, non si verifica alcun tempo di inattività per i workload dei cluster utente esistenti. A seconda dell'ambiente vSphere sottostante, il control plane subirà un tempo di inattività minimo durante il passaggio a Controlplane V2. Il processo di migrazione esegue le seguenti operazioni:

  • Crea un nuovo control plane nel cluster utente.
  • Copia i dati etcd dal vecchio control plane.
  • Esegue la transizione dei nodi del pool di nodi esistente (chiamati anche nodi worker) al nuovo control plane.
Prima della migrazione Dopo la migrazione
Oggetti nodo Kubernetes del control plane Nodo del cluster di amministrazione Nodo del cluster utente
Pod del control plane Kubernetes StatefulSet/deployment del cluster di amministrazione (namespace del cluster utente) Pod statici del cluster utente (namespace kube-system)
Altri pod del control plane StatefulSet/deployment del cluster di amministrazione (namespace del cluster utente) StatefulSet/deployment del cluster utente (namespace kube-system)
VIP control plane Servizio di bilanciamento del carico del cluster di amministrazione keepalived + haproxy (pod statici del cluster utente)
Dati etcd Volume permanente del cluster di amministrazione Disco dati
Gestione degli IP delle macchine del control plane IPAM o DHCP IPAM
Rete del control plane VLAN del cluster di amministrazione VLAN del cluster utente

Esegui la migrazione a un cluster di amministrazione ad alta affidabilità

In passato, il cluster di amministrazione poteva eseguire un solo nodo del control plane, creando un rischio intrinseco di single point of failure. Oltre al nodo del control plane, i cluster di amministrazione non ad alta disponibilità hanno anche due nodi aggiuntivi. Un cluster di amministrazione ad alta affidabilità ha tre nodi del control plane senza nodi aggiuntivi, quindi il numero di VM richieste da un nuovo cluster di amministrazione non è cambiato, ma la disponibilità è notevolmente migliorata. A partire dalla versione 1.16, puoi utilizzare un cluster di amministrazione ad alta affidabilità (HA), che è diventato l'unica opzione per la creazione di nuovi cluster nella versione 1.28.

La migrazione a un cluster di amministrazione ad alta disponibilità offre i seguenti vantaggi:

  • Affidabilità e uptime migliorati: la configurazione ad alta affidabilità elimina il single point of failure, consentendo al cluster di amministrazione di rimanere operativo anche se uno dei nodi del control plane presenta un problema.
  • Esperienza di upgrade e aggiornamento migliorata: tutti i passaggi necessari per eseguire l'upgrade e l'aggiornamento di un cluster di amministrazione vengono ora eseguiti all'interno del cluster, anziché in una workstation di amministrazione separata. In questo modo, gli upgrade e gli aggiornamenti continuano anche se la sessione iniziale della workstation di amministrazione potrebbe essere interrotta.
  • Fonte di verità affidabile per gli stati dei cluster: i cluster di amministrazione non ad alta affidabilità si basano su un "file di checkpoint" fuori banda per archiviare lo stato del cluster di amministrazione. Al contrario, il cluster di amministrazione ad alta disponibilità archivia lo stato aggiornato del cluster all'interno del cluster di amministrazione stesso, fornendo una fonte di verità più affidabile per lo stato del cluster.

Puoi scegliere di eseguire la migrazione del cluster di amministrazione non ad alta disponibilità a un cluster di amministrazione ad alta disponibilità, il che non comporta tempi di inattività per i workload degli utenti. Il processo causa tempi di inattività e interruzioni minimi per i cluster utente esistenti, principalmente associati al passaggio del control plane. Il processo di migrazione esegue le seguenti operazioni:

  • Crea un nuovo control plane ad alta affidabilità.
  • Ripristina i dati etcd dal cluster non ad alta affidabilità esistente.
  • Esegue la transizione dei cluster utente al nuovo cluster di amministrazione ad alta affidabilità.
Prima della migrazione Dopo la migrazione
Repliche del nodo control plane 1 3
Nodi aggiuntivi 2 0
Dimensione disco dati 100GB * 1 25GB * 3
Percorso dei dischi dati Impostato da vCenter.dataDisk nel file di configurazione del cluster di amministrazione Generato automaticamente nella directory: /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
VIP control plane Impostato da loadBalancer.kind nel file di configurazione del cluster di amministrazione keepalived + haproxy
Allocazione degli indirizzi IP per i nodi del control plane del cluster di amministrazione DHCP o statico, a seconda di network.ipMode.type 3 indirizzi IP statici

Migrazioni del bilanciatore del carico e del control plane del gruppo

In genere, quando aggiorni i cluster, ti consigliamo di aggiornare una sola funzionalità o impostazione alla volta. Nella versione 1.30 e successive, tuttavia, puoi raggruppare le modifiche alla configurazione per la migrazione sia del bilanciatore del carico sia del control plane, quindi aggiornare il cluster una sola volta per apportare entrambe le modifiche.

Se hai cluster utente che utilizzano una CNI precedente, devi prima eseguire la migrazione a DataPlane V2. Dopodiché, puoi raggruppare la migrazione per il bilanciatore del carico e il control plane. Il raggruppamento della migrazione offre i seguenti vantaggi:

  • Un processo più semplice: se devi eseguire la migrazione sia di un control plane sia di un bilanciatore del carico, in genere aggiorni il cluster una sola volta. Inoltre, non devi decidere quali funzionalità migrare per prime.
  • Riduci i tempi di inattività complessivi: alcune migrazioni comportano tempi di inattività del control plane, quindi il raggruppamento di queste migrazioni in un'unica operazione di aggiornamento riduce i tempi di inattività complessivi rispetto all'esecuzione di aggiornamenti individuali sequenziali.

La procedura varia a seconda delle configurazioni del cluster. In generale, esegui la migrazione per ogni cluster come descritto nei seguenti passaggi:

  1. Esegui la migrazione di ogni cluster utente per utilizzare la CNI consigliata, Dataplane V2.

    1. Apporta le modifiche alla configurazione e aggiorna il cluster utente per attivare una migrazione del cluster utente dalla precedente CNI, Calico, a Dataplane V2.

    2. Dopo aver verificato di aver completato la migrazione a Dataplane V2 e di non dover eseguire il rollback a Calico, rimuovi l'annotazione features.onprem.cluster.gke.io/dpv2-migration dalla risorsa personalizzata OnPremUserCluster (e da OnPremAdminCluster se è stata eseguita la migrazione del cluster di amministrazione da Calico durante l'upgrade dalla versione 1.29 alla 1.30). La rimozione di questa annotazione prima di scalare o eseguire l'upgrade del cluster consente al controller del cluster di eliminare definitivamente i DaemonSet calico-node e calico-route-daemon inattivi. Per istruzioni, consulta Rimuovi i DaemonSet Calico inattivi.

  2. Esegui la migrazione di ogni cluster utente dal vecchio bilanciatore del carico (LB) e dal vecchio control plane (CP) per utilizzare il bilanciatore del carico consigliato e Controlplane V2.

    1. Apporta modifiche alla configurazione per utilizzare il bilanciatore del carico consigliato (MetalLB o ManualLB).
    2. Apporta modifiche alla configurazione per abilitare Controlplane V2.
    3. Aggiorna il cluster utente per eseguire la migrazione del bilanciatore del carico e del control plane.

  3. Esegui la migrazione del cluster di amministrazione per utilizzare il bilanciatore del carico consigliato e rendere il control plane ad alta affidabilità.

    1. Apporta modifiche alla configurazione per utilizzare il bilanciatore del carico consigliato (MetalLB o ManualLB).
    2. Apporta modifiche alla configurazione per eseguire la migrazione del control plane del cluster di amministrazione da non ad alta affidabilità ad alta affidabilità.
    3. Aggiorna il cluster di amministrazione per eseguire la migrazione del bilanciatore del carico e del control plane.

  4. Esegui i passaggi di pulizia facoltativi, ad esempio la pulizia della VM del control plane non ad alta affidabilità.

Il seguente diagramma illustra i passaggi della migrazione:

Passaggi per eseguire la migrazione alle funzionalità consigliate

Se il cluster di amministrazione e tutti i cluster utente sono alla versione 1.30 o successiva, puoi utilizzare il processo di migrazione dei gruppi. Per i passaggi dettagliati, consulta le seguenti guide: