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 a Controlplane V2. Se i tuoi cluster hanno la versione 1.30 o successive, ti consigliamo di seguire le istruzioni riportate in Pianificare la migrazione del cluster alle funzionalità consigliate.

1.29: Anteprima
1.28: Non disponibile

Informazioni sui control plane dei cluster utente

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

I vantaggi di Controlplane V2 includono:

Isolamento degli errori. Un errore del cluster di amministrazione non influisce sui cluster utente.
Separazione operativa. L'upgrade di un cluster di amministrazione non causa tempi di inattività per i cluster utente.
Separazione del deployment. Puoi posizionare i cluster di amministrazione e utente in domini di errore o siti geografici diversi. Ad esempio, un cluster utente in una località edge può trovarsi in un sito geografico diverso dal 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 la versione 1.29 o successive. Il cluster di amministrazione e i pool di nodi possono essere una o due versioni secondarie precedenti rispetto 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 sul cluster, non puoi eseguirne la migrazione a Controlplane V2.
Il cluster utente deve essere configurato per utilizzare MetalLB o un bilanciatore del carico manuale. Se il cluster utente utilizza il bilanciatore del carico SeeSaw, puoi eseguirne la migrazione a MetalLB.
Esamina il documento di pianificazione degli indirizzi IP e assicurati di avere a disposizione un numero sufficiente di indirizzi IP per i nodi del control plane del cluster utente. I nodi del control plane richiedono indirizzi IP statici e avrai bisogno di un indirizzo IP aggiuntivo per un nuovo IP virtuale (VIP) del control plane.

Prepararsi per la migrazione

Se la crittografia dei secret sempre attiva è stata abilitata nel cluster utente, devi eseguire i passaggi descritti in Disabilita la crittografia dei secret sempre attiva e decripta i secret prima di iniziare 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 è mai stata abilitata 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, la crittografia dei secret sempre attiva non è mai stata abilitata. Puoi avviare la migrazione.

Se l'output del comando precedente non è vuoto, la crittografia dei secret sempre attiva era stata abilitata in precedenza. Prima della migrazione, devi eseguire i passaggi della sezione successiva per assicurarti che il nuovo cluster Controlplane V2 possa decriptare i secret.

L'esempio seguente mostra un output non vuoto:

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

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

Per disabilitare la crittografia dei secret sempre attiva e decriptare i secret, segui questi passaggi:

Nel file di configurazione del cluster utente, per disattivare la crittografia dei secret sempre attiva, aggiungi 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 file di configurazione del cluster utente

Esegui un aggiornamento in sequenza su un DaemonSet specifico nel seguente modo:

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 come testo normale, riapplica tutti i secret nel cluster utente:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Ora puoi iniziare la migrazione a Controlplane V2. Al termine della migrazione, puoi riattivare la crittografia dei secret sempre attiva sul cluster.

Correggi i webhook dei workload configurati in modo errato

Se hai webhook che includono pod di sistema nello spazio dei nomi kube-system, aggiungi namespaceSelector per filtrare lo spazio dei nomi kube-system.

Ad esempio,

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

Aggiorna il file di configurazione del cluster utente

Apporta le seguenti modifiche al file di configurazione del cluster utente esistente:

Imposta enableControlplaneV2 su true.
Se vuoi, puoi rendere il control plane per il cluster utente Controlplane V2 a disponibilità elevata (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 i nodi del control plane del cluster utente alla sezione network.controlPlaneIPBlock.ips. L'indirizzo o gli indirizzi IP per i nodi del control plane devono trovarsi nella stessa VLAN dei nodi worker. I nomi host sono obbligatori.
Compila la maschera di rete e il gateway nella sezione network.controlPlaneIPBlock.
Se la sezione network.hostConfig è vuota, compilala.
Se il cluster utente 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, poiché non sono necessari quando Controlplane V2 è abilitato.
Aggiorna il campo loadBalancer.vips.controlPlaneVIP con il nuovo indirizzo IP per il VIP del control plane. Tieni presente che deve trovarsi nella stessa VLAN degli IP dei nodi del control plane.
Tutti i campi precedenti sono immutabili, tranne quando si aggiorna il cluster per la migrazione. Assicurati di controllare tutte le impostazioni.
Esegui gkectl diagnose cluster e risolvi 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 del file kubeconfig del cluster di amministrazione.
- USER_CLUSTER_NAME: il nome del cluster utente.

Modifica la configurazione del bilanciatore del carico manuale

Se il cluster utente utilizza il bilanciamento del carico manuale, esegui il passaggio descritto 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 control plane specificati nella sezione network.controlPlaneIPBlock, configura i mapping 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 file kubeconfig del cluster di amministrazione.
USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente.

Il comando esegue queste operazioni:

Crea il control plane di un nuovo cluster con ControlPlane V2 abilitato.
Arresta il control plane Kubernetes del cluster kubeception.
Acquisisci uno snapshot etcd del cluster kubeception.
Spegni i nodi del control plane del cluster utente del cluster kubeception. Tieni presente che, ai fini del recupero in caso di errore, ovvero del failback al cluster kubeception, i nodi non vengono eliminati fino al completamento della migrazione.
Ripristina i dati del cluster nel nuovo control plane con lo snapshot etcd menzionato in precedenza.
Collega i nodi del pool di nodi del cluster kubeception al nuovo control plane, accessibile con il nuovo controlPlaneVIP.
Riconcilia il cluster utente ripristinato in modo che soddisfi lo stato finale del cluster con ControlPlane V2 attivato.

Note

Durante la migrazione, non ci sono tempi di inattività per i workload del cluster utente.
Durante la migrazione, il control plane del cluster utente non è disponibile per un breve periodo. Più precisamente, il piano di controllo non è disponibile tra il passaggio 2 e il completamento del passaggio 6. (Il tempo di inattività è inferiore a 7 minuti in base ai nostri test, ma la durata effettiva dipende dalla tua infrastruttura).
Al termine della migrazione, i nodi del control plane dei cluster kubeception del cluster utente vengono eliminati. Se network.ipMode.type del cluster di amministrazione è impostato su "static", puoi riciclare alcuni degli IP statici inutilizzati rimuovendoli dal file di configurazione del cluster di amministrazione ed eseguendo gkectl update admin. Puoi elencare gli oggetti 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 passaggi riportati di seguito 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