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 container (CNI).
Esegui la migrazione dei cluster utente utilizzando kubeception a Controlplane V2.
Migra la configurazione del bilanciatore del carico:
- Dalla configurazione del bilanciatore del carico F5 BIG-IP integrato a ManualLB
  
  o
- Dal bilanciatore del carico di Seesaw in bundle a MetalLB.

Questa pagina è rivolta agli amministratori IT e agli operatori che gestiscono il ciclo di vita dell'infrastruttura tecnologica sottostante. 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 è riuscita, ripeti questa procedura per ogni ambiente, eseguendo la migrazione dell'ambiente di produzione per ultimo. In questo modo puoi convalidare la riuscita di ogni migrazione e assicurarti che i tuoi carichi di lavoro vengano eseguiti correttamente, prima di passare all'ambiente successivo più critico.

Ti consigliamo di creare un nuovo cluster utente con Controlplane V2 abilitato per scoprire le differenze architetturali rispetto ai cluster kubeception. Il nuovo cluster non influisce sui tuoi workload. Tuttavia, nello scenario peggiore, se la migrazione non va a buon fine, hai un cluster pronto per i tuoi carichi di lavoro.

Per saperne di più sulla pianificazione della migrazione, vedi Pianificare la migrazione del cluster alle funzionalità consigliate.

Requisiti

Per questa migrazione:

Il cluster utente deve essere alla versione 1.30 o successive.
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 client, come descritto nella sezione successiva.

Conservazione dell'IP client di Seesaw

Per controllare externalTrafficPolicy, esegui questo comando:

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

Se riscontri questo problema, contatta l'Assistenza Google.

Stima l'impegno di tempo e pianifica 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, il tempo totale di 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 unpool di nodil per il bilanciamento 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 nelpool di nodil.

Per stimare il tempo necessario, conta il numero di volte in cui devi aggiornare il cluster. I seguenti passaggi di alto livello mostrano quando devi eseguire gkectl update cluster per aggiornare il cluster:

Se il cluster utente 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 V2.
Preparati per la migrazione del bilanciatore del carico e del control plane:
1. Se il cluster di amministrazione ha la riparazione automatica attivata, disattivala. Poi esegui gkectl update admin. Questo aggiornamento viene completato rapidamente perché non ricrea i nodi del cluster di amministrazione.
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 interessa 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 V2. 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 per la migrazione dipende dal numero di volte in cui 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. Supponi inoltre che ci siano 10 nodi nel pool di nodi più grande e 3 nodi nel node pool che MetalLB utilizzerà. 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 quelpool di nodil = 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 per la 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 i tempi di inattività durante la migrazione

Quando pianifichi la migrazione, prevedi questi tipi di tempi di inattività:

Tempo di inattività del control plane: l'accesso al server API Kubernetes è interessato durante la migrazione. Se esegui la migrazione a Controlplane V2, si verifica un tempo di inattività del control plane per i cluster utente kubeception durante la migrazione di loadBalancer.vips.controlPlaneVIP. Il tempo di inattività è in genere inferiore a 10 minuti, ma la durata dipende dall'infrastruttura.
Tempo di inattività del workload: gli IP virtuali (VIP) utilizzati dai servizi di tipo LoadBalancer non sono disponibili. Ciò si verifica solo durante una migrazione da Seesaw a MetalLB. Il processo 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 funzionano di nuovo.

La tabella seguente descrive l'impatto della migrazione:

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

Interessato: si verifica un'interruzione del servizio notevole durante la migrazione.
Non interessato: non si verifica alcuna interruzione del servizio o è quasi impercettibile.

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 V2, alloca nuovi indirizzi IP statici nella stessa VLAN dei nodi worker (i nodi nei node pool).

Hai bisogno di un indirizzo IP per loadBalancer.vips.controlPlaneVIP.
Alloca un indirizzo IP per ogni nodo del control plane. Il numero di indirizzi IP che devi allocare dipende dal fatto che il cluster di utenti sarà ad alta disponibilità (HA) o non HA.
- Non HA: un indirizzo IP
- HA: tre indirizzi IP

Aggiorna le regole firewall

Se esegui la migrazione a Controlplane V2, aggiorna le regole firewall sui cluster utente. Assicurati che i nuovi indirizzi IP allocati per i nodi del control plane sul cluster utente possano raggiungere tutte le API e le altre destinazioni richieste, come descritto in Regole firewall per i nodi del cluster utente.

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 la versione 1.30 o successive. In caso contrario, esegui l'upgrade dei pool di nodi alla gkeOnPremVersion nel file di configurazione del cluster utente prima di continuare con la migrazione. Per controllare le versioni, esegui questo comando:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

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

Controllare 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 USER_CLUSTER_NAME

Sostituisci quanto segue:

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

Disabilita la riparazione automatica nel cluster di amministrazione

Se esegui la migrazione del cluster utente per utilizzare Controlplane V2 e la riparazione automatica è abilitata nel cluster di amministrazione, disattiva la riparazione automatica. Controlla il campo autoRepair.enabled del file di configurazione del cluster di amministrazione. Se questo campo non è impostato o è impostato su true, svolgi i seguenti passaggi:

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

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.

Una volta completata la 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 stai eseguendo la migrazione del cluster utente per utilizzare Controlplane V2, verifica la presenza di un problema con la crittografia dei secret sempre attiva.

Se la crittografia dei secret sempre attiva è stata abilitata nel cluster utente, devi eseguire i passaggi descritti in Disabilita la crittografia dei secret sempre attiva e decripta 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 comando seguente per verificare se la crittografia dei secret sempre attiva è mai stata abilitata:

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, la crittografia dei secret sempre attiva non è mai stata abilitata. Puoi avviare la migrazione.

Se l'output del comando precedente non è vuoto, la crittografia dei secret sempre attiva era stata abilitata in precedenza. Prima della migrazione, devi eseguire i passaggi della 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]}}

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

Per disabilitare la crittografia dei secret sempre attiva e decriptare i secret, segui questi passaggi:

Nel file di configurazione del cluster utente, per disattivare la crittografia dei secret always-on, 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 nel seguente modo:

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 come testo normale, applica di nuovo 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.

Verifica la presenza di un problema relativo ai webhook del workload configurati in modo errato

Se stai eseguendo la migrazione del cluster utente per utilizzare Controlplane V2, verifica la presenza di un problema con i webhook dei workload configurati in modo errato.

Se hai webhook che includono pod di sistema nello spazio dei nomi kube-system, aggiungi namespaceSelector per filtrare lo spazio dei nomi kube-system.

Ad esempio,

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

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

Se esegui la migrazione dal bilanciatore del carico Seesaw in bundle a MetalLB, segui i passaggi descritti in questa sezione. Il cluster utilizza Seesaw se loadBalancer.kind: Seesaw si trova nel file di configurazione del cluster utente. Se stai eseguendo la migrazione della configurazione integrata di F5 BIG-IP, passa alla sezione successiva, Eseguire la migrazione a Dataplane V2.

Scegli un pool di nodi e abilitalo per l'utilizzo con MetalLB. La migrazione esegue il deployment di MetalLB sui nodi nel pool di nodi.

Nella sezione nodePools del file di configurazione del cluster utente, scegli un pool di nodi o aggiungi un nuovo node pool 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, vedi Bilanciamento del carico in bundle con MetalLB.

Esegui la migrazione a Dataplane V2

Prima della 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à abilitato, passa alla sezione successiva, Prepararsi per la migrazione del bilanciatore del carico.

Per eseguire la migrazione a Dataplane V2, hai a disposizione le seguenti opzioni:

Esegui l'upgrade del cluster alla versione 1.31. Per la procedura dettagliata, vedi Attivare Dataplane V2.
Aggiorna il cluster 1.30.

In entrambi i casi devi rimuovere temporaneamente la specifica NetworkPolicy come descritto nei passaggi seguenti.

Per eseguire la migrazione a Dataplane V2, segui questi passaggi. Se hai dubbi in merito alla rimozione temporanea della specifica NetworkPolicy, contatta l'Assistenza Google.

Se il cluster utilizza un NetworkPolicy, rimuovi temporaneamente la relativa specifica dal cluster, nel seguente modo:

Controlla se al tuo cluster è applicato un 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 in modo da poterla riapplicare dopo l'aggiornamento del cluster.
```
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 NetworkPolicy specifiche non di sistema, dopo il completamento dell'aggiornamento, applicale di nuovo con questo comando:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

Dopo aver completato questi passaggi, Dataplane V2 è abilitato. Successivamente, preparati a eseguire la migrazione del cluster al bilanciatore del carico e a Controlplane V2 consigliati.

Preparati per la migrazione del bilanciatore del carico

Se i cluster utente 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 utente. Altrimenti, passa alla sezione successiva, Prepararsi alla migrazione a Controlplane V2.

F5 BIG-IP

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

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

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 utente utilizzano il bilanciamento del carico Seesaw, preparati alla migrazione a MetalLB svolgendo i passaggi nelle sezioni seguenti.

Specifica i pool di indirizzi

Il controller MetalLB assegna gli indirizzi IP per i servizi. Quando uno sviluppatore di applicazioni crea un servizio di tipo LoadBalancer in un cluster utente, il controller MetalLB assegna automaticamente un indirizzo IP al servizio. Il controller MetalLB seleziona un indirizzo IP da un pool di indirizzi che specifichi.

Per assicurarti che il cluster utente disponga di indirizzi IP sufficienti, considera il numero massimo di servizi LoadBalancer che probabilmente saranno attivi. Quindi, specifica un numero sufficiente di indirizzi IP nella sezione loadBalancer.metalLB.addressPools del file di configurazione del cluster utente.

Gli indirizzi nel pool devono essere in formato CIDR o intervallo. Per specificare un singolo indirizzo, utilizza un CIDR /32. Ad esempio:

addresses:
  -   "192.0.2.0/26"
  -   "192.0.2.64-192.0.2.72"
  -   "192.0.2.75/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 V2, modifica il valore del campo loadBalancer.vips.controlPlaneVIP con l'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 da 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, si trova in questo pool nel formato di notazione dell'intervallo, 198.51.100.10/32.
Il VIP 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 in questopool di nodil.

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"
        addresses:
        - "198.51.100.10/32"
        - "198.51.100.80 - 198.51.100.89"

Prepararsi per la migrazione a Controlplane V2

Se nel cluster non è abilitato Controlplane 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 il cluster ha già Controlplane V2 abilitato, vai alla sezione Migrare il 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.
(Facoltativo) Rendi il control plane per il cluster utente Controlplane V2 a disponibilità elevata (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) per i nodi del control plane del cluster utente alla sezione network.controlPlaneIPBlock.ips. L'indirizzo o gli indirizzi IP per i nodi del control plane devono trovarsi nella stessa VLAN dei nodi worker. I nomi host sono obbligatori.
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 control plane. L'indirizzo IP deve trovarsi nella stessa VLAN degli IP dei nodi del control plane.
Se il cluster utente utilizza il bilanciamento del carico manuale, imposta loadBalancer.manualLB.controlPlaneNodePort e loadBalancer.manualLB.konnectivityServerNodePort su 0. Non sono obbligatori quando è abilitato Controlplane V2, ma devono avere 0 come valore.
Se il cluster di utenti utilizza il bilanciamento del carico manuale, configura il bilanciatore del carico come descritto nella sezione successiva.

Se necessario, modifica i mapping nel bilanciatore del carico

Se il cluster utente utilizza già il bilanciamento del carico manuale, devi configurare alcuni mapping sul bilanciatore del carico. Se esegui la migrazione dalla configurazione integrata di F5 BIG-IP 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 utente.

Per ogni indirizzo IP specificato nella sezione network.controlPlaneIPBlock, configura i seguenti mapping nel bilanciatore del carico per i nodi del control plane:

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

Questi mapping sono necessari per tutti i nodi nel cluster utente, sia per i nodi del control plane sia per i nodi worker. Poiché le NodePort sono configurate sul cluster, Kubernetes apre le NodePort su tutti i nodi del cluster, in modo che qualsiasi nodo del cluster possa gestire il traffico del piano dati.

Dopo aver configurato i mapping, il bilanciatore del carico rimane in ascolto del traffico sull'indirizzo IP configurato per il VIP Ingress 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 viene instradata a uno dei nodi del cluster, il networking Kubernetes interno 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 di Controlplane V2

Durante la migrazione di Controlplane V2, l'aggiornamento esegue le seguenti azioni:

Crea il control plane di un nuovo cluster con ControlPlane V2 abilitato.
Arresta il control plane Kubernetes del cluster kubeception.
Acquisisce uno snapshot etcd del cluster kubeception.
Spegne i nodi del control plane del cluster utente del cluster kubeception. Fino al completamento della migrazione, i nodi non vengono eliminati perché ciò consente il ripristino in caso di errore eseguendo il failback a quel cluster kubeception.
Ripristina i dati del cluster nel nuovo control plane utilizzando lo snapshot etcd creato in un passaggio precedente.
Collega i nodi del pool di nodi del cluster kubeception al nuovo control plane, accessibile con il nuovo controlPlaneVIP.
Esegue la riconciliazione del cluster utente ripristinato per soddisfare lo stato finale del cluster con ControlPlane V2 abilitato.

Tieni presente quanto segue:

Non sono previsti tempi di inattività per i workload del cluster utente durante la migrazione.
Durante la migrazione, il control plane del cluster utente non è disponibile per un breve periodo di tempo. In particolare, il control plane non è disponibile tra l'arresto del control plane Kubernetes del cluster kubeception e il completamento della connessione dei nodi del node pool del cluster kubeception al nuovo control plane. Nei test, questo tempo di inattività è stato inferiore a 7 minuti, ma la durata effettiva dipende dalla tua infrastruttura.
Al termine della migrazione, i nodi del control plane del cluster utente dei cluster kubeception vengono eliminati. Se il cluster di amministrazione ha network.ipMode.type impostato su "static", puoi riciclare alcuni degli indirizzi IP statici inutilizzati. Puoi elencare gli oggetti nodo del cluster di amministrazione con kubectl get nodes -o wide per vedere quali indirizzi IP sono in uso. Per riciclare 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 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 firewall sul cluster di amministrazione per rimuovere i nodi del control plane 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 componenti del bilanciatore del carico siano in esecuzione.

Migrazione di MetalLB

Se hai eseguito la migrazione a MetalLB, verifica che i componenti MetalLB siano in esecuzione 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 spente per il cluster utente. Puoi trovare i nomi delle VM di Seesaw nella sezione vmnames del file seesaw-for-[USERCLUSTERNAME].yaml 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 perché le risorse F5 esistenti esistono ancora, come puoi vedere eseguendo questo 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