Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Eseguire 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 Container Network Interface (CNI).
Esegui la migrazione dei cluster utente utilizzando kubeception a Controlplane V2.
Esegui la migrazione della configurazione del bilanciatore del carico:
- Dalla configurazione del bilanciatore del carico BIG-IP di F5 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 sottostante. Per informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti diGoogle Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Best practice

Ti consigliamo di eseguire prima la migrazione dell'ambiente meno critico, ad esempio quello di test. Dopo aver verificato che la migrazione è andata a buon fine, ripeti questa procedura per ogni ambiente, eseguendo la migrazione dell'ambiente di produzione per ultimo. In questo modo puoi convalidare l'esito positivo di ogni migrazione e assicurarti che i workload 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 di architettura con i cluster kubeception. Il nuovo cluster non influisce sui tuoi workload. Tuttavia, nel peggiore dei casi, se la migrazione non va a buon fine, hai un cluster pronto per i tuoi workload.

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

Requisiti

Per questa migrazione:

Il cluster utente deve essere alla versione 1.30 o successive.
Tutti i node pool 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 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 il tempo necessario e pianifica un periodo di manutenzione

Quando aggiorni il cluster, per impostazione predefinita tutti i node pool vengono aggiornati in parallelo. Tuttavia, all'interno di ogni pool di nodi, i nodi vengono aggiornati in sequenza. Pertanto, il tempo di aggiornamento totale 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, calcola 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, conta il numero di volte in cui devi aggiornare il cluster. I seguenti passaggi generali 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 alla migrazione del bilanciatore del carico e del control plane:
1. Se il cluster di amministrazione ha la riparazione automatica abilitata, disabilitala. 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 riguarda solo i nodi nel pool di nodi selezionato.
Apporta tutte le modifiche di configurazione necessarie per aggiornare il bilanciatore del carico ed 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. Supponiamo inoltre che ci siano 10 nodi nel pool di nodi più grande e 3 nodi 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 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 un periodo di manutenzione ed eseguire il resto della migrazione in uno o due periodi di manutenzione.

Pianifica i tempi di inattività durante la migrazione

Quando pianifichi la migrazione, tieni conto di 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. In genere, il tempo di inattività è inferiore a 10 minuti, ma la sua durata dipende dall'infrastruttura.
Tempo di inattività del workload: gli IP virtuali (VIP) utilizzati dai servizi di tipo LoadBalancer non sono disponibili. Questo accade 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 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, con `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 del bilanciamento manuale del carico	Interessato	Non interessato
Cluster Kubeception con `loadBalancer.kind: "Seesaw"`	Cluster Controlplane V2 con MetalLB	Interessato	Interessato

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

Preparati alla migrazione

Per garantire una migrazione corretta, 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).

Ti serve 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 utente sia ad alta affidabilità (HA) o meno.
- 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 gli indirizzi IP appena allocati per i nodi del control plane nel cluster utente possano raggiungere tutte le API richieste e altre destinazioni, come descritto in Regole firewall per i nodi del cluster utente.

Controlla le versioni del cluster e pool di nodi

Verifica che tutti i node pool utilizzino la stessa versione del cluster utente, che deve essere la versione 1.30 o successiva. In caso contrario, esegui l'upgrade dei node pool alla versione 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.

Controlla l'integrità del cluster

Controlla lo stato 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 utente.

Disabilita la riparazione automatica nel cluster di amministrazione

Se stai eseguendo la migrazione del cluster utente per utilizzare Controlplane V2 e la riparazione automatica è abilitata nel cluster di amministrazione, disabilita 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: 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.

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

Verifica se è presente un problema con la crittografia dei secret sempre attiva

Se stai eseguendo la migrazione del cluster utente per utilizzare Controlplane V2, verifica se esiste un problema con la crittografia dei secret sempre attiva.

Se la crittografia dei secret sempre attiva è stata attivata nel cluster utente, devi seguire i passaggi descritti in Disattiva la crittografia dei secret sempre attiva e decripta i secret prima di avviare la migrazione. In caso contrario, il nuovo cluster Controlplane V2 non è in grado di decriptare i secret.

Prima di iniziare la migrazione, esegui questo comando per verificare se la crittografia dei secret sempre attivi è 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, significa che la crittografia dei secret sempre attiva era stata abilitata in precedenza. Prima della migrazione, devi seguire 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 disattivare 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 sempre attiva, 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

Per fare in modo che tutti i secret vengano archiviati in etcd come testo non crittografato, applica nuovamente tutti i secret nel cluster utente:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Ora puoi avviare la migrazione a Controlplane V2. Una volta completata la migrazione, puoi riattivare la crittografia dei secret sempre attiva sul cluster.

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

Se stai eseguendo la migrazione del cluster utente per utilizzare Controlplane V2, verifica se esiste 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

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, segui i passaggi descritti in questa sezione. Il cluster utilizza Seesaw se loadBalancer.kind: Seesaw è presente nel file di configurazione del cluster utente. Se stai eseguendo la migrazione della configurazione F5 BIG-IP integrata, vai alla sezione successiva, Esegui 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 aggiungine uno nuovo 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 saperne di più su MetalLB, consulta Bilanciamento del carico integrato con MetalLB.

Esegui la migrazione a Dataplane V2

Prima di eseguire la migrazione, verifica 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:

Se il cluster è stato originariamente creato con Dataplane V2 abilitato, vai a Preparati alla migrazione del bilanciatore del carico.
Se in precedenza è stata eseguita la migrazione del cluster da Calico a Dataplane V2 (ad esempio durante un upgrade alla versione 1.31), vai a Rimuovi i DaemonSet Calico inattivi.

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 Abilita 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 sulla rimozione temporanea della specifica NetworkPolicy, contatta l'Assistenza Google.

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

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 applicare nuovamente 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 della 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

Per eseguire la migrazione a Dataplane V2, segui 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 hai rimosso le specifiche NetworkPolicy non di sistema in un passaggio precedente, dopo il completamento dell'aggiornamento, applicale nuovamente con questo comando:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

Hai abilitato Dataplane V2.

Rimuovi i DaemonSet Calico inattivi

Dopo aver eseguito la migrazione di un cluster di amministrazione o di un cluster utente da Calico a Dataplane V2, i DaemonSet calico-node e calico-route-daemon rimangono inattivi nello spazio dei nomi kube-system per preservare la funzionalità di rollback. Prima di scalare o eseguire l'upgrade del cluster, rimuovi l'annotazione features.onprem.cluster.gke.io/dpv2-migration una volta per cluster migrato, in modo che il controller del cluster elimini definitivamente i DaemonSet Calico inattivi e impedisca loro di inizializzarsi sui nuovi nodi (consulta il problema noto Timeout di connessione intermittenti dopo l'upgrade o la scalabilità di un cluster migrato da Calico a Dataplane V2). Non è necessario eseguire questi passaggi sui cluster creati con Dataplane V2 abilitato.

Verifica che la migrazione a Dataplane V2 sia stata completata e che tutti i nodi del cluster abbiano l'etichetta networking.gke.io/cni-type: cilium:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get nodes -L networking.gke.io/cni-type
```
Sostituisci CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente o del cluster di amministrazione.
Dopo aver verificato che Dataplane V2 è in esecuzione su tutti i nodi e che non è più necessario eseguire il rollback a Calico, rimuovi l'annotazione features.onprem.cluster.gke.io/dpv2-migration dalla risorsa personalizzata OnPremUserCluster (e da OnPremAdminCluster se è stata eseguita la migrazione del cluster di amministrazione da Calico durante l'upgrade dalla versione 1.29 alla 1.30):
```
# For a user cluster:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG annotate onpremusercluster USER_CLUSTER_NAME \
    -n USER_CLUSTER_NAME-gke-onprem-mgmt \
    features.onprem.cluster.gke.io/dpv2-migration-

# For an admin cluster:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG annotate onpremadmincluster ADMIN_CLUSTER_NAME \
    -n kube-system \
    features.onprem.cluster.gke.io/dpv2-migration-
```
Sostituisci quanto segue:
- ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
- USER_CLUSTER_NAME: il nome del cluster utente.
- ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione (puoi trovarlo eseguendo kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremadmincluster -n kube-system).
Nota: non utilizzare kubectl delete daemonset per eliminare manualmente i DaemonSet, perché il controller del cluster riconcilia il bundle del componente aggiuntivo durante gli aggiornamenti e gli upgrade e li ricrea, a meno che non rimuovi l'annotazione features.onprem.cluster.gke.io/dpv2-migration.
Verifica che il controller abbia eliminato i DaemonSet calico-node e calico-route-daemon (entrambi restituiscono NotFound):
```
kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-system get daemonset calico-node calico-route-daemon
```

Successivamente, preparati a eseguire la migrazione del cluster al bilanciatore del carico consigliato e a Controlplane V2.

Preparati alla migrazione del bilanciatore del carico

Se i tuoi 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. In caso contrario, vai alla sezione successiva, Preparati alla migrazione a Controlplane V2.

BIG-IP di F5

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

Cambia 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 bilanciatore del carico Seesaw, preparati alla migrazione a MetalLB seguendo i passaggi descritti 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 specificato da te.

Per assicurarti che il cluster utente disponga di un numero sufficiente di indirizzi IP, considera il numero massimo di servizi LoadBalancer che potrebbero essere 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 indirizzo individuale, 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"

Escludi gli indirizzi IP utilizzati per altri scopi

Non includere i seguenti indirizzi IP in nessun pool di indirizzi:

VIP del control plane:
- cluster di amministrazione
- cluster utente
Indirizzi IP dei nodi del control plane:
- cluster di amministrazione
- cluster utente
Indirizzi IP del gateway:
- cluster di amministrazione
- cluster utente
Indirizzi IP per i servizi:
- cluster di amministrazione
- cluster utente
Indirizzi IP per i pod:
- cluster di amministrazione
- cluster utente
Indirizzi IP dei nodi worker del cluster utente
Indirizzi IP dei server vCenter, dei server DNS, dei server NTP e della workstation di amministrazione

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 Ingress 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:

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, si trova in questo pool nella notazione del formato 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 per l'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"
        addresses:
        - "198.51.100.10/32"
        - "198.51.100.80 - 198.51.100.89"

Preparati alla migrazione a Controlplane V2

Se il cluster non ha Controlplane V2 abilitato:

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

Questi passaggi sono descritti nelle sezioni seguenti.

Se nel cluster è già abilitato Controlplane V2, vai alla sezione Esegui 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.
Facoltativamente, rendi il control plane per il cluster utente Controlplane V2 ad alta affidabilità (HA). Per passare da un cluster non ad alta affidabilità a un cluster ad alta affidabilità, 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. Gli indirizzi IP dei nodi del control plane devono trovarsi nella stessa VLAN dei nodi worker. I nomi host sono obbligatori.
Compila i campi 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 manuale del carico, imposta loadBalancer.manualLB.controlPlaneNodePort e loadBalancer.manualLB.konnectivityServerNodePort su 0. Non sono obbligatori quando Controlplane V2 è abilitato, ma devono avere un valore pari a 0.
Se il cluster utente utilizza il bilanciamento manuale del carico, 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 manuale del carico, devi configurare alcune mappature sul bilanciatore del carico. Se esegui la migrazione dalla configurazione F5 BIG-IP integrata al bilanciamento manuale del carico, non devi apportare modifiche alla configurazione del bilanciatore del carico e puoi passare alla sezione successiva, Esegui la migrazione del cluster utente.

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

(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 control plane 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 nel cluster possa gestire il traffico del piano dati.

Dopo aver configurato le mappature, il bilanciatore del carico rimane in ascolto del traffico sull'indirizzo IP configurato per il VIP in entrata 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, il networking interno di Kubernetes la instrada al pod di destinazione.

Esegui la migrazione del cluster utente

Innanzitutto, esamina attentamente tutte le modifiche apportate al file di configurazione del cluster utente. 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 Controlplane V2

Durante la migrazione a 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 recupero degli errori tornando al 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.
Riconcilia il 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 dei cluster utente durante la migrazione.
Durante la migrazione, il control plane del cluster utente è inattivo 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 pool di nodi 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.
Al termine della migrazione, i nodi worker vengono sottoposti a un aggiornamento in sequenza. Attendi che tutti i nodi siano pronti prima di procedere con i passaggi post-migrazione nella sezione seguente.
Dopo la migrazione, l'indirizzo VIP del control plane precedente continua a funzionare, ma è instabile. Non fare affidamento su questo. Aggiorna eventuali dipendenze dal vecchio indirizzo VIP per utilizzare il nuovo indirizzo VIP il prima possibile.

Dopo la migrazione

Al termine dell'aggiornamento, segui questi 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 correttamente.

Migrazione di MetalLB

Se hai eseguito la migrazione a MetalLB, verifica che i componenti di 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 l'altoparlante 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 Seesaw nella sezione vmnames del file seesaw-for-[USERCLUSTERNAME].yaml nella directory di configurazione.

Migrazione di F5 BIG-IP

Dopo la migrazione al bilanciamento manuale del carico, il traffico verso i cluster non viene interrotto. Questo 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