Creazione di una ClusterClass personalizzata

Questo argomento spiega come creare una risorsa ClusterClass personalizzata per un cluster di gestione autonomo Tanzu Kubernetes Grid (TKG), come utilizzarlo per creare cluster del carico di lavoro basati sulla classe e come utilizzare cluster basati sulla ClusterClass personalizzata.

Per basare un cluster su una ClusterClass personalizzata , impostare il valore di spec.topology.class sul nome della ClusterClass personalizzata.

Queste procedure non si applicano a TKG con un supervisore vSphere with Tanzu.

Attenzione

La ClusterClass personalizzata è una funzionalità di Kubernetes sperimentale, in base alla documentazione relativa all'API del cluster upstream. Poiché la gamma di personalizzazioni disponibili con la ClusterClass personalizzata è molto vasta, VMware non può testare o convalidare tutte le personalizzazioni possibili. I clienti sono responsabili del test, della convalida e della risoluzione dei problemi dei propri cluster con ClusterClass personalizzata. I clienti possono aprire ticket di supporto relativi ai cluster con ClusterClass personalizzata. Tuttavia, l'assistenza VMware è limitata solo al massimo sforzo possibile e non può garantire la risoluzione di tutti i problemi aperti per i cluster con ClusterClass personalizzata. I clienti devono essere consapevoli di questi rischi prima di distribuire cluster con ClusterClass personalizzata negli ambienti di produzione. Per creare cluster del carico di lavoro utilizzando la risorsa ClusterClass predefinita, eseguire le procedure indicate in Passaggi per la distribuzione del cluster.

Requisiti

Per creare una ClusterClass personalizzata, sono necessari ytt, imgpkg, la CLI di Tanzu e kubectl installati in locale. Per informazioni su come scaricare e installare ytt e imgpkg, vedere Installazione degli strumenti Carvel.

Opzioni: Modelli e specifica di un nuovo oggetto

Per creare una ClusterClass personalizzata, VMware consiglia di iniziare con il manifesto ClusterClass predefinito esistente o con i modelli YTT descritti in Creazione di un manifesto ClusterClass di base. Quando viene pubblicata una nuova versione dell'oggetto ClusterClass predefinito, ad esempio con una nuova versione di TKG, è possibile applicare l'overlay alla nuova versione per implementare le stesse personalizzazioni. Le procedure in questo argomento descrivono questo metodo di creazione di un oggetto ClusterClass personalizzato.

Per scrivere un oggetto ClusterClass completamente nuovo senza utilizzare un modello esistente, eseguire la procedura descritta in Scrittura di una ClusterClass nella documentazione di Cluster API.

Creazione di un manifesto ClusterClass di base

È possibile creare un manifesto ClusterClass di base basato sul manifesto ClusterClass predefinito o sui modelli YTT che Tanzu Kubernetes Grid fornisce. Tutti i cluster personalizzati creati devono essere basati su questo manifesto ClusterClass di base. Il processo comprende 3 passaggi:

1. Recuperare il manifesto di ClusterClass o i modelli YTT predefiniti per la piattaforma di destinazione.
2. Utilizzare il manifesto ClusterClass predefinito o i modelli YTT per generare un manifesto ClusterClass di base personalizzato, che includa informazioni sull'infrastruttura.
3. Utilizzare questo manifesto ClusterClass di base come modello da cui creare i cluster personalizzati.

Sono disponibili tre metodi con cui è possibile creare un manifesto ClusterClass di base per i cluster.

• Metodo 1: Ottenere il manifesto di base direttamente da un cluster di gestione. Questo è il metodo più semplice. Quando si distribuisce un cluster di gestione, viene generato automaticamente un manifesto di base predefinito. Questo manifesto di base include la configurazione dell'infrastruttura fornita durante la distribuzione del cluster di gestione. È possibile utilizzarlo direttamente come manifesto ClusterClass di base.
• Metodo 2: Ottenere modelli YTT dalla CLI di Tanzu (utenti avanzati). Quando si installa la CLI di Tanzu, nella macchina vengono installati i modelli YTT. Per creare un manifesto di base da questi modelli YTT, è necessario creare un overlay YTT che fornisca la configurazione dell'infrastruttura.
• Metodo 3: Ottenere modelli YTT dal registro immagini TKG (utenti avanzati). È inoltre possibile ottenere i modelli YTT dal registro immagini TKG. Per creare un manifesto di base da questi modelli YTT, è necessario creare un overlay YTT che fornisca la configurazione dell'infrastruttura.

Importante

I metodi 2 e 3 sono destinati agli utenti avanzati che devono soddisfare i seguenti casi d'uso:

• Si desidera generare definizioni ClusterClass personalizzate per il sistema CI, senza distribuire un cluster di gestione autonomo.
• Si desidera che i cluster del carico di lavoro utilizzino un'infrastruttura diversa da quella dei cluster di gestione.

Metodo 1: Ottenere il manifesto di base direttamente da un cluster di gestione

In Tanzu Kubernetes Grid v2.3.0 e versioni successive, dopo aver distribuito un cluster di gestione, è possibile trovare il manifesto ClusterClass predefinito nella cartella ~/.config/tanzu/tkg/clusterclassconfigs.

Per visualizzare il manifesto per le piattaforme di destinazione in cui è stato distribuito un cluster di gestione, eseguire il comando seguente:

tree ~/.config/tanzu/tkg/clusterclassconfigs/

Ad esempio, se è stato distribuito un cluster di gestione in vSphere, verrà visualizzato il file YAML seguente.

.config/tanzu/tkg/clusterclassconfigs/
└── tkg-vsphere-default-v1.1.0.yaml
 
1 directory, 1 file

Il manifesto generato contiene informazioni sulla piattaforma di destinazione estratte dalla distribuzione del cluster di gestione. È possibile utilizzare direttamente questo come manifesto di base per la creazione personalizzata di ClusterClass. Per i passaggi successivi, vedere Personalizzazione del manifesto ClusterClass di base.

Metodo 2: Ottenere i modelli YTT dalla CLI di Tanzu

Dopo aver installato la CLI di Tanzu v1.0.0 o versioni successive, ma prima di distribuire un cluster di gestione, è possibile trovare i modelli YTT per la ClusterClass predefinita nella cartella ~/.config/tanzu/tkg/providers/infrastructure-<provider name>/<provider version>/cconly. È possibile utilizzare questi modelli per creare un manifesto di base per la creazione di una ClusterClass personalizzata.

1. Per trovare i modelli, eseguire il comando appropriato per la piattaforma di destinazione.

   vSphere

   tree ~/.config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly
   

   Verranno visualizzati i seguenti file YAML.

   .config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly
   ├── base.yaml
   ├── overlay-kube-apiserver-admission.yaml
   └── overlay.yaml
   
   1 directory, 3 files
   

   AWS

   tree ~/.config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly
   

   Verranno visualizzati i seguenti file YAML.

   .config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly
   ├── base.yaml
   ├── overlay-kube-apiserver-admission.yaml
   └── overlay.yaml
   

   Azure

   tree ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly/
   

   Verranno visualizzati i seguenti file YAML.

   .config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly/
   ├── base.yaml
   ├── overlay-kube-apiserver-admission.yaml
   └── overlay.yaml
   

2. Creare un file data-value YTT denominato user_input.yaml con il seguente contenuto.

   #@data/values
   
   #@overlay/match-child-defaults missing_ok=True
   ---
   

3. Aggiungere i valori di configurazione appropriati per la piattaforma di destinazione in user_input.yaml.

   È possibile utilizzare i valori di configurazione utilizzati durante la distribuzione di un cluster di gestione. Ad esempio, un file user_input.yaml per vSphere sarà simile al seguente:

   #@data/values
   
   #@overlay/match-child-defaults missing_ok=True
   ---
   ENABLE_MHC: true
   ENABLE_MHC_CONTROL_PLANE: true
   ENABLE_MHC_WORKER_NODE: true
   MHC_UNKNOWN_STATUS_TIMEOUT: 5m
   MHC_FALSE_STATUS_TIMEOUT: 12m
   MHC_MAX_UNHEALTHY_CONTROL_PLANE: 100%
   MHC_MAX_UNHEALTHY_WORKER_NODE: 100%
   NODE_STARTUP_TIMEOUT: 20m
   VSPHERE_TLS_THUMBPRINT: 0A:B4:8F:2E:E4:34:82:90:D5:6A:F8:77:8C:8C:51:24:D2:49:3B:E8
   VSPHERE_DATACENTER: /dc0
   VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-0
   VSPHERE_FOLDER: /dc0/vm
   VSPHERE_NETWORK: /dc0/network/VM Network
   VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources
   VSPHERE_SERVER: xxx.xxx.xxx.xxx
   VSPHERE_USERNAME: [email protected]
   VSPHERE_CONTROL_PLANE_DISK_GIB: "20"
   VSPHERE_CONTROL_PLANE_MEM_MIB: "8192"
   VSPHERE_CONTROL_PLANE_NUM_CPUS: "4" VSPHERE_WORKER_DISK_GIB: "20"
   VSPHERE_WORKER_MEM_MIB: "8192"
   VSPHERE_WORKER_NUM_CPUS: "4"
   VSPHERE_CLUSTER_CLASS_VERSION: "v1.1.0"       # change it to the version in TKG BOM
   NAMESPACE: "tkg-system"                       # DO NOT change it
   

4. Utilizzare ytt per generare il manifesto ClusterClass di base per la piattaforma di destinazione.

   vSphere

   ytt -f ~/.config/tanzu/tkg/providers/infrastructure-vsphere/v1.7.0/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
   

   AWS

   ytt -f ~/.config/tanzu/tkg/providers/infrastructure-aws/v2.1.3/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
   

   Azure

   ytt -f ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
   

Dopo aver generato un manifesto di base per l'infrastruttura, per i passaggi successivi vedere Personalizzazione del manifesto ClusterClass di base.

Metodo 3: Ottenere modelli YTT dal registro immagini TKG

I modelli YTT per la ClusterClass predefinita sono disponibili per il download anche dal repository di immagini TKG. È possibile utilizzare questi modelli per creare un manifesto di base per la creazione di una ClusterClass personalizzata.

1. Estrarre i modelli YTT dall'immagine providerTemplate nel registro TKG ufficiale.

   Per TKG v2.3.1, il tag dell'immagine providerTemplate è v0.30.2. È possibile trovare la versione del tag nel file BOM TKG cercando providerTemplateImage.

   imgpkg pull -i projects.registry.vmware.com/tkg/tanzu_core/provider/provider-templates:v0.30.2 -o providers
   

   Viene visualizzato un output simile al seguente:

   Pulling image 'projects.registry.vmware.com/tkg/tanzu_core/provider/provider-templates@sha256:b210d26c610800f5da4b3aa55bfbc8ffae9275fa2c4073a2b1332e2045a6e1da'
   Extracting layer 'sha256:3ba336232c0e616b2b6c8f263593497c5a059a645f4c6137ea0eb658f4a8538a' (1/1)
   
   Succeeded
   

   I file del modello YAML vengono scaricati in una cartella providers.

2. Creare un file data-value YTT denominato user_input.yaml con il seguente contenuto.

   #@data/values
   
   #@overlay/match-child-defaults missing_ok=True
   ---
   

3. Aggiungere i valori di configurazione appropriati per la piattaforma di destinazione in user_input.yaml.

   È possibile utilizzare i valori di configurazione utilizzati durante la distribuzione di un cluster di gestione. Ad esempio, un file user_input.yaml per vSphere sarà simile al seguente:

   #@data/values
   
   #@overlay/match-child-defaults missing_ok=True
   ---
   ENABLE_MHC: true
   ENABLE_MHC_CONTROL_PLANE: true
   ENABLE_MHC_WORKER_NODE: true
   MHC_UNKNOWN_STATUS_TIMEOUT: 5m
   MHC_FALSE_STATUS_TIMEOUT: 12m
   MHC_MAX_UNHEALTHY_CONTROL_PLANE: 100%
   MHC_MAX_UNHEALTHY_WORKER_NODE: 100%
   NODE_STARTUP_TIMEOUT: 20m
   VSPHERE_TLS_THUMBPRINT: 0A:B4:8F:2E:E4:34:82:90:D5:6A:F8:77:8C:8C:51:24:D2:49:3B:E8
   VSPHERE_DATACENTER: /dc0
   VSPHERE_DATASTORE: /dc0/datastore/sharedVmfs-0
   VSPHERE_FOLDER: /dc0/vm
   VSPHERE_NETWORK: /dc0/network/VM Network
   VSPHERE_RESOURCE_POOL: /dc0/host/cluster0/Resources
   VSPHERE_SERVER: xxx.xxx.xxx.xxx
   VSPHERE_USERNAME: [email protected]
   VSPHERE_CONTROL_PLANE_DISK_GIB: "20"
   VSPHERE_CONTROL_PLANE_MEM_MIB: "8192"
   VSPHERE_CONTROL_PLANE_NUM_CPUS: "4" VSPHERE_WORKER_DISK_GIB: "20"
   VSPHERE_WORKER_MEM_MIB: "8192"
   VSPHERE_WORKER_NUM_CPUS: "4"
   VSPHERE_CLUSTER_CLASS_VERSION: "v1.1.0"       # change it to the version in TKG BOM
   NAMESPACE: "tkg-system"                       # DO NOT change it
   

4. Utilizzare ytt per generare il manifesto ClusterClass di base per la piattaforma di destinazione.

   vSphere

   ytt -f providers/infrastructure-vsphere/v1.7.0/cconly -f providers/config_default.yaml -f user_input.yaml
   

   AWS

   ytt -f providers/infrastructure-aws/v2.1.3/cconly -f providers/config_default.yaml -f user_input.yaml
   

   Azure

   ytt -f ~/.config/tanzu/tkg/providers/infrastructure-azure/v1.9.2/cconly -f ~/.config/tanzu/tkg/providers/config_default.yaml -f user_input.yaml
   

Dopo aver generato un manifesto di base per l'infrastruttura, per i passaggi successivi vedere Personalizzazione del manifesto ClusterClass di base.

Personalizzazione del manifesto ClusterClass di base

Per personalizzare il manifesto ClusterClass, creare file di overlay ytt insieme al manifesto. L'esempio seguente illustra come modificare un parametro del kernel Linux nella definizione di ClusterClass.

1. Creare una cartella custom con la struttura seguente:

   tree custom
   custom
   |-- overlays
       |-- filter.yaml
       |-- kernels.yaml
   

2. Modificare custom/overlays/kernels.yaml.

   Ad esempio, aggiungere nfConntrackMax come variabile e definire una patch per tale variabile che aggiunga al suo valore il parametro net.netfilter.nf_conntrack_max per i nodi del piano di controllo.

   Questo overlay aggiunge un comando al campo preKubeadmCommands per scrivere la configurazione in sysctl.conf. Per rendere effettiva l'impostazione, aggiungere il comando sysctl -p per applicare questa modifica. Le definizioni di ClusterClass predefinite non sono modificabili, quindi questo overlay modifica anche il nome della ClusterClass personalizzata e tutti i relativi modelli aggiungendo -extended.

   cat custom/overlays/kernels.yaml
   #@ load("@ytt:overlay", "overlay")
   
   #@overlay/match by=overlay.subset({"kind":"ClusterClass"})
   ---
   apiVersion: cluster.x-k8s.io/v1beta1
   kind: ClusterClass
   metadata:
     name: tkg-vsphere-default-v1.1.0-extended
   spec:
     variables:
     - name: nfConntrackMax
       required: false
       schema:
         openAPIV3Schema:
           type: string
     patches:
     - name: nfConntrackMax
       enabledIf: '{{ not (empty .nfConntrackMax) }}'
       definitions:
         - selector:
             apiVersion: controlplane.cluster.x-k8s.io/v1beta1
             kind: KubeadmControlPlaneTemplate
             matchResources:
               controlPlane: true
           jsonPatches:
             - op: add
               path: /spec/template/spec/kubeadmConfigSpec/preKubeadmCommands/-
               valueFrom:
                 template: echo "net.netfilter.nf_conntrack_max={{ .nfConntrackMax }}" >> /etc/sysctl.conf
             - op: add
               path: /spec/template/spec/kubeadmConfigSpec/preKubeadmCommands/-
               value: sysctl -p
   

3. Rimuovere le risorse che non si desidera modificare.

   In questo esempio, tutti i modelli sono pensati per essere condivisi tra la ClusterClass personalizzata e quella predefinita in modo che vengano tutti rimossi. È inoltre possibile creare un modello personalizzato basato sul modello predefinito nello stesso modo, nel qual caso assicurarsi che kind non venga escluso.

   cat custom/overlays/filter.yaml
   #@ load("@ytt:overlay", "overlay")
   
   #@overlay/match by=overlay.not_op(overlay.subset({"kind": "ClusterClass"})),expects="0+"
   ---
   #@overlay/remove
   

4. Utilizzare il manifesto ClusterClass predefinito per generare la ClusterClass di base.

   ytt -f tkg-vsphere-default-v1.1.0.yaml -f custom/overlays/filter.yaml > default_cc.yaml
   

5. Generare la ClusterClass personalizzata.

   ytt -f tkg-vsphere-default-v1.1.0.yaml -f custom/ > custom_cc.yaml
   

6. (Facoltativo) Verificare la differenza tra la ClusterClass predefinita e quella personalizzata per confermare che le modifiche siano state applicate.

   diff default_cc.yaml custom_cc.yaml
   

   Viene visualizzato un output simile al seguente:

   4c4
   <   name: tkg-vsphere-default-v1.1.0
   ---
   >   name: tkg-vsphere-default-v1.1.0-extended
   638a639,643
   >   - name: nfConntrackMax
   >     required: false
   >     schema:
   >       openAPIV3Schema:
   >         type: string
   2607a2613,2628
   >   - name: nfConntrackMax
   >     enabledIf: '{{ not (empty .nfConntrackMax) }}'
   >     definitions:
   >     - selector:
   >         apiVersion: controlplane.cluster.x-k8s.io/v1beta1
   >         kind: KubeadmControlPlaneTemplate
   >         matchResources:
   >           controlPlane: true
   >       jsonPatches:
   >       - op: add
   >         path: /spec/template/spec/kubeadmConfigSpec/preKubeadmCommands/-
   >         valueFrom:
   >           template: echo "net.netfilter.nf_conntrack_max={{ .nfConntrackMax }}" >> /etc/sysctl.conf
   >       - op: add
   >         path: /spec/template/spec/kubeadmConfigSpec/preKubeadmCommands/-
   >         value: sysctl -p
   

In questo esempio, si può notare che -extended è stato aggiunto al nome del cluster.

Installazione della ClusterClass personalizzata nel cluster di gestione

Per consentire al cluster di gestione di utilizzare la ClusterClass personalizzata, installarla applicando il nuovo manifesto.

1. Applicare il manifesto ClusterClass.

   kubectl apply -f custom_cc.yaml
   

   L'output dovrebbe essere il seguente.

   clusterclass.cluster.x-k8s.io/tkg-vsphere-default-v1.1.0-extended created
   

2. Controllare se la ClusterClass personalizzata è stata propagata nello spazio dei nomi predefinito, ad esempio:

   kubectl get clusterclass
   

   L'output dovrebbe essere il seguente.

   NAME                                  AGE
   tkg-vsphere-default-v1.1.0            2d23h
   tkg-vsphere-default-v1.1.0-extended   11s
   

Generazione di un manifesto del cluster del carico di lavoro personalizzato

Dopo aver creato la ClusterClass personalizzata, è possibile utilizzarla per creare un nuovo cluster del carico di lavoro che includa la personalizzazione.

1. Eseguire tanzu cluster create con l'opzione --dry-run per generare un manifesto del cluster da un file di configurazione del cluster standard.

   tanzu cluster create --file workload-1.yaml --dry-run > default_cluster.yaml
   

2. Creare un overlay ytt o modificare direttamente il manifesto del cluster.

   L'opzione consigliata consiste nel creare un overlay ytt, ad esempio cluster_overlay.yaml, per eseguire le operazioni seguenti:

   • Sostituire il valore di topology.class con il nome della ClusterClass predefinita
   • Aggiungere le variabili personalizzate al blocco variables, con un valore predefinito

   Come per la modifica delle specifiche degli oggetti ClusterClass, l'utilizzo di un overlay come indicato di seguito consente di applicare automaticamente le modifiche ai nuovi oggetti ogni volta che viene rilasciata una nuova versione del cluster upstream.

   #@ load("@ytt:overlay", "overlay")
   
   #@overlay/match by=overlay.subset({"kind":"Cluster"})
   ---
   apiVersion: cluster.x-k8s.io/v1beta1
   kind: Cluster
   spec:
     topology:
       class: tkg-vsphere-default-v1.1.0-extended
       variables:
       - name: nfConntrackMax
         value: "1048576
   

3. Generare il manifesto custom_cluster.yaml:

   ytt -f default_cluster.yaml -f cluster_overlay.yaml > custom_cluster.yaml
   

4. (Facoltativo) Come per la ClusterClass precedente, è possibile eseguire diff per confrontare il manifesto della classe del cluster personalizzata con un cluster predefinito basato sulla classe, ad esempio:

   diff custom_cluster.yaml default_cluster.yaml
   

   Viene visualizzato un output simile al seguente:

   <     class: tkg-vsphere-default-v1.1.0
   ---
   >     class: tkg-vsphere-default-v1.1.0-extended
   142a143,144
   >     - name: nfConntrackMax
   >       value: "1048576"
   

Creazione di un cluster personalizzato

Creare un cluster del carico di lavoro personalizzato in base al manifesto personalizzato generato in precedenza, come indicato di seguito.

1. Creare il cluster.

   tanzu cluster create -f custom_cluster.yaml
   

2. Controllare le proprietà degli oggetti creati.

   Ad esempio, con la modifica del kernel precedente, recuperare l'oggetto KubeadmControlPlane e verificare che la configurazione del kernel sia impostata:

   kubectl get kcp workload-1-jgwd9 -o yaml
   

   Viene visualizzato un output simile al seguente:

   apiVersion: controlplane.cluster.x-k8s.io/v1beta1
   kind: KubeadmControlPlane
   ...
       preKubeadmCommands:
       - hostname "{{ ds.meta_data.hostname }}"
       - echo "::1         ipv6-localhost ipv6-loopback" >/etc/hosts
       - echo "127.0.0.1   localhost" >>/etc/hosts
       - echo "127.0.0.1   {{ ds.meta_data.hostname }}" >>/etc/hosts
       - echo "{{ ds.meta_data.hostname }}" >/etc/hostname
       - echo "net.netfilter.nf_conntrack_max=1048576" >> /etc/sysctl.conf
       - sysctl -p
   ...
   

3. Accedere a un nodo del piano di controllo e verificare che il valore di sysctl.conf sia stato modificato:

   capv@workload-1-jgwd9:~$ sudo cat /etc/sysctl.conf
   ...
   net.ipv6.neigh.default.gc_thresh3=16384
   fs.file-max=9223372036854775807
   net.netfilter.nf_conntrack_max=1048576
   

Aggiornamento dei cluster personalizzati

Se sono stati creati cluster personalizzati con una versione precedente, è possibile aggiornarli alla versione di TKG più recente.

Preparazione all'aggiornamento dei cluster

Prima di aggiornare i cluster, è necessario eseguire i passaggi preparatori.

1. Prima di aggiornare il cluster di gestione, creare cluster di test con la versione del manifesto personalizzato creato per la versione precedente.

   Ad esempio, creare un cluster personalizzato denominato test-upgrade.

2. Recuperare le informazioni sulle versioni di ClusterClass disponibili con il cluster di gestione TKG 2.2.

   kubectl get clusterclass
   

   Se sono stati creati cluster personalizzati con TKG v2.2.0, la versione di ClusterClass deve essere 1.0.0. Ad esempio:

   NAME                                  AGE
   tkg-vsphere-default-extended-v1.0.0   21m
   tkg-vsphere-default-v1.0.0            10d
   

3. Recuperare le informazioni sulle versioni di ClusterClass in esecuzione nel cluster test-upgrade.

   kubectl get cluster test-upgrade -o jsonpath='{.spec.topology.class}'
   

   L'output deve essere tkg-vsphere-default-extended-v1.0.0.

4. Seguire le istruzioni riportate in Aggiornamento dei cluster di gestione autonomi per aggiornare il cluster di gestione a TKG 2.3.

5. Recuperare le informazioni sulla versione di ClusterClass disponibile dopo l'aggiornamento del cluster di gestione alla versione v.2.3.

   kubectl get cluster mgmt-cluster-name -n tkg-system -o jsonpath='{.spec.topology.class}'
   

   L'output deve essere tkg-vsphere-default-v1.1.0 se il cluster di gestione è in esecuzione in vSphere.

6. Eseguire le procedure in Creazione di un manifesto ClusterClass di base e Personalizzazione del manifesto ClusterClass di base per creare una nuova versione del manifesto ClusterClass.
   • Ad esempio, denominare la nuova ClusterClass personalizzata tkg-vsphere-default-v1.1.0-extended e includere le stesse variabili personalizzate della versione precedente tkg-vsphere-default-extended-v1.0.0.
   • Denominare il nuovo overlay custom_cc.yaml.

7. Installare la nuova ClusterClass personalizzata nel cluster di gestione.

   kubectl apply -f custom_cc.yaml
   

8. Recuperare le informazioni sulle versioni di ClusterClass ora disponibili con il cluster di gestione.

   kubectl get clusterclass
   

   Devono essere visualizzate sia le versioni precedenti sia le versioni più recenti.

   NAME                                  AGE
   tkg-vsphere-default-extended-v1.0.0   61m
   tkg-vsphere-default-v1.0.0            10d
   tkg-vsphere-default-v1.1.0            25m
   tkg-vsphere-default-v1.1.0-extended   15s
   

Esecuzione dell'aggiornamento

Dopo aver eseguito i passaggi preparatori, è possibile testare l'aggiornamento nel cluster di prova prima di aggiornare i cluster di produzione.

1. Ricreare la base del cluster test-upgrade dalla versione precedente della ClusterClass personalizzata a quella nuova.

   kubectl patch cluster test-upgrade --type merge -p '{"spec": {"topology": {"class": "tkg-vsphere-default-v1.1.0-extended"}}}'   
   

   L'output deve essere cluster.cluster.x-k8s.io/test-upgrade patched.

2. Recuperare le informazioni sulla versione di ClusterClass ora in esecuzione nel cluster test-upgrade.

   kubectl get cluster test-upgrade -o jsonpath='{.spec.topology.class}'
   

   L'output deve essere tkg-vsphere-default-v1.1.0-extended. In precedenza era tkg-vsphere-default-extended-v1.0.0.

3. Attendere alcuni minuti ed eseguire kubectl get cluster finché non viene visualizzato che UpdatesAvailable è stato aggiornato a true.

   kubectl get cluster test-upgrade -o yaml
   

   Quando è pronto, nell'output deve essere visualizzato un messaggio simile al seguente:

   ...
   status:
     conditions:
   ...
     - lastTransitionTime: "2023-06-19T09:59:21Z"
       message: '[v1.25.9+vmware.1-tkg.1-20230609 v1.26.4+vmware.1-tkg.1-20230609]'
       status: "True"
       type: UpdatesAvailable
     controlPlaneReady: true
     infrastructureReady: true
     observedGeneration: 5
     phase: Provisioned
   

4. Aggiornare il cluster test-upgrade.

   tanzu cluster upgrade test-upgrade    
   

5. Controllare le proprietà degli oggetti creati.

   Ad esempio, con la modifica del kernel descritta nell'esempio precedente, recuperare l'oggetto KubeadmControlPlane e verificare che la configurazione del kernel sia impostata:

   kubectl get kcp test-upgrade-nsc6d -o yaml
   

   Viene visualizzato un output simile al seguente:

   apiVersion: controlplane.cluster.x-k8s.io/v1beta1
   kind: KubeadmControlPlane
   ...
       preKubeadmCommands:
       - hostname "{{ ds.meta_data.hostname }}"
       - echo "::1         ipv6-localhost ipv6-loopback" >/etc/hosts
       - echo "127.0.0.1   localhost" >>/etc/hosts
       - echo "127.0.0.1   {{ ds.meta_data.hostname }}" >>/etc/hosts
       - echo "{{ ds.meta_data.hostname }}" >/etc/hostname
       - sed -i 's|".*/pause|"projects-stg.registry.vmware.com/tkg/pause|' /etc/containerd/config.toml
       - systemctl restart containerd
       - echo "net.netfilter.nf_conntrack_max=1048576" >> /etc/sysctl.conf
       - sysctl -p  
   

Aggiornamento dei cluster di produzione

Se l'aggiornamento di prova è stato eseguito correttamente, ripetere i passaggi da Esecuzione dell'aggiornamento nei cluster di produzione.

Nota

Se si verificano errori durante l'aggiornamento, è possibile eseguire il rollback ricreando la base del cluster dalla nuova versione della ClusterClass personalizzata alla versione precedente.

Ricreare la base di un cluster predefinito per utilizzare una ClusterClass personalizzata

Se sono stati creati cluster con la ClusterClass predefinita e si desidera aggiornarli per utilizzare una ClusterClass personalizzata, utilizzare kubectl per modificare l'oggetto cluster:

• Modificare spec.topology.class con il nome del manifesto ClassClass personalizzato.
• Modificare spec.topology.variables per aggiungere le variabili personalizzate.

Ricreare la base di un cluster personalizzato per utilizzare la ClusterClass predefinita

Se si desidera ripristinare una nuova versione della ClusterClass predefinita:

• Modificare spec.topology.class alla nuova versione della ClusterClass predefinita.
• Modificare spec.topology.variables per rimuovere le variabili personalizzate. Potrebbe essere necessario aggiungere nuove variabili definite nella nuova versione della ClusterClass predefinita.