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 offrire una migliore scalabilità, prestazioni, sicurezza e funzionalità di 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 consigliamo vivamente di eseguire la migrazione delle implementazioni legacy per usufruire di miglioramenti significativi. Questa pagina descrive i vantaggi della migrazione dalle funzionalità obsolete alle funzionalità consigliate più recenti.

Per ogni area delle funzionalità, hai a disposizione le seguenti opzioni:

Area delle 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 disponibilità (HA)
    (adminMaster.replicas: 3)
  • cluster di amministrazione non HA
    (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 il nuovo cluster Consenti l'upgrade del cluster Migrazione alla nuova funzionalità
Versione 1.30 e successive
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, tutte le soluzioni di migrazione sono disponibili per migrare i 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 HA: 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 una Container Network Interface (CNI) che offre funzionalità di rete dei container, Calico o Dataplane V2. Dataplane V2, l'implementazione CNI di Google, si basa su Cilium e viene utilizzato sia in Google Kubernetes Engine (GKE) che in Google Distributed Cloud.

Dataplane V2 offre un design ottimizzato e un utilizzo efficiente delle risorse, il che si traduce in prestazioni di rete migliorate e una migliore scalabilità, in particolare per cluster di grandi dimensioni o ambienti con elevate richieste di traffico di rete. Ti consigliamo vivamente di eseguire la migrazione dei cluster a Dataplane V2 per usufruire delle funzionalità, delle innovazioni di rete 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. Se esegui la migrazione proattiva a Dataplane V2, puoi usufruire di:

  • Prestazioni e scalabilità migliorate: la progettazione ottimizzata e l'utilizzo efficiente delle risorse di Dataplane V2 possono migliorare le prestazioni di rete e la scalabilità, in particolare in cluster di grandi dimensioni o ambienti con elevate richieste di traffico di rete. Ciò è dovuto all'utilizzo di EBPF anziché IPTables, che consente lo scalabilità del cluster utilizzando le mappe BPF.

  • Gestione e assistenza semplificate:la standardizzazione di 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 Obbligatorio e distribuito automaticamente Non richiesto e non eseguito il deployment
Routing kube-proxy + iptables eBPF

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 come 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 quello in bundle di Seesaw, 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.

Migra le 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 bilanciatore del carico F5 Big-IP integrato originale presenta le seguenti limitazioni:

  • Espressività limitata: F5 Big IP integrato 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 più recenti progressi delle offerte di F5, con conseguente perdita di opportunità di miglioramento delle prestazioni e di potenziamento della sicurezza.

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

Prima della migrazione Dopo la migrazione
Componenti degli agenti F5
  • Controller F5
  • OSS CIS Controller
  • F5 Controller (nessuna modifica)
  • OSS CIS Controller (nessuna modifica)
Upgrade della versione del componente F5 Per eseguire l'upgrade dei componenti F5, devi eseguire l'upgrade dei cluster. 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 Gestito dagli agenti F5 Gestito 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 devi 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 garanzia di compatibilità futura: lo sviluppo attivo di MetalLB e l'integrazione con l'ecosistema Kubernetes più ampio lo rendono una soluzione più adatta al futuro rispetto a Seesaw. L'utilizzo di MetalLB ti consente di sfruttare i più recenti progressi nella tecnologia di bilanciamento del carico.
Prima della migrazione Dopo la migrazione
Nodi LB VM Seesaw aggiuntive (al di fuori del cluster) Nodi LB in-cluster con scelte del cliente
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 di servizio assegnato automaticamente dal pool di indirizzi

Migra i cluster utente a Controlplane V2 e i cluster di amministrazione ad alta disponibilità

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 per un cluster utente viene eseguito in un cluster di amministrazione. Per creare un cluster di amministrazione ad alta disponibilità (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 HA. Gli upgrade dei cluster utente con il control plane legacy sono ancora supportati, così come gli upgrade dei cluster di amministrazione non HA.

Esegui la migrazione dei cluster utente a Controlplane V2

Storicamente, i cluster utente hanno utilizzato kubeception. La versione 1.13 ha introdotto Controlplane V2 come funzionalità di anteprima, che è passata alla disponibilità generale nella versione 1.14. A partire dalla versione 1.15, Controlplane V2 è l'opzione predefinita per la creazione di cluster utente e Controlplane V2 è 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:l'upgrade di un 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 verificano tempi di inattività per i carichi di lavoro del cluster di utenti esistente. A seconda dell'ambiente vSphere sottostante, il control plane avrà tempi di inattività minimi durante il passaggio a Controlplane V2. La procedura 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 esistenti (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 (spazio dei nomi del cluster utente) Pod statici del cluster utente (spazio dei nomi kube-system)
Altri pod del control plane Statefulset/Deployment del cluster di amministrazione (spazio dei nomi del cluster utente) Statefulset/Deployment del cluster utente (spazio dei nomi 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 IP delle macchine del control plane IPAM o DHCP IPAM
Control Plane Network VLAN del cluster di amministrazione VLAN del cluster utente

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

Storicamente, il cluster di amministrazione poteva eseguire un solo nodo del control plane, creando un rischio intrinseco di un singolo punto di errore. Oltre al nodo del control plane, i cluster di amministrazione non ad alta disponibilità hanno anche due nodi aggiuntivi. Un cluster di amministrazione HA 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à è migliorata in modo significativo. A partire dalla versione 1.16, puoi utilizzare un cluster di amministrazione ad alta disponibilità (HA), che è diventata l'unica opzione per la creazione di nuovi cluster nella versione 1.28.

La migrazione a un cluster di amministrazione HA offre i seguenti vantaggi:

  • Maggiore affidabilità e tempo di attività:la configurazione ad alta disponibilità elimina il single point of failure, consentendo al cluster di amministrazione di rimanere operativo anche se uno dei nodi del control plane riscontra 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 nel cluster, anziché in una workstation di amministrazione separata. In questo modo, gli upgrade e gli aggiornamenti continuano anche se la sessione iniziale alla workstation di amministrazione potrebbe essere interrotta.
  • Fonte attendibile per gli stati del cluster: i cluster di amministrazione non HA si basano su un "file di checkpoint" out-of-band per archiviare lo stato del cluster di amministrazione. Al contrario, il cluster di amministrazione HA memorizza 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 HA a un cluster di amministrazione HA, che non comporta tempi di inattività per i carichi di lavoro utente. La procedura causa tempi di inattività e interruzioni minimi per i cluster utente esistenti, principalmente associati al failover del piano di controllo. La procedura di migrazione esegue le seguenti operazioni:

  • Crea un nuovo control plane HA.
  • Ripristina i dati etcd dal cluster non HA esistente.
  • Esegue la transizione dei cluster utente al nuovo cluster di amministrazione HA.
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 di gruppo e del control plane

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 piano di controllo, quindi aggiornare il cluster una sola volta per apportare entrambe le modifiche.

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

  • Un processo più semplice: se devi eseguire la migrazione di un control plane e di un bilanciatore del carico, in genere aggiorni il cluster una sola volta. Inoltre, non devi decidere quali funzionalità devi migrare per prime.
  • Riduzione dei tempi di inattività complessivi: alcune migrazioni comportano tempi di inattività del control plane, pertanto 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. Nel complesso, 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 la migrazione del cluster utente dal vecchio CNI, Calico, a Dataplane V2.

  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 e Controlplane V2 consigliati.

    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. Migra il cluster di amministrazione per utilizzare il bilanciatore del carico consigliato e per rendere il control plane a disponibilità elevata.

    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 piano di controllo del cluster di amministrazione da non HA ad HA.
    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 HA.

Il seguente diagramma illustra i passaggi della migrazione:

Passaggi per la migrazione alle funzionalità consigliate

Se il cluster di amministrazione e tutti i cluster utente hanno la versione 1.30 o successiva, puoi utilizzare la procedura di migrazione dei gruppi. Per la procedura dettagliata, consulta le seguenti guide: