Anthos clusters on VMware ora è Google Distributed Cloud (solo software) per VMware. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Esegui la migrazione di un cluster utente a Controlplane V2

Questo documento mostra come eseguire la migrazione di un cluster utente versione 1.29 utilizzando kubeception al piano di controllo V2. Se i tuoi cluster sono alla versione 1.30 o successiva, ti consigliamo di seguire le istruzioni riportate in Pianificare la migrazione dei cluster alle funzionalità consigliate.

1.29: Anteprima
1.28: Non disponibile

Informazioni sui piani di controllo dei cluster utente

Prima di Google Distributed Cloud versione 1.13, il piano di controllo per un cluster utente eseguito su uno o più nodi in un cluster di amministrazione. Questo tipo di piano di controllo noto come kubeception. Nella versione 1.13, è stato introdotto il piano di controllo V2 per i nuovi cluster utente. Quando il control plane v2 è abilitato, il control plane per il cluster utente viene eseguito nel cluster utente stesso.

Ecco i vantaggi del piano di controllo V2:

Isolamento dei guasti. Un errore del cluster di amministrazione non influisce sui cluster utente.
Separazione operativa. L'upgrade di un cluster di amministrazione non causa tempi di riposo per i cluster utente.
Separazione del deployment. Puoi inserire i cluster di amministrazione e utente diversi domini o siti geografici in errore. Ad esempio, un cluster di utenti in una località edge può trovarsi in una località geografica diversa da quella del cluster di amministrazione.

Requisiti

Per eseguire la migrazione di un cluster utente a Controlplane v2, il cluster utente deve soddisfare i seguenti requisiti:

Il cluster utente deve essere della versione 1.29 o successive. Il cluster di amministrazione e I pool di nodi possono essere una o due versioni secondarie inferiori al cluster utente. Se necessario, esegui l'upgrade del cluster.
Nel cluster utente deve essere abilitato Dataplane V2. Questo campo è immutabile, quindi se Dataplane V2 non è abilitato sulla non puoi eseguirne la migrazione al piano di controllo V2.
Il cluster utente deve essere configurato in modo da utilizzare MetalLB o una configurazione manuale con il bilanciatore del carico di rete passthrough esterno regionale. Se il cluster utente utilizza il bilanciatore del carico SeeSaw, puoi eseguire la migrazione a MetalLB.
Esamina il documento di pianificazione degli indirizzi IP, e assicurati di avere a disposizione indirizzi IP sufficienti per i nodi del control plane del cluster utente. I nodi del piano di controllo richiedono indirizzi IP statici, mentre è necessario un indirizzo IP aggiuntivo per un nuovo IP virtuale (VIP) del piano di controllo.

Prepararsi per la migrazione

Se crittografia dei secret sempre attiva sia stata abilitata sul cluster utente, devi seguire Disabilita la crittografia dei secret sempre attivi 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 avviare la migrazione, esegui il seguente comando per verificare se la crittografia dei secret sempre attiva è stata attivata in un determinato momento:

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, significa che la crittografia dei secret sempre attiva non è mai stata attivata. Puoi avviare la migrazione.

Se l'output del comando precedente non è vuoto, significa che la crittografia dei secret sempre attiva è stata abilitata in precedenza. Prima di eseguire la migrazione, devi eseguire i passaggi della sezione successiva per assicurarti che il nuovo piano di controllo V2 un cluster può decriptare i secret.

L'esempio seguente mostra un campo non vuoto output:

{"generatedKeyVersions":{"keyVersions":[1]}}

Disabilita la crittografia dei secret sempre attivi e decripta i secret, se necessario

Per disabilitare la crittografia dei secret sempre attivi e decriptare i secret, esegui la seguenti passaggi:

Nel file di configurazione del cluster utente, per disabilitare i secret sempre attivi per aggiungere 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 cluster utente file di configurazione

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

Affinché tutti i secret vengano archiviati in etcd in testo non cifrato, riapplica tutti i secret nel cluster utente:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Ora puoi avviare la migrazione al piano di controllo V2. Dopo la migrazione puoi completare questa operazione, riabilitare la crittografia dei secret sempre attivi sul cluster.

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, crea il piano di controllo per il cluster utente del piano di controllo V2 ad alta disponibilità (HA). Per passare da un cluster non HA a un cluster HA, modifica masterNode.replicas da 1 a 3.
Aggiungi l'indirizzo o gli indirizzi IP statici per il piano di controllo del cluster utente uno o più nodi network.controlPlaneIPBlock.ips .
Compila la netmask e il gateway nella network.controlPlaneIPBlock .
Se network.hostConfig è vuota, compilala.
Se il cluster di utenti utilizza il bilanciamento del carico manuale, configura il bilanciatore del carico come descritto nella sezione successiva.
Se il cluster utente utilizza il bilanciamento del carico manuale, imposta loadBalancer.manualLB.controlPlaneNodePort e loadBalancer.manualLB.konnectivityServerNodePort su 0 perché non sono necessari quando è abilitato il piano di controllo V2.
Aggiorna il loadBalancer.vips.controlPlaneVIP con il nuovo indirizzo IP per il VIP del piano di controllo. Tieni presente che deve Essere nella stessa VLAN degli IP dei nodi del piano di controllo.
Tutti i campi precedenti sono immutabili, tranne durante l'aggiornamento del cluster per la migrazione. Assicurati di controllare attentamente tutte le impostazioni.
Esegui gkectl diagnose cluster e correggi gli eventuali problemi rilevati dal comando.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
Sostituisci quanto segue:
- ADMIN_CLUSTER_KUBECONFIG: il percorso dell'amministratore kubeconfig del cluster.
- USER_CLUSTER_NAME: il nome del cluster di utenti.

Modificare la configurazione del bilanciatore del carico manuale

Se il cluster utente utilizza il bilanciamento del carico manuale, esegui il passaggio in questa sezione. In caso contrario, salta questa sezione.

Analogamente alla configurazione del bilanciatore del carico per un cluster utente CPv2, per ciascuno dei tre nuovi indirizzi IP dei nodi del piano di controllo specificati nella sezione network.controlPlaneIPBlock , configura le mappature nel bilanciatore del carico:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)

Aggiorna il cluster

Esegui questo comando per eseguire la migrazione del cluster a Controlplane V2:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Sostituisci quanto segue:

ADMIN_CLUSTER_KUBECONFIG: il percorso del cluster di amministrazione kubeconfig.
USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente.

Il comando esegue le seguenti operazioni:

Crea il piano di controllo di un nuovo cluster con il piano di controllo V2 abilitato.
Interrompi il piano di controllo Kubernetes del cluster kubeception.
Acquisisci uno snapshot etcd del cluster kubeception.
Spegni i nodi del piano di controllo del cluster kubeception. Tieni presente che per il ripristino da errori, ovvero per fare ricorso al cluster kubeception, i nodi non vengono eliminati fino al completamento della migrazione.
Ripristina i dati del cluster nel nuovo piano di controllo con lo snapshot etcd sopra indicato.
Connetti i nodi del pool di nodi del cluster kubeception al nuovo piano di controllo, a cui è possibile accedere con il nuovo controlPlaneVIP.
Riconcilia il cluster utente ripristinato in modo che soddisfi lo stato finale del cluster con ControlPlane V2 abilitato.

Note

Durante la migrazione, non ci sono tempi di inattività per i carichi di lavoro del cluster utente.
Durante la migrazione, si è verificato un tempo di inattività per il piano di controllo del cluster utente. In particolare, il piano di controllo non sarà disponibile tra il passaggio 2 e il completamento del passaggio 6. In base ai nostri test, il tempo di inattività è inferiore a 7 minuti, ma la durata effettiva dipende dall'infrastruttura.
Al termine della migrazione, i nodi del piano di controllo del cluster utente dei cluster kubeception vengono eliminati. Se nel cluster di amministrazione il campo network.ipMode.type è impostato su "statico", puoi riciclare alcuni IP statici inutilizzati rimuovendoli dal file di configurazione del cluster di amministrazione ed eseguire gkectl update admin. Puoi elencare gli oggetti del nodo del cluster di amministrazione con kubectl get nodes -o wide per vedere quali IP sono in uso.

Dopo la migrazione

Se hai disattivato la crittografia dei secret sempre attiva prima della migrazione, segui i seguenti passaggi per riattivare la funzionalità:

Nel file di configurazione del cluster utente, imposta secretsEncryption.generatedKey.disabled su false. Ad esempio:

secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: false

Aggiorna il cluster utente:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG