Eseguire la migrazione di un cluster di amministrazione alle funzionalità consigliate

Panoramica

Questa pagina mostra come eseguire la migrazione di un cluster di amministrazione versione 1.30 o successive a queste funzionalità consigliate:

• La configurazione del bilanciatore del carico:

  • La configurazione del bilanciatore del carico F5 BIG-IP integrato in ManualLB.

    o

  • Il bilanciatore del carico Seesaw in bundle a MetalLB.

• Esegui la migrazione a un cluster di amministrazione ad alta disponibilità (HA) da un cluster di amministrazione non HA. La disponibilità è migliorata in modo significativo con un cluster di amministrazione ad alta disponibilità utilizzando lo stesso numero di VM. Un cluster di amministrazione non ad alta disponibilità ha un nodo del control plane e due nodi dei componenti aggiuntivi. I tre nodi di un cluster di amministrazione HA sono tutti nodi del piano di controllo senza nodi aggiuntivi.

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

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

Best practice

Se hai più ambienti, ad esempio test, sviluppo e produzione, ti consigliamo di eseguire la migrazione prima dell'ambiente meno critico, ad esempio 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.

Requisiti

• Il cluster di amministrazione deve essere alla versione 1.30 o successive.
• Tutti i cluster utente gestiti dal cluster di amministrazione devono essere già stati migrati alle funzionalità consigliate, come descritto in Migrare un cluster utente alle funzionalità consigliate.

Pianificare i tempi di inattività durante la migrazione

Per la migrazione, pianifica un tempo di inattività limitato del control plane. L'accesso all'API Kubernetes non è disponibile per i cluster di amministrazione non ad alta disponibilità per circa 20 minuti, ma il control plane Kubernetes rimane disponibile per i cluster di amministrazione ad alta disponibilità con F5. Durante le migrazioni, il piano dati di Kubernetes continua a funzionare in modo stabile.

Nota: i carichi di lavoro degli utenti devono essere eseguiti solo nei cluster utente, che non sono interessati dalla migrazione dei cluster di amministrazione.

Da	A	Accesso API Kubernetes	Workload utente
Cluster di amministrazione ad alta disponibilità con F5 BIG-IP	Cluster di amministrazione HA con ManualLB	Non interessato	Non interessato
cluster di amministrazione non HA con MetalLB o ManualLB	Cluster di amministrazione HA con lo stesso tipo di bilanciatore del carico	Interessato	Non interessato
cluster di amministrazione non HA con F5 BIG-IP	Cluster di amministrazione HA con ManualLB	Interessato	Non interessato
cluster di amministrazione non HA con Seesaw	Cluster di amministrazione ad alta disponibilità con MetalLB	Interessato	Non 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

Se il tuo cluster di amministrazione non è ad alta disponibilità, preparati a eseguire la migrazione a un cluster di amministrazione ad alta disponibilità seguendo i passaggi descritti in questa sezione. Se il cluster di amministrazione è già HA, passa alla sezione successiva, Prepararsi per la migrazione del bilanciatore del carico.

Allocare indirizzi IP aggiuntivi

Quando esegui la migrazione del cluster di amministrazione da non HA ad HA, alloca quattro indirizzi IP aggiuntivi. Assicurati che questi indirizzi IP si trovino nella stessa VLAN dei nodi del cluster di amministrazione esistenti e che non siano già utilizzati da nodi esistenti:

• Assegna un indirizzo IP al nuovo VIP del control plane, per il campo loadBalancer.vips.controlPlaneVIP nel file di configurazione del cluster di amministrazione.
• Alloca un nuovo indirizzo IP per ciascuno dei tre nodi del control plane, per la sezione network.controlPlaneIPBlock nel file di configurazione del cluster di amministrazione.

Aggiorna le regole firewall

Quando esegui la migrazione del cluster di amministrazione da non HA ad HA, aggiorna le regole firewall sul cluster di amministrazione. In questo modo, i nuovi indirizzi IP allocati per i nodi del control plane possono raggiungere tutte le API e le altre destinazioni richieste, come descritto in Regole firewall per i cluster di amministrazione.

Preparati per la migrazione del bilanciatore del carico

Se il cluster di amministrazione utilizza la configurazione integrata di F5 BIG-IP o il bilanciatore del carico Seesaw in bundle, segui i passaggi descritti in questa sezione per apportare le modifiche necessarie al file di configurazione del cluster di amministrazione. Altrimenti, passa alla sezione successiva, Prepararsi alla migrazione da una VPN non ad alta disponibilità a una VPN ad alta disponibilità.

F5 BIG-IP

Se il cluster di amministrazione utilizza la configurazione integrata di F5 BIG-IP, apporta le seguenti modifiche al file di configurazione del cluster di amministrazione:

1. Imposta il campo loadBalancer.kind su "ManualLB".
2. Imposta o mantieni il valore del campo loadBalancer.vips.controlPlaneVIP. Se il cluster di amministrazione è già HA, mantieni lo stesso valore. Se esegui la migrazione da un cluster di amministrazione non HA a un cluster di amministrazione HA, modifica il valore del campo loadBalancer.vips.controlPlaneVIP con l'indirizzo IP che hai allocato.
3. Elimina l'intera sezione loadBalancer.f5BigIP.

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

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
kind: "F5BigIP" "ManualLB"
f5BigIP:
    address: "203.0.113.20"
  credentials:
    fileRef:
      path: ""my-config-folder/user-creds.yaml"
      entry: "f5-creds"
  partition: "my-f5-user-partition"
  

Seesaw

Se il cluster di amministrazione utilizza il bilanciatore del carico di Seesaw, apporta le seguenti modifiche al file di configurazione del cluster di amministrazione:

1. Imposta il campo loadBalancer.kind su "MetalLB".
2. Mantieni la sezione network.hostConfig.
3. Imposta o mantieni il valore del campo loadBalancer.vips.controlPlaneVIP]5. Se il cluster di amministrazione è già HA, puoi mantenere lo stesso valore. Se esegui la migrazione da un cluster di amministrazione non HA a un cluster di amministrazione HA, modifica il valore del campo loadBalancer.vips.controlPlaneVIP con l'indirizzo IP che hai allocato.
4. Rimuovi la sezione loadBalancer.seesaw.

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

network:
hostConfig:
  dnsServers:
  - "203.0.113.1"
  - "203.0.113.2"
  ntpServers:
  - "203.0.113.3"
loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
kind: "MetalLB" "Seesaw"
seesaw:
  ipBlockFilePath: "user-cluster-1-ipblock.yaml"
  vrid: 1
  masterIP: ""
  cpus: 4
  memoryMB: 3072

Prepararsi alla migrazione da non HA ad HA

Se il cluster di amministrazione non è HA, preparati a eseguire la migrazione ad HA seguendo i passaggi descritti in questa sezione.

Se il cluster di amministrazione è già HA, vai alla sezione successiva, Eseguire la migrazione del cluster di amministrazione.

Se la versione del cluster di amministrazione è 1.29.0-1.29.600 o 1.30.0-1.30.100 e se la crittografia dei secret sempre attiva è stata attivata nel cluster di amministrazione alla versione 1.14 o precedente, devi ruotare la chiave di crittografia prima di iniziare la migrazione. In caso contrario, il nuovo cluster di amministrazione HA non sarà in grado di decriptare i secret.

Per verificare se il cluster potrebbe utilizzare una vecchia chiave di crittografia:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

Se l'output mostra una chiave vuota, come nell'esempio seguente, devi ruotare la chiave di crittografia seguendo i passaggi descritti in questo problema noto.

"GeneratedKeys":[{"KeyVersion":"1","Key":""}]

Avviso: se hai avviato la migrazione senza eseguire la rotazione della chiave di crittografia, contatta l'assistenza Google.

Aggiorna il file di configurazione del cluster di amministrazione

Apporta le seguenti modifiche al file di configurazione del cluster di amministrazione:

1. Compila network.controlPlaneIPBlock con i tre indirizzi IP che hai allocato per i nodi del control plane.
2. Assicurati di aver compilato la sezione network.hostConfig. Questa sezione contiene informazioni sui server NTP, sui server DNS e sui domini di ricerca DNS utilizzati dalle VM corrispondenti ai nodi del cluster.
3. Assicurati di aver sostituito il valore di loadBalancer.vips.controlPlaneVIP con l'indirizzo IP che hai allocato.
4. Imposta adminMaster.replicas su 3.
5. Rimuovi il campo vCenter.dataDisk. Per un cluster di amministrazione HA, i percorsi dei tre dischi di dati utilizzati dai nodi del control plane vengono generati automaticamente nella directory principale anthos nell'archivio dati.
6. Se loadBalancer.kind è impostato su "ManualLB", imposta loadBalancer.manualLB.controlPlaneNodePort su 0.

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

vCenter:
  address: "my-vcenter-server.my-domain.example"
  datacenter: "my-data-center"
  dataDisk: "xxxx.vmdk"
...
network:
  hostConfig:
    dnsServers:
    - 203.0.113.1
    - 203.0.113.2
    ntpServers:
    - 203.0.113.3
  ...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "198.51.100.1"
    ips:
    - ip: "192.0.2.1"
      hostname: "admin-cp-hostname-1"
    - ip: "192.0.2.2"
      hostname: "admin-cp-hostname-2"
    - ip: "192.0.2.3"
      hostname: "admin-cp-hostname-3"
...

...
loadBalancer:
  vips:
    controlPlaneVIP: 192.0.2.6 192.0.2.50
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 30003 0

...
adminMaster:
  replicas: 3
  cpus: 4
  memoryMB: 8192
...

Se necessario, modifica i mapping nel bilanciatore del carico

Se il cluster di amministrazione ha utilizzato il bilanciamento del carico manuale, completa il passaggio in questa sezione.

Se esegui la migrazione dal bilanciamento del carico manuale integrato di F5 BIG-IP o se esegui la migrazione a MetalLB, vai alla sezione successiva, Esegui la migrazione del cluster di amministrazione.

Per ciascuno dei tre nuovi indirizzi IP del nodo del control plane specificati nella sezione network.controlPlaneIPBlock, configura questo mapping nel bilanciatore del carico esterno (ad esempio F5 BIG-IP o Citrix):

(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old controlPlaneNodePort)

In questo modo, il VIP del control plane precedente continua a funzionare durante la migrazione.

Esegui la migrazione del cluster di amministrazione

Esamina attentamente tutte le modifiche apportate al file di configurazione del cluster di amministrazione. Tutte le impostazioni sono immutabili, tranne quando aggiorni il cluster per la migrazione.

Aggiorna il cluster:

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

Replace the following:

• 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.

Il comando mostra l'avanzamento della migrazione.

Quando richiesto, inserisci Y per continuare.

Durante la migrazione da non HA ad HA, il VIP del control plane precedente continua a funzionare e può essere utilizzato per accedere al nuovo cluster di amministrazione HA. Al termine della migrazione, il file kubeconfig del cluster di amministrazione viene aggiornato automaticamente per utilizzare il nuovo VIP del control plane.

Dopo la migrazione

Al termine dell'aggiornamento, verifica che il cluster di amministrazione sia in esecuzione:

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

L'output previsto è simile al seguente:

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.

MetalLB

Se hai eseguito la migrazione a MetalLB, verifica che i componenti MetalLB siano in esecuzione correttamente utilizzando il seguente comando:

kubectl --kubeconfig ADMIN_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 di amministrazione. Puoi trovare i nomi delle VM di Seesaw nella sezione vmnames del file seesaw-for-gke-admin.yaml nella directory di configurazione.

ManualLB

Dopo aver aggiornato i cluster in modo che utilizzino il 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 ADMIN_CLUSTER_KUBECONFIG \

L'output previsto è simile al seguente:

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