Anthos clusters on VMware ora è Google Distributed Cloud (solo software) per VMware. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Pianifica la migrazione del cluster alle funzionalità consigliate

Panoramica

Google Distributed Cloud si basa su Kubernetes e su molte altre tecnologie correlate, che vengono aggiornate e migliorate continuamente per offrire una maggiore 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 dei deployment precedenti per usufruire di 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 di 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 integrato¹ (`loadBalancer.kind: "F5BigIP"`) Altalena (`loadBalancer.kind: "Seesaw"`)
Piano di controllo del cluster di amministrazione	Cluster di amministrazione ad alta disponibilità (HA) (`adminMaster.replicas: 3`)	cluster di amministrazione non ad alta disponibilità (`adminMaster.replicas: 1`)
Control plane del cluster utente	Control plane V2 (`enableControlplaneV2: true`)	Cluster utente Kubeception (`enableControlplaneV2: false`)

^{1 BIG-IP F5 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 utenti:

Tipo di cluster	Funzionalità obsoleta	Aggiungi per il nuovo cluster	Consentire l'upgrade del cluster	Migrazione alla nuova funzionalità
Versione 1.30
Amministratore	non-HA	No	Sì	Sì
	Seesaw	No	Sì	Sì
	Big IP F5 integrato	No	Sì	Sì
Utente	Kubeception	No	Sì	Sì
	Seesaw	No	Sì	Sì
	Big IP F5 integrato	No	Sì	Sì
	Dataplane V1	No	Sì	Sì
Versione 1.29
Amministratore	non-HA	No	Sì	Sì (anteprima)
	Seesaw	No	Sì	Sì
	Big IP F5 integrato	Sì	Sì	Sì (anteprima)
Utente	Kubeception	Sì	Sì	Sì (anteprima)
	Seesaw	Sì	Sì	Sì
	Big IP F5 integrato	Sì	Sì	Sì (anteprima)
	Dataplane V1	Sì	Sì	No
Versione 1.28
Amministratore	non-HA	No	Sì	No
	Seesaw	No	Sì	Sì
	Big IP F5 integrato	Sì	Sì	No
Utente	Kubeception	Sì	Sì	No
	Seesaw	Sì	Sì	Sì
	Big IP F5 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, di seguito sono riportate le versioni in cui le funzionalità originali non sono consentite:
- Cluster di amministrazione:
  - Piano di controllo non ad alta disponibilità: 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
  - Big IP F5 integrato: 1.30 e superiore
  - Dataplane V1: 1,30 e successive
Puoi comunque eseguire l'upgrade delle campagne esistenti con le funzionalità originali.

Esegui la migrazione dei cluster utente a Dataplane V2

Puoi scegliere un'interfaccia di rete del contenitore (CNI) che offra funzionalità di rete dei contenitori, Calico o Dataplane V2. Dataplane V2, l'implementazione CNI di Google, si basa su Cilium ed è utilizzato in entrambi Google Kubernetes Engine (GKE) e Google Distributed Cloud.

Dataplane V2 offre una progettazione ottimizzata e un utilizzo efficiente delle risorse, migliorando le prestazioni di rete e la scalabilità, in particolare per cluster o ambienti di grandi dimensioni con elevate esigenze di traffico di rete. Abbiamo di eseguire la migrazione dei cluster a Dataplane V2 per le funzionalità più recenti, innovazioni e capacità di networking.

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 è progettato in modo da non comportare tempi di inattività per i carichi di lavoro esistenti. Proattivamente migrazione a Dataplane V2, puoi trarre vantaggio da:

Miglioramento delle prestazioni e della scalabilità: il design ottimizzato e l'utilizzo efficiente delle risorse di Dataplane V2 possono portare a un miglioramento delle prestazioni della rete e della scalabilità, in particolare in cluster di grandi dimensioni o in ambienti con richieste di traffico di rete elevato. Questo è dovuto all'utilizzo di EBPF anziché IPTables, che consente di scalare il cluster utilizzando le mappe BPF.
Gestione e assistenza semplificate:standardizzazione su Dataplane V2 in Google Distributed Cloud e GKE possono semplificare la gestione e la risoluzione dei problemi dei cluster, poiché puoi contare di strumenti e documentazione.
Funzionalità di networking avanzate: EgressNAT e altre funzionalità di networking avanzate sono supportate solo in Dataplane V2. Eventuali richieste di networking future verranno implementate in Dataplane V2 livello di sicurezza.

	Prima della migrazione	Dopo la migrazione
kube-proxy	Obbligatorio e di cui viene eseguito il deployment automaticamente	Non obbligatorio e di cui non è stato eseguito il deployment
Routing	kube-proxy + iptables	eBPF

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 come come F5 BIG-IP o Citrix. Utilizza "MetalLB" per il nostro 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 gruppi. Per i cluster esistenti che utilizzano l'integrato F5 Big IP o bilanciatore del carico Seesaw in bundle, forniamo guide alla migrazione per impostazioni di configurazione di "F5BigIP" in "ManualLB" ed eseguire la migrazione del bundle del carico di lavoro da Seesaw a MetalLB.

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

Pianifica di eseguire la migrazione di tutti i cluster che utilizzano F5 Big IP integrato a ManualLB. L'F5 Big IP integrato utilizza F5 BIG-IP con il bilanciatore del carico composti dai seguenti due controller:

Controller F5 (pod prefix: load-balancer-f5): riconciliazioni digita i servizi Kubernetes di LoadBalancer in ConfigMap F5 Common Controller Core Library (CCCL) formato.
F5 BIG-IP CIS Controller v1.14 (pod prefix: k8s-bigip-ctlr-deployment): converte i ConfigMap in configurazioni del bilanciatore del carico F5.

L'F5 Big IP integrato originale presenta le seguenti limitazioni:

Espressività limitata: l'IP Big F5 integrato limita la il pieno potenziale di F5 BIG-IP limitando l'espressività dei l'API Service. Questo può impedirti di configurare il controller BIG-IP per alle tue esigenze specifiche o sfruttare le funzionalità avanzate di F5 che potrebbero sono cruciali per la tua applicazione.
Componente legacy: l'implementazione attuale si basa su tecnologie meno recenti come l'API ConfigMap CCCL e CIS 1.x. Questi componenti legacy potrebbero non essere compatibili con le ultime innovazioni delle offerte di F5, con potenziali opportunità mancate di miglioramento delle prestazioni e della sicurezza.

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

	Prima della migrazione	Dopo la migrazione
Componenti degli agenti F5	Controller F5 Controller CIS OSS	Controller F5 (nessuna modifica) OSS CIS Controller (nessuna modifica)
Upgrade della versione del componente F5	Devi eseguire l'upgrade dei cluster per eseguire l'upgrade dei componenti F5. Disponibile sono limitate, come spiegato in precedenza.	Se necessario, puoi eseguire l'upgrade delle versioni dei componenti F5.
Creazione del servizio	Gestito da agenti F5	Gestito dagli agenti F5 (nessuna modifica)

Migrazione da Seesaw a MetalLB

MetalLB offre i seguenti vantaggi rispetto a Seesaw:

Gestione semplificata e riduzione delle risorse: a differenza di Seesaw, MetalLB viene eseguito direttamente sui nodi del cluster, consentendo l'uso dinamico di risorse del cluster per il bilanciamento del carico.
Assegnazione IP automatica: 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 diversi servizi possono essere eseguite su nodi diversi.
Funzionalità avanzate e a prova di futuro: lo sviluppo attivo di MetalLB e l'integrazione con il più ampio ecosistema Kubernetes lo rende un più sicura per il futuro rispetto a Seesaw. L'uso di MetalLB garantisce possono sfruttare i più recenti progressi nella tecnologia di bilanciamento del carico.

	Prima della migrazione	Dopo la migrazione
Nodi LB	VM Seesaw extra (al di fuori del cluster)	Nodi Bilanciatore del carico nel cluster con scelte del cliente
Conservazione dell'IP client	Può essere raggiunto tramite `externalTrafficPolicy: Local`	Può essere ottenuto tramite la modalità DSR DataplaneV2
Creazione del servizio	IP di servizio specificato manualmente	Indirizzo IP del servizio assegnato automaticamente dal pool di indirizzi

Esegui la migrazione dei cluster utente al piano di controllo V2 e dei cluster di amministrazione ad alta disponibilità

Il control plane consigliato per i cluster utente è Controlplane V2. Con Control Plane v2, il control plane viene eseguito su uno o più nodi nel cluster utente stesso. Con il piano di controllo legacy, chiamato kubeception, il piano di controllo 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 il control plane V2 abilitato.

A partire dalla versione 1.30, per i nuovi cluster utente è obbligatorio attivare Controlplane V2 e i nuovi cluster di amministrazione saranno ad alta disponibilità. Upgrade dei cluster utente con sono ancora supportati il piano di controllo legacy, così come gli upgrade di amministratori non ad alta disponibilità cluster.

Esegui la migrazione dei cluster utente al piano di controllo V2

In passato, i cluster utente utilizzavano kubeception. La versione 1.13 ha introdotto Controlplane V2 come funzionalità di anteprima, che è passata alla disponibilità generale nella versione 1.14. Dalla versione 1.15, Controlplane V2 è l'opzione predefinita per la creazione di utenti e Controlplane V2 è l'unica opzione nella versione 1.30.

Rispetto a kubeception, i vantaggi di Controlplane V2 includono:

Coerenza architetturale: 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 di utenti.
Separazione operativa: l'upgrade di un cluster di amministrazione non causa tempo di riposo per i cluster utente.
Separazione del deployment: puoi inserire i cluster di amministrazione e utente diversi domini di topologia o 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 esistenti. A seconda dell'ambiente vSphere sottostante, il piano di controllo e un tempo di inattività minimo durante il passaggio al piano di controllo V2. La procedura di migrazione esegue le seguenti operazioni:

Crea un nuovo piano di controllo nel cluster utente.
Copia i dati etcd dal vecchio piano di controllo.
Esegue la transizione dei nodi del pool di nodi esistenti (chiamati anche nodi worker) a il nuovo piano di controllo.

	Prima della migrazione	Dopo la migrazione
Oggetti del nodo Kubernetes del piano di controllo	Nodo del cluster di amministrazione	Nodo del cluster utente
Pod del piano di controllo Kubernetes	Statefulset/Deployment del cluster di amministrazione (spazio dei nomi del cluster utente)	Cluster utente statico pod (spazio dei nomi kube-system)
Altri pod del piano di controllo	Deployment/Statefulset/deployment del cluster di amministrazione (spazio dei nomi del cluster utente)	Deployment/statefulset del cluster utente (spazio dei nomi kube-system)
VIP control plane	Servizio bilanciatore del carico del cluster di amministrazione	keepalived + haproxy (pod statici del cluster di utenti)
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 di utenti

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

In passato, il cluster di amministrazione poteva eseguire un solo nodo del piano di controllo, il rischio intrinseco di un single point of failure. Oltre al singolo nodo del piano di controllo, i cluster di amministrazione non ad alta disponibilità hanno anche due nodi aggiuntivi. Un cluster di amministrazione ad alta disponibilità ha tre nodi del piano di controllo senza nodi aggiuntivi, pertanto 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 modello di disponibilità (HA), che è diventata l'unica opzione per i nuovi cluster nella versione 1.28.

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

Maggiore affidabilità e tempo di attività: la configurazione HA elimina il singolo punto di errore, consentendo al cluster di amministrazione di rimanere operativo anche se si verifica un problema con uno dei nodi del piano di controllo.
Esperienza di upgrade e aggiornamento migliorata: tutti i passaggi necessari per eseguire l'upgrade e l'aggiornamento di un cluster di amministrazione ora vengono eseguiti all'interno del cluster anziché in una VM di amministrazione separata. In questo modo, gli upgrade e gli aggiornamenti continuano anche se la sessione iniziale con la VM di amministrazione potrebbe essere interrotta.
Origine attendibile per gli stati del cluster: i cluster di amministrazione non HA si basano su un "file di checkpoint" out-of-band per memorizzare 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, offrendo una fonte di riferimento 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à, senza tempi di riposo per i carichi di lavoro degli utenti. La procedura causa un tempo di inattività minimo e interruzione dei cluster utente esistenti, principalmente associata al passaggio al piano di controllo. Il processo di migrazione prevede le seguenti operazioni:

Crea un nuovo piano di controllo HA.
Ripristina i dati etcd dal cluster non ad alta disponibilità esistente.
Esegue la transizione dei cluster utente al nuovo cluster di amministrazione ad alta disponibilità.

	Prima della migrazione	Dopo la migrazione
Repliche del nodo control plane	1	3
Nodi aggiuntivi	2	0
Dimensione disco dati	100 GB * 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	keepaLive + haproxy
Alloca gli 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

Esegui migrazioni di bilanciatori del carico e del piano di controllo di gruppo

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

Se hai cluster di utenti che utilizzano un vecchio CNI, devi prima eseguire la migrazione a DataPlane 2. Successivamente, puoi raggruppare la migrazione per il bilanciatore del carico dal piano di controllo. Il raggruppamento della migrazione offre i seguenti vantaggi:

Un processo più semplice: se devi eseguire la migrazione sia del piano di controllo di solito aggiorni il cluster una sola volta. Inoltre, non è necessario decidere quali funzionalità eseguire per prime.
Riduci i tempi di inattività complessivi: alcune migrazioni comportano tempi di inattività del control plane, quindi raggrupparle in un'unica operazione di aggiornamento riduce i tempi di inattività complessivi rispetto all'esecuzione di singoli aggiornamenti sequenziali.

La procedura varia a seconda delle configurazioni del cluster. In generale, esegui le migrazione per ogni cluster nel seguente ordine:

Esegui la migrazione di ogni cluster utente in modo che utilizzi il CNI consigliato, Dataplane V2.
1. Apporta le modifiche alla configurazione e aggiorna il cluster utente in attivare una migrazione del cluster utente da Calico a Dataplane V2.
  
  Nota: questo passaggio non è necessario per il cluster di amministrazione. Quando esegui l'upgrade del cluster di amministrazione alla versione 1.30, il cluster viene automaticamente è stata eseguita la migrazione a Dataplane V2.
Esegui la migrazione di ogni cluster utente in modo che utilizzi il bilanciatore del carico e Controlplane V2 consigliati.
1. Apporta modifiche alla configurazione per utilizzare il caricamento consigliato (MetalLB o ManualLB).
2. Apporta modifiche alla configurazione per abilitare il piano di controllo V2.
3. Aggiorna il cluster utente per eseguire la migrazione del bilanciatore del carico e del piano di controllo.
Esegui la migrazione del cluster di amministrazione per utilizzare il bilanciatore del carico consigliato e la disponibilità elevata del piano di controllo.
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 controllo del cluster di amministrazione dal piano non ad alta disponibilità ad alta disponibilità.
3. Aggiorna il cluster di amministrazione per eseguire la migrazione del bilanciatore del carico e del piano di controllo.
Esegui i passaggi di pulizia facoltativi, ad esempio la pulizia della VM del piano di controllo non HA.

Se il cluster di amministrazione e tutti i cluster utente sono alla versione 1.30 o puoi utilizzare il processo di migrazione dei gruppi. Per la procedura dettagliata, vedi seguenti guide: