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 successiva a questi 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à da un cluster di amministrazione non ad alta disponibilità. La disponibilità è notevolmente migliorato con un cluster di amministrazione ad alta disponibilità lo stesso numero di VM. Un cluster di amministrazione non ad alta disponibilità ha un nodo del piano di controllo e due nodi aggiuntivi. Un alta disponibilità I tre nodi del cluster di amministrazione 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 ulteriori informazioni sulla pianificazione della migrazione, consulta Pianificare la migrazione del cluster alle funzionalità consigliate.

Best practice

Se utilizzi più ambienti, ad esempio test, sviluppo e produzione, consigliamo di eseguire prima la migrazione dell'ambiente meno critico, come il 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 convalidare il successo di ogni migrazione e assicurarti che i carichi di lavoro vengano eseguiti correttamente, prima di passare al successivo ambiente più critico.

Requisiti

• La versione del cluster di amministrazione deve essere 1.30 o successiva.
• È 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.

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

Da	A	Accesso API Kubernetes	Carichi di lavoro 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: è stata rilevata una notevole interruzione del servizio. durante la migrazione.
• Non interessato: non si verificano interruzioni del servizio o sono quasi impercettibili.

Preparati per la migrazione

Se il 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:

• Alloca un indirizzo IP per il nuovo VIP del piano di controllo, per Campo loadBalancer.vips.controlPlaneVIP nel cluster di amministrazione di configurazione del deployment.
• 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. Ciò garantisce che gli indirizzi IP appena allocati per i nodi del piano di controllo possano raggiungere tutte le API richieste e altre destinazioni, come descritto in Firewall per i cluster di amministrazione.

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

F5 BIG-IP

Se il tuo cluster di amministrazione utilizza la configurazione integrata F5 BIG-IP, effettua 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à ad alta disponibilità, mantieni lo stesso valore. Se esegui la migrazione da un cluster amministrativo non ad alta disponibilità a un cluster amministrativo ad alta disponibilità, 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 192.0.2.50
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. Conserva la sezione network.hostConfig.
3. Imposta o mantieni il valore del campo loadBalancer.vips.controlPlaneVIP]5. Se il cluster di amministrazione è già ad alta disponibilità, puoi mantenere valore. Se esegui la migrazione da un cluster amministrativo non HA a un cluster amministrativo HA, modifica il valore del campo loadBalancer.vips.controlPlaneVIP in base all'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 192.0.2.50
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 cluster di amministrazione è già ad alta disponibilità, passa nella 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 crittografia dei secret sempre attiva sia stata abilitata nel cluster di amministrazione alla versione 1.14 o precedenti, devi ruota 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 è possibile che il cluster utilizzi 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.

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

Se necessario, ruota la chiave di crittografia

Se i passaggi nella sezione precedente hanno mostrato che devi ruotare di crittografia dei dati, segui questi passaggi:

1. Aumenta keyVersion nel file di configurazione del cluster di amministrazione.

2. Aggiorna il cluster di amministrazione:

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

   In questo modo viene creata una nuova chiave che corrisponde al nuovo numero di versione e viene crittografata nuovamente ogni segreto e cancella in modo sicuro i vecchi segreti. Tutti i nuovi secret successivi vengono criptati utilizzando la nuova chiave di crittografia.

Avviso: se hai avviato la migrazione senza ruotare la 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 assegnati ai nodi del piano di controllo.
2. Assicurati di aver compilato il campo network.hostConfig . Questa sezione contiene informazioni su server NTP, server DNS e DNS. dai domini di ricerca 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 il criterio loadBalancer.kind è impostato su "ManualLB", imposta loadBalancer.manualLB.controlPlaneNodePort a 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 cluster di amministrazione utilizza il bilanciamento del carico manuale, completa il passaggio .

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 che hai specificato sezione network.controlPlaneIPBlock, configura questa mappatura bilanciatore del carico esterno (come 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 cluster di amministrazione di configurazione del deployment. Tutte le impostazioni sono immutabili, a meno che non si aggiorni il 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 cluster di amministrazione kubeconfig.
• 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 un'alta disponibilità ad alta disponibilità, il VIP del piano di controllo meno recente continua e può essere utilizzato 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.

MetalLB

Se hai eseguito la migrazione a MetalLB, verifica che i componenti MetalLB funzionino 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 disattivate per il cluster amministrativo. Puoi trovare i nomi delle VM Seesaw nella sezione vmnames del seesaw-for-gke-admin.yaml file nella directory di configurazione.

ManualLB

Dopo aver aggiornato i cluster per utilizzare il bilanciamento del carico manuale, il traffico verso senza interruzioni. Il motivo è che le risorse F5 esistenti esistono ancora, che 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