Aggiornamento di una versione di Tanzu Kubernetes dopo la conversione della specifica del cluster nell'API v1alpha2 di Servizio Tanzu Kubernetes Grid

Per aggiornare la versione di Tanzu Kubernetes dopo la conversione della specifica del cluster nell'API v1alpha2, che in genere viene eseguita modificando la versione di Tanzu Kubernetes, potrebbe essere necessario eseguire alcune operazioni di pre-elaborazione della specifica per evitare errori.

Conversione automatica delle specifiche del cluster

Per aggiornare l'ambiente di vSphere with Tanzu all'API v1alpha2 di Servizio Tanzu Kubernetes Grid, aggiornare il Cluster supervisore in cui viene eseguito il servizio.

Una volta che Servizio Tanzu Kubernetes Grid esegue l'API v1alpha2, il sistema converte automaticamente tutte le specifiche dei cluster di Tanzu Kubernetes esistenti dal formato v1alpha1 al formato v1alpha2. Durante il processo di conversione automatica, il sistema crea e popola i campi previsti per ogni manifesto del cluster. Impostazioni obsolete e aggiunte all'API elenca i campi delle specifiche del cluster nuovi e obsoleti nell'API v1alpha2.

Per aggiornare la versione di Tanzu Kubernetes per un cluster il cui manifesto è stato convertito automaticamente nel formato v1alpha2, è necessario eseguire alcune operazioni di pre-elaborazione manuale per evitare errori. Esempi di aggiornamento del cluster elenca varie opzioni.

Impostazioni obsolete e aggiunte all'API

Nella tabella sono elencate le impostazioni delle specifiche del cluster considerate obsolete per l'API v1alpha2 e sostituite da nuove impostazioni.

Impostazioni obsolete	Nuove impostazioni	Commenti
`spec.distribution.version` `spec.distribution.fullVersion`	`spec.topology.controlPlane.tkr.refernece.name` `spec.topology.nodePools[*].tkr.reference.name`	È necessario utilizzare il formato TKR NAME. Vedere gli esempi.
`spec.topology.workers`	`spec.topology.nodePools[*]`	In un cluster convertito, il blocco `spec.topology.workers` diventa `spec.topology.nodePools[0]`. La prima voce nell'elenco `nodePools` è `name: workers`.
`spec.topology.controlPlane.count` `spec.topology.workers.count`	`spec.topology.controlPlane.replicas` `spec.topology.nodePools[*].replicas`	`count` è sostituito da `replicas`
`spec.topology.controlPlane.class` `spec.topology.workers.class`	`spec.topology.controlPlane.vmClass` `spec.topology.nodePools[*].vmClass`	`class` è sostituito da `vmClass`
N/D	`spec.topology.nodePools[*].labels`	Valori di coppie di chiavi facoltativi per organizzare e categorizzare gli oggetti. Le etichette vengono propagate ai nodi creati.
N/D	`spec.topology.nodePools[*].taints`	Taint facoltativi con cui registrare i nodi. I taint definiti dall'utente vengono propagati ai nodi creati.

È necessario il formato TKR NAME

Oltre ai campi spec.distribution.version considerati obsoleti, il formato DISTRIBUTION per specificare la versione di Tanzu Kubernetes non è supportato. Questo significa che non è possibile utilizzare i seguenti formati stringa per fare riferimento alla versione di destinazione: 1.21.2+vmware.1-tkg.1.ee25d55, 1.21.2 e 1.21.

Quando si fa riferimento alla versione di Tanzu Kubernetes in una specifica del cluster dell'API v1alpha2, è necessario utilizzare il formato TKR NAME, non il formato DISTRIBUTION obsoleto. Anche se il formato obsoleto viene visualizzato nella colonna UPDATES AVAILABLE, l'unico formato supportato è quello elencato nella colonna TKR NAME.

kubectl get tanzukubernetescluster
NAMESPACE        NAME            CONTROL PLANE   WORKER   TKR NAME                             AGE    READY   TKR COMPATIBLE   UPDATES AVAILABLE
tkgs-cluster-1   test-cluster    3               3        v1.21.2---vmware.1-tkg.1.ee25d55     38h    True    True             [1.21.2+vmware.1-tkg.1.ee25d55]

Esempi di aggiornamento del cluster

Poiché la modifica di spec.distribution.version è il modo più comune per attivare un aggiornamento in sequenza del cluster (vedere Aggiornamento dei cluster di Tanzu Kubernetes) e questo campo è deprecato nell'API v1alpha2, ci sono alcune considerazioni da tenere presenti e alcuni consigli di pre-elaborazione da seguire per evitare potenziali problemi di aggiornamento del cluster.

Gli esempi seguenti illustrano come aggiornare la versione di un cluster di Tanzu Kubernetes il cui provisioning è stato eseguito utilizzando l'API v1alpha1 in un sistema che esegue l'API v1alpha2.

Esempio 1 di aggiornamento del cluster: utilizzo di un singolo riferimento TKR NAME nel piano di controllo

L'approccio consigliato è rimuovere tutti i blocchi nodePools[*].tkr.reference.name dalla specifica convertita e aggiornare controlPlane.tkr.reference.name con il TKR NAME della versione di destinazione. In questo caso, la stessa versione di Tanzu Kubernetes viene propagata a tutti i nodi di nodePools[*].

In futuro, le versioni di Tanzu Kubernetes potranno essere diverse tra controlPlane e nodePools[*]. Al momento, tutte le versioni di un cluster devono tuttavia corrispondere, pertanto è sufficiente inserire un singolo riferimento TKR NAME in controlPlane.

Ad esempio:

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example1
  namespace: tkgs-cluster-ns
spec:
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      tkr:
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55
      vmClass: best-effort-medium
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium

Esempio 2 di aggiornamento del cluster: utilizzo di un riferimento TKR NAME per ogni pool di nodi

Il secondo esempio consiste nell'inserire il TKR NAME nel blocco tkr.reference.name per entrambe le topologie controlPlane e nodePools[*].

Questo approccio consente di prepararsi per le versioni future quando la versione di Tanzu Kubernetes potrà essere diversa tra i pool di nodi. Al momento devono corrispondere.

Ad esempio:

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example2
  namespace: tkgs-cluster-ns
spec:
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
      tkr:
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
      tkr:
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55

Esempio 3 di aggiornamento del cluster: utilizzo dei campi della distribuzione obsoleti

L'opzione finale consiste nell'utilizzare i campi obsoleti spec.distribution.fullVersion e spec.distribution.version e rimuovere manualmente tutti i blocchi tkr.reference.name. È necessario includere entrambi i campi, facendo in modo che uno utilizzi il formato TKR NAME e l'altro sia impostato su null. Le abbreviazioni delle versioni, come v1.21.2 e v1.21, non sono supportate.

Nota: Per la versione Tanzu Kubernetes in Ubuntu, l'utilizzo di spec.distribution.version non è supportato.

Nell'esempio seguente viene utilizzato fullVersion con il TKR NAME e un valore null (vuoto) nel campo version. Tutte le voci tkr.reference.name vengono rimosse.

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example3a
  namespace: tkgs-cluster-ns
spec:
  distribution:
    fullVersion: v1.21.2---vmware.1-tkg.1.ee25d55
    version: ""
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium

In alternativa, è possibile utilizzare il campo version con il TKR NAME e un valore null (vuoto) nel campo fullVersion. Anche se si utilizza il campo version, le abbreviazioni delle versioni non sono supportate. Tutte le voci tkr.reference.name vengono rimosse.

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example3b
  namespace: tkgs-cluster-ns
spec:
  distribution:
    fullVersion: ""
    version: v1.21.2---vmware.1-tkg.1.ee25d55
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium