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.

Esegui la migrazione di un cluster utente alle funzionalità consigliate

Panoramica

Questa pagina mostra come eseguire la migrazione dei cluster utente della versione 1.30 o successive alle seguenti funzionalità consigliate:

Esegui la migrazione a Dataplane V2 come interfaccia di rete del contenitore (CNI).
Esegui la migrazione dei cluster utente che utilizzano kubeception a Controlplane v2.
Esegui la migrazione della configurazione del bilanciatore del carico:
- Dalla configurazione del bilanciatore del carico F5 BIG-IP integrato a ManualLB
  
  o
- Dal bilanciatore del carico Seesaw in bundle a MetalLB.

Questa pagina è rivolta agli amministratori IT e agli operatori che gestiscono il ciclo di vita dell'infrastruttura tecnologica di base. Per informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Best practice

Ti consigliamo di eseguire prima la migrazione dell'ambiente meno critico, ad esempio quello di test. Dopo aver verificato che la migrazione sia riuscita, ripeti questa procedura per ogni ambiente, eseguendo per ultimo quello di produzione. In questo modo puoi verificare il buon esito di ogni migrazione e assicurarti che i carichi di lavoro vengano eseguiti correttamente, prima di passare all'ambiente più critico successivo.

Ti consigliamo di creare un nuovo cluster utente con Controlplane V2 abilitato per conoscere le differenze di architettura con i cluster kubeception. Il nuovo cluster non influisce sui tuoi carichi di lavoro. Tuttavia, nella peggiore delle ipotesi, se la migrazione non va a buon fine, hai un cluster pronto per i tuoi carichi di lavoro.

Per ulteriori informazioni sulla pianificazione della migrazione, consulta Pianificare la migrazione del cluster alle funzionalità consigliate.

Requisiti

Per questa migrazione:

Il cluster utente deve essere almeno della versione 1.30.
Tutti i pool di nodi devono avere la stessa versione del cluster utente.
Se il cluster utilizza il bilanciatore del carico Seesaw, assicurati di non fare affidamento su Seesaw per la conservazione dell'IP del client come descritto nella sezione successiva.

Conservazione dell'IP client Seesaw

Per controllare externalTrafficPolicy, esegui il seguente comando:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

Se riscontri questo problema, contatta l'Assistenza Google.

Stimare l'impegno in termini di tempo e pianificare un periodo di manutenzione

Quando aggiorni il cluster, per impostazione predefinita tutti i pool di nodi vengono aggiornati in parallelo. Tuttavia, all'interno di ogni pool di nodi, i nodi vengono aggiornati in sequenza. Pertanto, la durata totale dell'aggiornamento dipende dal numero di nodi nel pool di nodi più grande. Per calcolare una stima approssimativa per ogni aggiornamento:

Se esegui la migrazione da Seesaw a MetalLB, stima 15 minuti per l'aggiornamento per scegliere un pool di nodi per il bilanciatore del carico MetalLB. Per questo aggiornamento, viene aggiornato solo il pool di nodi selezionato.
Per qualsiasi altro aggiornamento nel processo di migrazione, moltiplica 15 minuti per il numero di nodi nel pool di nodi.

Per stimare l'impegno in termini di tempo, conteggia il numero di volte che devi aggiornare il cluster. I seguenti passaggi di alto livello mostrano quando devi eseguire gkectl update cluster per aggiornare il cluster:

Se il cluster di utenti utilizza la crittografia dei secret sempre attiva, disattiva la funzionalità ed esegui gkectl update cluster.
Se il cluster utente ha enableDataplaneV2 non impostato o impostato su false, apporta le modifiche alla configurazione, quindi esegui gkectl update cluster per eseguire la migrazione a Dataplane 2.
Preparati per la migrazione del bilanciatore del carico e del piano di controllo:
1. Se nel cluster di amministrazione è stata attivata la riparazione automatica, disattivala. Poi esegui gkectl update admin. Questo aggiornamento termina rapidamente perché non ricrea i nodi del cluster amministrativo.
2. Se il cluster utente utilizza Seesaw, scegli un pool di nodi da utilizzare per il bilanciatore del carico MetalLB, quindi esegui gkectl update cluster. Questo aggiornamento aggiorna solo i nodi nel pool di nodi selezionato.
Apporta tutte le modifiche di configurazione necessarie per aggiornare il bilanciatore del carico e per eseguire la migrazione a Controlplane 2. Poi esegui gkectl update cluster.
Dopo la migrazione, se hai disattivato la crittografia dei secret sempre attiva, riattiva la funzionalità ed esegui gkectl update cluster.

Il tempo totale della migrazione dipende dal numero di volte che devi eseguire gkectl cluster update, che dipende dalla tua configurazione. Ad esempio, supponiamo che tu stia eseguendo la migrazione a Dataplane V2, ControlPlane V2 e MetalLB. Supponiamo inoltre che ci siano 10 nodi nel pool di nodi più grande e 3 nel node pool che verrà utilizzato da MetalLB. Per calcolare una stima del tempo di migrazione, aggiungi quanto segue:

150 minuti per la migrazione a Dataplane V2 perché 15 minuti * 10 nodi nel pool più grande = 150 minuti.
45 minuti per il pool di nodi utilizzato da MetalLB perché 15 minuti * 3 nodi in quel pool di nodi = 45 minuti.
150 minuti per l'aggiornamento di Controlplane V2 e MetalLB perché 15 minuti * 10 nodi nel pool più grande = 150 minuti.

Il tempo totale della migrazione è di circa 345 minuti, ovvero 5 ore e 45 minuti.

Se necessario, puoi eseguire la migrazione in più fasi. Utilizzando l'esempio precedente, puoi eseguire la migrazione a Dataplane V2 in una periodo di manutenzione ed eseguire il resto della migrazione in una o due finestre di manutenzione.

Pianificare il tempo di riposo durante la migrazione

Quando pianifichi la migrazione, tieni conto di questi tipi di tempi di riposo:

Tempo di riposo del piano di controllo: l'accesso al server dell'API Kubernetes è interessato durante la migrazione. Se esegui la migrazione a Controlplane v2, si verifica un tempo di riposo del piano di controllo per i cluster utente kubeception durante la migrazione di loadBalancer.vips.controlPlaneVIP. In genere, il tempo di riposo è inferiore a 10 minuti, ma la durata dipende dall'infrastruttura.
Tempo di riposo del carico di lavoro: gli indirizzi IP virtuali (VIP) utilizzati dai servizi di tipo LoadBalancer non sono disponibili. Questo accade solo durante una migrazione da Seesaw a MetalLB. La procedura di migrazione di MetalLB interromperà le connessioni di rete a tutti i VIP nel cluster utente per i servizi Kubernetes di tipo LoadBalancer per circa 2-10 minuti. Al termine della migrazione, le connessioni funzioneranno di nuovo.

La tabella seguente descrive l'impatto della migrazione:

Da	A	Accesso all'API Kubernetes	Workload utente
Cluster Kubeception che utilizza Calico, con `enableDataplaneV2` non impostato o impostato su `false`	Cluster Kubeception con Dataplane V2	Non interessato	Non interessato
Cluster Kubeception, in cui `enableControlplaneV2` non è impostato o è impostato su `false` con `MetalLB` o `ManualLB`	Cluster Control Plane V2 con lo stesso tipo di bilanciatore del carico	Interessato	Non interessato
Cluster Kubeception con `loadBalancer.kind: "F5BigIP"`	Cluster Controlplane V2 con configurazione del bilanciatore del carico manuale	Interessato	Non interessato
Cluster Kubeception con `loadBalancer.kind: "Seesaw"`	Cluster Control Plane V2 con MetalLB	Interessato	Interessato

Affetta: si è verificata un'interruzione del servizio significativa durante la migrazione.
Non interessato: non si verificano interruzioni del servizio o sono quasi impercettibili.

Prepararsi per la migrazione

Per garantire una migrazione riuscita, segui i passaggi descritti nelle sezioni seguenti.

Alloca nuovi indirizzi IP

Se esegui la migrazione a Controlplane 2, alloca nuovi indirizzi IP statici nella stessa VLAN dei nodi worker (i nodi nei node pool).

Devi avere un indirizzo IP per il loadBalancer.vips.controlPlaneVIP.
Assegna un indirizzo IP per ogni nodo del piano di controllo. Il numero di indirizzi IP da allocare dipende dal fatto che il cluster di utenti sia ad alta disponibilità (HA) o meno.
- Non HA: un indirizzo IP
- HA: tre indirizzi IP

Aggiorna le regole firewall

Se esegui la migrazione a Controlplane 2, aggiorna le regole del firewall sui tuoi cluster dell'utente. Assicurati che gli indirizzi IP appena allocati per i nodi del piano di controllo nel cluster utente possano raggiungere tutte le API e le altre destinazioni richieste, come descritto in Nodi del cluster utente delle regole firewall.

Controllare le versioni del cluster e del pool di nodi

Verifica che tutti i node pool utilizzino la stessa versione del cluster utente, che deve essere almeno la 1.30. In caso contrario, esegui l'upgrade dei pool di nodi alla versione gkeOnPremVersion nel file di configurazione del cluster utente prima di continuare con la migrazione. Per controllare le versioni, esegui il seguente comando:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

Controlla l'integrità del cluster

Controlla l'integrità del cluster e risolvi eventuali problemi segnalati dal comando gkectl diagnose cluster:

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name <var>USER_CLUSTER_NAME</var>

Sostituisci quanto segue:

ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
USER_CLUSTER_NAME: il nome del cluster di utenti.

Disattiva la riparazione automatica nel cluster di amministrazione

Se esegui la migrazione del cluster utente per utilizzare Controlplane v2 e la riparazione automatica è attivata nel cluster di amministrazione, disattiva la riparazione automatica. Controlla il campo autoRepair.enabled del file di configurazione del cluster di amministrazione. Se il campo non è impostato o è impostato su true, segui questi passaggi:

Nel file di configurazione del cluster di amministrazione, imposta autoRepair.enabled su false . Ad esempio:
```
autoRepair:
  enabled: true
```

Aggiorna il cluster di amministrazione:

gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG

Sostituisci quanto segue:

ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
ADMIN_CLUSTER_CONFIG: il percorso del file di configurazione del cluster di amministrazione.

Al termine della migrazione, assicurati di riattivare la riparazione automatica nel cluster di amministrazione.

Verificare la presenza di un problema con la crittografia dei secret sempre attiva

Se esegui la migrazione del cluster utente per utilizzare Controlplane 2, controlla se è presente un problema con la crittografia delle chiavi sempre attive.

Se la crittografia dei secret sempre attiva è stata attivata nel cluster di utenti, devi seguire la procedura descritta in Disattivare la crittografia dei secret sempre attiva e decriptare i secret prima di iniziare la migrazione. In caso contrario, il nuovo cluster Controlplane V2 non è in grado di decriptare i secret.

Prima di avviare la migrazione, esegui il seguente comando per verificare se la crittografia dei secret sempre attiva è stata attivata in un determinato momento:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

Se l'output del comando precedente è vuoto, significa che la crittografia dei secret sempre attiva non è mai stata attivata. Puoi avviare la migrazione.

Se l'output del comando precedente non è vuoto, significa che la crittografia dei secret sempre attiva è stata abilitata in precedenza. Prima della migrazione, devi svolgere i passaggi descritti nella sezione successiva per assicurarti che il nuovo cluster Controlplane V2 possa decriptare i secret.

L'esempio seguente mostra un output non vuoto:

{"generatedKeyVersions":{"keyVersions":[1]}}

Disattiva la crittografia dei secret sempre attiva e decripta i secret, se necessario

Per disattivare la crittografia dei secret sempre attiva e decriptare i secret, svolgi i seguenti passaggi:

Nel file di configurazione del cluster utente, per disattivare la crittografia dei secret sempre attivi, aggiungi un campo disabled: true alla sezione secretsEncryption:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
Aggiorna il cluster:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Sostituisci quanto segue:
- ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione
- USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente

Esegui un aggiornamento in sequenza su un DaemonSet specifico come segue:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

Recupera i manifest di tutti i secret nel cluster utente in formato YAML:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml

Affinché tutti i secret vengano archiviati in etcd in testo non cifrato, riapplica tutti i secret nel cluster utente:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Ora puoi iniziare la migrazione a Controlplane V2. Al termine della migrazione, puoi riattivare la crittografia dei secret sempre attiva sul cluster.

Abilita un pool di nodi per l'utilizzo da parte di MetalLB

Se esegui la migrazione dal bilanciatore del carico Seesaw in bundle a MetalLB, svolgi i passaggi di questa sezione. Il cluster utilizza Seesaw se loadBalancer.kind: Seesaw è presente nel file di configurazione del cluster utente. Se esegui la migrazione della configurazione di F5 BIG-IP integrata, vai alla sezione successiva Eseguire la migrazione a Dataplane v2.

Scegli un pool di nodi e abilitalo per l'utilizzo con MetalLB. La migrazione implementa MetalLB sui nodi del pool di nodi.

Nella sezione nodePools del file di configurazione del cluster di utenti, scegli un pool di nodi o aggiungi un nuovo pool di nodi e imposta enableLoadBalancer su true. Ad esempio:
```
nodePools:
  - name: pool-1
    replicas: 3
    enableLoadBalancer: true
```

Aggiorna il cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Per ulteriori informazioni su MetalLB, consulta Bilanciamento del carico in bundle con MetalLB.

Esegui la migrazione a Dataplane V2

Prima di eseguire la migrazione, controlla se DataPlane V2 è abilitato sul cluster eseguendo il seguente comando:

kubectl —kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -o yaml | grep enableDataplaneV2

Se Dataplane V2 è già attivato, vai alla sezione successiva Prepararsi alla migrazione del bilanciatore del carico.

Per eseguire la migrazione a Dataplane 2, svolgi i seguenti passaggi. Se hai dubbi sulla rimozione temporanea della specifica NetworkPolicy, contatta l'Assistenza Google.

Se il tuo cluster utilizza un NetworkPolicy, rimuovi temporaneamente la sua specifica dal cluster come segue:

Controlla se al tuo cluster sono applicati NetworkPolicy non di sistema:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system

Se l'output del passaggio precedente non era vuoto, salva ogni specifica NetworkPolicy in un file:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
```
Sostituisci quanto segue:
- NETWORK_POLICY_NAME: il nome del NetworkPolicy che stai salvando.
- NETWORK_POLICY_NAMESPACE: lo spazio dei nomi di NetworkPolicy.

Elimina NetworkPolicy utilizzando il seguente comando:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE

Esegui la migrazione a Dataplane V2 seguendo questi passaggi:

Imposta enableDataplaneV2 su true nel file di configurazione del cluster utente.

Per abilitare DataPlane V2, aggiorna il cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
--config USER_CLUSTER_CONFIG

Se in un passaggio precedente hai rimosso specificheNetworkPolicy non di sistema, al termine dell'aggiornamento riapplicale con questo comando:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

Dopo aver completato questi passaggi, Dataplane V2 è attivato. Successivamente, preparati a eseguire la migrazione del cluster al bilanciatore del carico e al piano di controllo V2 consigliati.

Preparazione per la migrazione del bilanciatore del carico

Se i tuoi cluster di utenti utilizzano il bilanciatore del carico Seesaw o F5 BIG-IP integrato, segui i passaggi descritti in questa sezione per apportare le modifiche necessarie al file di configurazione del cluster di utenti. In caso contrario, vai alla sezione successiva Prepararsi alla migrazione a Control plane V2.

F5 BIG-IP

Se i tuoi cluster utilizzano la configurazione integrata di F5 BIG-IP, preparati alla migrazione a ManualLB apportando le seguenti modifiche al file di configurazione del cluster di utenti:

Modifica loadBalancer.kind in "ManualLB".
Mantieni lo stesso valore per il campo loadBalancer.vips.ingressVIP.
Se esegui la migrazione a Controlplane 2, modifica il valore del campo loadBalancer.vips.controlPlaneVIP in base all'indirizzo IP che hai allocato. In caso contrario, puoi mantenere lo stesso valore.
Elimina l'intera loadBalancer.f5BigIP sezione.

Il seguente file di configurazione del cluster utente di esempio mostra queste modifiche:

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.5
  ingressVIP: 198.51.100.20
kind: "f5BigIP" "ManualLB"
f5BigIP:
  address: "203.0.113.2"
  credentials:
  fileRef:
    path: "my-config-folder/user-creds.yaml"
    entry: "f5-creds"
  partition: "my-f5-user-partition"

Seesaw

Se i tuoi cluster di utenti utilizzano il bilanciatore del carico Seesaw, prepara la migrazione a MetalLB seguendo i passaggi riportati nelle sezioni seguenti.

Specifica i pool di indirizzi

Il controller MetalLB gestisce gli indirizzi IP per i servizi. Pertanto, quando un sviluppatore di applicazioni crea un servizio di tipo LoadBalancer in un cluster di utenti, non deve specificare manualmente un indirizzo IP per il servizio. Il controller MetalLB sceglie invece un indirizzo IP da un pool di indirizzi specificato.

Tieni conto del numero massimo di servizi LoadBalancer che potrebbero essere attivi nel tuo cluster di utenti. Quindi, nella sezione loadBalancer.metalLB.addressPools del file di configurazione del cluster utente, specifica indirizzi IP sufficienti per ospitare i servizi.

Quando specifichi i pool di indirizzi, includi il VIP in entrata per il tuo cluster utente in uno dei pool. Questo perché il proxy di ingresso viene esposto da un servizio di tipo LoadBalancer.

Gli indirizzi devono essere in formato CIDR o intervallo. Se vuoi specificare un singolo indirizzo, utilizza un CIDR /32 come 198.51.100.10/32.

Aggiorna il file di configurazione del cluster

Aggiorna il file di configurazione del cluster per rimuovere la sezione Seesaw e aggiungere una sezione MetalLB, come segue:

Imposta loadBalancer.kind su "MetalLB".
Puoi mantenere lo stesso valore per il campo loadBalancer.vips.ingressVIP.
Aggiungi il VIP in entrata a un pool di indirizzi MetalLB.
Se esegui la migrazione a Controlplane 2, modifica il valore del campo loadBalancer.vips.controlPlaneVIP in base all'indirizzo IP che hai allocato. In caso contrario, puoi mantenere lo stesso valore.
Rimuovi la sezione loadBalancer.seesaw.
Aggiungi una sezione loadBalancer.metalLB.

La seguente parte di un file di configurazione del cluster utente mostra queste modifiche e la configurazione di MetalLB di:

Un pool di indirizzi tra cui il controller MetalLB può scegliere e assegnare ai servizi di tipo LoadBalancer. Il VIP in entrata, che in questo esempio è 198.51.100.10, è in questo pool in notazione nel formato intervallo, 198.51.100.10/32.
L'IP virtuale designato per il server API Kubernetes del cluster utente.
Il VIP in entrata che hai configurato per il proxy in entrata.
Un pool di nodi abilitato all'utilizzo di MetalLB. La migrazione esegue il deployment di MetalLB sui nodi di questo pool di nodi.

loadBalancer:
  vips:
    controlPlaneVIP: "198.51.100.50"
    ingressVIP: "198.51.100.10"
  kind: "MetalLB" "Seesaw"
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
  addressPools:
    - name: "address-pool-1"
      enableLoadBalancer: true
      addresses:
      - "198.51.100.10/32"
      - "198.51.100.80 - 198.51.100.89"

Prepararsi per la migrazione a Control plane V2

Se nel cluster non è abilitato Control Plane v2:

Aggiorna il file di configurazione del cluster utente.
Se il cluster utilizza il bilanciamento del carico manuale (loadBalancer.kind: "ManualLB"), aggiorna anche la configurazione sul bilanciatore del carico.

Questi passaggi sono descritti nelle sezioni seguenti.

Se nel cluster è già abilitato il control plane v2, vai alla sezione Eseguire la migrazione del cluster utente.

Aggiorna il file di configurazione del cluster utente

Apporta le seguenti modifiche al file di configurazione del cluster utente esistente:

Imposta enableControlplaneV2 su true.
Se vuoi, rendi il control plane per il cluster utente Controlplane V2 di alta disponibilità (HA). Per passare da un cluster non HA a un cluster HA, modifica masterNode.replicas da 1 a 3.
Aggiungi l'indirizzo IP statico (o gli indirizzi IP statici) per i nodi del piano di controllo del cluster utente alla sezione network.controlPlaneIPBlock.ips. L'indirizzo IP (o gli indirizzi IP) dei nodi del piano di controllo deve trovarsi nella stessa VLAN dei nodi worker.
Compila netmask e gateway nella sezione network.controlPlaneIPBlock.
Se la sezione network.hostConfig è vuota, compilala.
Assicurati che il campo loadBalancer.vips.controlPlaneVIP contenga il nuovo indirizzo IP per il VIP del piano di controllo. L'indirizzo IP deve trovarsi nella stessa VLAN degli indirizzi IP dei nodi del control plane.
Se il cluster di utenti utilizza il bilanciamento del carico manuale, imposta loadBalancer.manualLB.controlPlaneNodePort e loadBalancer.manualLB.konnectivityServerNodePort su 0. Non sono obbligatori quando è attivato Controlplane V2, ma devono avere un valore pari a 0.
Se il cluster di utenti utilizza il bilanciamento del carico manuale, configura il bilanciatore del carico come descritto nella sezione successiva.

Se necessario, modifica le mappature nel bilanciatore del carico

Se il tuo cluster utente utilizza già il bilanciamento del carico manuale, devi configurare alcune mappature sul bilanciatore del carico. Se stai eseguendo la migrazione dalla configurazione F5 BIG-IP integrata al bilanciamento del carico manuale, non devi apportare modifiche alla configurazione del bilanciatore del carico e puoi passare alla sezione successiva, Eseguire la migrazione del cluster di utenti.

Per ogni indirizzo IP specificato nella sezione network.controlPlaneIPBlock, configura i seguenti mappaggi nel bilanciatore del carico per i nodi del piano di controllo:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPSNodePort)

Queste mappature sono necessarie per tutti i nodi del cluster utente, sia i nodi del piano di controllo sia i nodi worker. Poiché i NodePort sono configurati sul cluster, Kubernetes li apre su tutti i nodi del cluster in modo che qualsiasi nodo del cluster possa gestire il traffico del piano dati.

Dopo aver configurato le mappature, il bilanciatore del carico ascolta il traffico sull'indirizzo IP configurato per il VIP di ingresso del cluster utente sulle porte HTTP e HTTPS standard. Il bilanciatore del carico instrada le richieste a qualsiasi nodo del cluster. Dopo che una richiesta è stata instradata a uno dei nodi del cluster, la rete interna di Kubernetes instrada la richiesta al pod di destinazione.

Esegui la migrazione del cluster utente

Innanzitutto, esamina attentamente tutte le modifiche apportate al file di configurazione del cluster di utenti. Tutte le impostazioni del bilanciatore del carico e di Controlplane V2 sono immutabili, tranne quando aggiorni il cluster per la migrazione.

Per aggiornare il cluster, esegui questo comando:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Migrazione a Control plane V2

Durante la migrazione a Control Plane v2, l'aggiornamento esegue le seguenti azioni:

Crea il piano di controllo di un nuovo cluster con ControlPlane V2 abilitato.
Interrompe il piano di controllo Kubernetes del cluster kubeception.
Acquisisce uno snapshot etcd del cluster kubeception.
Disattiva i nodi del control plane del cluster utente del cluster kubeception. Fino al completamento della migrazione, i nodi non vengono eliminati perché questo consente il recupero in caso di errore tramite il fallback al cluster kubeception.
Ripristina i dati del cluster nel nuovo piano di controllo utilizzando lo snapshot etcd creato in un passaggio precedente.
Collega i nodi del pool di nodi del cluster kubeception al nuovo piano di controllo, accessibile con il nuovo controlPlaneVIP.
Riconcilia il cluster utente ripristinato in modo che soddisfi lo stato finale del cluster con ControlPlane V2 abilitato.

Tieni presente quanto segue:

Durante la migrazione non si verificano tempi di inattività per i workload dei cluster utente.
Durante la migrazione, il piano di controllo del cluster utente subirà un breve tempo di inattività. Nello specifico, il piano di controllo non è disponibile tra la interruzione del piano di controllo Kubernetes del cluster kubeception e il completamento del collegamento dei nodi del node pool del cluster kubeception al nuovo piano di controllo. Nei test, questo tempo di riposo è stato inferiore a 7 minuti, ma la durata effettiva dipende dalla tua infrastruttura.
Al termine della migrazione, i nodi del piano di controllo del cluster utente dei cluster kubeception vengono eliminati. Se il cluster di amministrazione ha impostato network.ipMode.type su "static", puoi riutilizzare alcuni degli indirizzi IP statici inutilizzati. Puoi elencare gli oggetti del nodo del cluster di amministrazione con kubectl get nodes -o wide per vedere quali indirizzi IP sono in uso. Per riutilizzare questi indirizzi IP, rimuovili dal file di configurazione del cluster di amministrazione ed esegui gkectl update admin.

Dopo la migrazione

Al termine dell'aggiornamento, svolgi i seguenti passaggi:

Verifica che il cluster utente sia in esecuzione:

kubectl get nodes --kubeconfig var>USER_CLUSTER_KUBECONFIG

L'output è simile al seguente:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Se hai eseguito la migrazione a Controlplane v2, aggiorna le regole del firewall nel cluster di amministrazione per rimuovere i nodi del piano di controllo del cluster utente kubeception.
Se hai disattivato la crittografia dei secret sempre attiva, riattiva la funzionalità.
1. Nel file di configurazione del cluster utente, rimuovi il campo disabled: true.
2. Aggiorna il cluster utente:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Se hai disattivato la riparazione automatica nel cluster di amministrazione, riattiva la funzionalità.
1. Nel file di configurazione del cluster di amministrazione, imposta autoRepair.enabled su true.
2. Aggiorna il cluster:
```
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG
```

Migrazione del bilanciatore del carico

Se hai eseguito la migrazione del bilanciatore del carico, verifica che i relativi componenti funzionino correttamente.

Migrazione di MetalLB

Se hai eseguito la migrazione a MetalLB, verifica che i componenti MetalLB funzionino correttamente:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

L'output mostra i pod per il controller e lo speaker MetalLB. Ad esempio:

metallb-controller-744884bf7b-rznr9   1/1     Running
metallb-speaker-6n8ws                 1/1     Running
metallb-speaker-nb52z                 1/1     Running
metallb-speaker-rq4pp                 1/1     Running

Dopo una migrazione riuscita, elimina le VM Seesaw disattivate per il cluster di utenti. Puoi trovare i nomi delle VM Seesaw nella sezione vmnames del seesaw-for-[USERCLUSTERNAME].yaml file nella directory di configurazione.

Migrazione di F5 BIG-IP

Dopo la migrazione al bilanciamento del carico manuale, il traffico verso i cluster non viene interrotto. Questo accade perché le risorse F5 esistenti sono ancora presenti, come puoi vedere eseguendo il seguente comando:

kubectl --kubeconfig CLUSTER_KUBECONFIG \
api-resources --verbs=list -o name | xargs -n 1 kubectl --kubeconfig
CLUSTER_KUBECONFIG get --show-kind --ignore-not-found
--selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

L'output previsto è simile al seguente:


Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z