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 a ManualLB.

    o

  • Il bilanciatore del carico Seesaw in bundle a MetalLB.

• Esegui la migrazione a un cluster di amministrazione ad alta affidabilità (HA) da un cluster di amministrazione non ad alta affidabilità. La disponibilità è notevolmente migliorata con un cluster di amministrazione ad alta disponibilità, pur utilizzando lo stesso numero di VM. Un cluster di amministrazione non ad alta disponibilità ha un nodo del control plane e due nodi aggiuntivi. I tre nodi di un cluster di amministrazione ad alta disponibilità sono tutti nodi del control plane senza nodi aggiuntivi.

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

Per ulteriori informazioni 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 prima la migrazione dell'ambiente meno critico, ad esempio 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 la riuscita di ogni migrazione e assicurarti che i workload vengano eseguiti correttamente, prima di passare all'ambiente più critico successivo.

Requisiti

• La versione del cluster di amministrazione deve essere 1.30 o successive.
• Tutti i cluster utente gestiti dal cluster di amministrazione devono essere già stati sottoposti a migrazione alle funzionalità consigliate, come descritto in Eseguire la migrazione di 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 data plane Kubernetes continua a funzionare in uno stato stabile.

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

Da	A	Accesso all'API Kubernetes	Workload utente
Cluster di amministrazione ad alta disponibilità con F5 BIG-IP	Cluster di amministrazione ad alta disponibilità con ManualLB	Non interessato	Non interessato
Cluster di amministrazione non ad alta disponibilità con MetalLB o ManualLB	Cluster di amministrazione ad alta disponibilità con lo stesso tipo di bilanciatore del carico	Interessato	Non interessato
Cluster di amministrazione non ad alta disponibilità con F5 BIG-IP	Cluster di amministrazione ad alta disponibilità con ManualLB	Interessato	Non interessato
Cluster di amministrazione non ad alta disponibilità 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 cluster di amministrazione non è ad alta disponibilità, preparati per la migrazione a un cluster di amministrazione ad alta disponibilità seguendo i passaggi descritti in questa sezione. Se il cluster di amministrazione è già ad alta disponibilità, salta 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 ad alta disponibilità ad alta disponibilità, 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 altri nodi esistenti:

• Alloca un indirizzo IP per il nuovo VIP del control plane, per il loadBalancer.vips.controlPlaneVIP campo 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.

Aggiornare le regole firewall

Quando esegui la migrazione del cluster di amministrazione da non ad alta disponibilità ad alta disponibilità, aggiorna le regole firewall nel cluster di amministrazione. In questo modo, gli indirizzi IP appena 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.

Prepararsi per la migrazione del bilanciatore del carico

Se il cluster di amministrazione utilizza la configurazione F5 BIG-IP integrata 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. In caso contrario, vai alla sezione successiva, Prepararsi per la migrazione da non ad alta disponibilità ad alta disponibilità.

F5 BIG-IP

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

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

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 Seesaw, apporta le seguenti modifiche al file di configurazione del cluster di amministrazione:

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

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 per la migrazione da non ad alta disponibilità ad alta disponibilità

Se il cluster di amministrazione non è ad alta disponibilità, preparati per la migrazione ad alta disponibilità seguendo i passaggi descritti in questa sezione.

Se il cluster di amministrazione è già ad alta disponibilità, 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 abilitata nel cluster di amministrazione alla versione 1.14 o precedenti, devi ruotare la chiave di crittografia prima di avviare la migrazione. In caso contrario, il nuovo cluster di amministrazione ad alta disponibilità 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 ruotare la chiave di crittografia, contatta l'assistenza Google.

Aggiornare 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 network.hostConfig sezione. 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 vCenter.dataDisk campo. Per un cluster di amministrazione ad alta disponibilità, i percorsi dei tre dischi dati utilizzati dai nodi del control plane vengono generati automaticamente nella directory principale anthos nel datastore.
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 descritto in questa sezione.

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

Per ciascuno dei tre nuovi indirizzi IP dei nodi 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 vecchio VIP del control plane continua a funzionare durante la migrazione.

Eseguire 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 ti viene richiesto, inserisci Y per continuare.

Durante la migrazione da non ad alta disponibilità ad alta disponibilità, il VIP del control plane precedente continua a funzionare e può essere utilizzato per accedere al nuovo cluster di amministrazione ad alta disponibilità. 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

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.

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 Seesaw nella sezione vmnames del file seesaw-for-gke-admin.yaml nella directory di configurazione.

ManualLB

Dopo aver aggiornato i cluster per utilizzare 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 il seguente 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