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"`)
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 di utenti 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 dell'utente:

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ì
	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, di seguito sono riportate le versioni in cui le funzionalità originali non sono consentite:
- Cluster di amministrazione:
  - Control plane 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 di utenti:
  - 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 versioni 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 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 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, in modo da migliorare le prestazioni della rete e la scalabilità, in particolare per cluster di grandi dimensioni o ambienti con richieste di traffico di rete elevato. Ti consigliamo vivamente di eseguire la migrazione dei cluster a Dataplane 2 per usufruire delle funzionalità, delle innovazioni e delle funzionalità di rete 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 carichi di lavoro esistenti. Eseguendo la migrazione in modo proattivo a Dataplane V2, puoi usufruire di:

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:la standardizzazione su Dataplane V2 su 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 rete avanzate: EgressNAT e altre funzionalità di rete avanzate sono supportate solo in Dataplane V2. Eventuali richieste di networking future verranno implementate nel livello Dataplane V2.

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

Esegui la migrazione del tipo di bilanciatore del carico

I tipi di bilanciatori 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 che utilizza 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 F5 Big IP integrato o il bilanciatore del carico 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 di eseguire la migrazione di tutti i cluster che utilizzano F5 Big IP integrato a ManualLB. F5 Big IP integrato utilizza F5 BIG-IP con agenti bilanciatore del carico, costituiti dai seguenti due controller:

Controller F5 (pod prefix: load-balancer-f5): riconcilia i servizi Kubernetes di tipo LoadBalancer nel formato ConfigMap della libreria di base del controller comune F5 (CCCL).
F5 BIG-IP CIS Controller v1.14 (pod prefix: k8s-bigip-ctlr-deployment): traduce i ConfigMap in configurazioni del bilanciatore del carico F5.

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

Espressività limitata: F5 Big IP integrato limita il potenziale dell'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 meno recenti come l'API ConfigMap CCCL e CIS 1.x. Questi componenti legacy potrebbero non essere compatibili con le ultime novità delle offerte di F5, con il rischio di perdere opportunità di miglioramento delle prestazioni e 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	Controller F5 (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)

Eseguire 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 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 adattabilità al futuro: lo sviluppo attivo di MetalLB e la sua integrazione con l'ecosistema Kubernetes più ampio lo rendono una soluzione più adattabile al futuro rispetto a Seesaw. L'utilizzo di MetalLB ti consente di usufruire degli ultimi progressi della tecnologia di bilanciamento del carico.

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

Esegui la migrazione dei cluster utente a Control Plane v2 e dei cluster di amministrazione ad HA

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 control plane precedente, 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 il control plane V2 abilitato.

A partire dalla versione 1.30, per i nuovi cluster utente è obbligatorio attivare il control plane V2 e i nuovi cluster di amministrazione saranno ad alta disponibilità. Gli upgrade dei cluster utente con il piano di controllo precedente sono ancora supportati, così come gli upgrade dei cluster amministrativi non HA.

Esegui la migrazione dei cluster utente a Controlplane 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 cluster di utenti ed è l'unica opzione disponibile 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 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 in diversi domini di topologia 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 esistenti. A seconda dell'ambiente vSphere sottostante, il piano di controllo subirà un tempo di riposo minimo durante il passaggio al control plane 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) al 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)	Pod statici del cluster utente (spazio dei nomi kube-system)
Altri pod del piano di controllo	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 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, creando un rischio intrinseco di un singolo punto di défaillance. 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 cluster di amministrazione ad alta disponibilità (HA), che è diventato l'unica opzione per la creazione di 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 workstation di amministrazione separata. In questo modo, gli upgrade e gli aggiornamenti continuano anche se la sessione iniziale con la workstation 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 HA memorizza lo stato aggiornato del cluster all'interno del cluster di amministrazione stesso, fornendo 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. La procedura di migrazione esegue le seguenti operazioni:

Crea un nuovo piano di controllo 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 del 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
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. Dopodiché, puoi raggruppare la migrazione per il bilanciatore del carico e il piano di controllo. Il raggruppamento della migrazione offre i seguenti vantaggi:

Una procedura più semplice: se devi eseguire la migrazione sia di un piano di controllo sia di un bilanciatore del carico, in genere aggiorni il cluster una sola volta. Inoltre, non è necessario decidere quali funzionalità eseguire per prime.
Riduci il tempo di riposo complessivo: alcune migrazioni comportano un tempo di riposo del control plane, quindi raggrupparle in un'unica operazione di aggiornamento riduce il tempo di riposo complessivo rispetto all'esecuzione di singoli aggiornamenti sequenziali.

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

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 per 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, viene eseguita automaticamente la migrazione del cluster 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 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 piano di controllo.
Esegui la migrazione del cluster di amministrazione in modo da utilizzare il bilanciatore del carico consigliato e rendere il control plane altamente disponibile.
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 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 superiore, puoi utilizzare la procedura di migrazione dei gruppi. Per la procedura dettagliata, consulta le seguenti guide: