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

Panoramica

Questa pagina mostra come eseguire la migrazione di un cluster amministrativo della versione 1.30 o successiva a queste funzionalità consigliate:

• La configurazione del bilanciatore del carico:

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

    o

  • Il bilanciatore del carico Seesaw in bundle con MetalLB.

• Esegui la migrazione a un cluster di amministrazione ad alta disponibilità (HA) da un cluster di amministrazione non HA. La disponibilità è notevolmente migliorata 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 piano di controllo e due nodi 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 di base. Per scoprire di più 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.

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

Requisiti

• Il cluster di amministrazione deve essere almeno della versione 1.30.
• È già stata eseguita la migrazione di tutti i cluster utente gestiti dal cluster di amministrazione alle funzionalità consigliate, come descritto in Eseguire la migrazione di un cluster utente alle funzionalità consigliate.

Pianificare il tempo di riposo durante la migrazione

Per la migrazione, pianifica un periodo di inattività limitato del piano di controllo. L'accesso all'API Kubernetes non è disponibile per i cluster di amministrazione non ad alta disponibilità per circa 20 minuti, ma il piano di controllo 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 uno stato stabile.

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

Prepararsi per la migrazione

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 tuo cluster di amministrazione è già ad alta disponibilità, vai alla sezione successiva Preparazione per la migrazione del bilanciatore del carico.

Alloca 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 amministrativo esistenti e che non siano già utilizzati da altri nodi esistenti:

• Assegna un indirizzo IP per il nuovo VIP del piano di controllo per il campo loadBalancer.vips.controlPlaneVIP nel file di configurazione del cluster di amministrazione.
• Assegna nuovi indirizzi IP a 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, 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 del firewall per i cluster di amministrazione.

Preparazione 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 alla migrazione da non HA ad HA.

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"
  

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 è ad alta disponibilità, preparati a eseguire la migrazione ad HA seguendo i passaggi di questa sezione.

Se il tuo cluster di amministrazione è già ad alta disponibilità, vai alla sezione successiva, Eseguire la migrazione del cluster di amministrazione.

Se la versione del tuo 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 nella 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 potrà 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, ad esempio nell'esempio seguente, devi ruotare la chiave di crittografia seguendo i passaggi descritti in questo problema noto.

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

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 assegnati ai nodi del piano di controllo.
2. Assicurati di aver compilato la sezione network.hostConfig. Questa sezione contiene informazioni su server NTP, server DNS e 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 amministrativo HA, i percorsi dei tre dischi dati utilizzati dai nodi del piano di controllo vengono generati automaticamente nella directory principale anthos nel data store.
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 le mappature nel bilanciatore del carico

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

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

Per ciascuno dei tre nuovi indirizzi IP dei nodi del piano di controllo specificati nella sezione network.controlPlaneIPBlock, configura questa mappatura 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 continuerà 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 si aggiorna 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, la VIP del control plane precedente continua a funzionare e può essere utilizzata per accedere al nuovo cluster di amministrazione ad alta disponibilità. Al termine della migrazione, il file kubeconfig del cluster amministrativo viene aggiornato automaticamente per utilizzare il nuovo VIP del piano di controllo.

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 relativi componenti funzionino correttamente.

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

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

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \

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