Après la conversion automatique d'une spécification de cluster Tanzu Kubernetes au format d'API v1alpha2, pour effectuer une mise à jour continue du cluster Tanzu Kubernetes, généralement effectuée en modifiant la version de Tanzu Kubernetes, vous devrez peut-être effectuer un prétraitement de la spécification de cluster pour éviter les erreurs.
Conversion automatique des spécifications du cluster
Pour mettre à jour votre environnement vSphere with Tanzu vers l'API Service Tanzu Kubernetes Grid v1alpha2, vous mettez à jour le Cluster superviseur où le service s'exécute.
Une fois que le Service Tanzu Kubernetes Grid exécute l'API v1alpha2, le système convertit automatiquement toutes les spécifications de cluster Tanzu Kubernetes existantes du format v1alpha1 au format v1alpha2. Pendant le processus de conversion automatique, le système crée et remplit les champs attendus pour chaque manifeste de cluster. Obsolescences et ajouts d'API répertorie les champs de spécification de cluster nouveaux et obsolètes dans l'API v1alpha2.
Pour mettre à jour la version Tanzu Kubernetes d'un cluster dont le manifeste a été converti automatiquement au format v1alpha2, vous devez effectuer un pré-traitement manuel afin d'éviter les erreurs. Exemples de mise à jour de cluster répertorie différentes options.
Obsolescences et ajouts d'API
| Paramètres obsolètes | Nouveaux paramètres | Commentaires |
|---|---|---|
|
|
|
Doit utiliser le format TKR NAME. Reportez-vous aux exemples. |
|
|
|
Dans un cluster converti, le bloc spec.topology.workers devient spec.topology.nodePools[0]. La première entrée de la liste |
|
|
|
count a été remplacé par replicas |
|
|
|
class a été remplacé par vmClass |
| S.O. |
|
Valeurs clé-paire facultatives pour organiser et classer les objets ; les étiquettes sont propagées aux nœuds créés |
| S.O. |
|
Marques facultatives avec lesquelles enregistrer les nœuds ; les marques définies par l'utilisateur sont propagées aux nœuds créés |
Le format NOM TKR est requis
Outre les champs spec.distribution.version obsolètes, le format de DISTRIBUTION permettant de spécifier la version Tanzu Kubernetes n'est pas pris en charge. Cela signifie que vous ne pouvez pas utiliser les formats de chaîne suivants pour référencer la version cible : 1.21.2+vmware.1-tkg.1.ee25d55, 1.21.2 et 1.21.
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]
Utiliser kubectl edit pour mettre à jour une spécification de cluster
Si vous devez apporter des modifications à une spécification de cluster afin qu'elle soit conforme à l'API TKGS v1alpha2, utilisez la méthode kubectl edit. N'utilisez pas la méthode kubectl patch pour ce type de mise à jour. Reportez-vous à la section Méthodes de modification du manifeste du cluster. Pour configurer kubectl avec un éditeur, reportez-vous à la section Spécifier un éditeur de texte par défaut pour Kubectl.
Exemples de mise à jour de cluster
Étant donné que la modification de spec.distribution.version est le moyen le plus courant de déclencher une mise à jour continue du cluster (reportez-vous à Mettre à jour les clusters Tanzu Kubernetes), et que ce champ est obsolète dans l'API v1alpha2, il convient de prendre en compte certains éléments et des recommandations de pré-traitement à suivre pour éviter d'éventuels problèmes de mise à niveau du cluster.
Les exemples suivants montrent comment mettre à jour la version d'un cluster Tanzu Kubernetes provisionné à l'aide de l'API v1alpha1 vers un système qui exécute l'API v1alpha2.
Exemple 1 de mise à niveau du cluster : utiliser une référence NOM TKR unique dans le plan de contrôle
L'approche recommandée consiste à supprimer tous les blocs nodePools[*].tkr.reference.name de la spécification convertie et à mettre à jour le controlPlane.tkr.reference.name avec le NOM TKR de la version cible. Dans ce cas, la même version Tanzu Kubernetes est propagée à tous les nœuds nodePools[*].
À l'avenir, les versions Tanzu Kubernetes peuvent être différentes entre les controlPlane et les nodePools[*]. Actuellement, toutefois, toutes les versions d'un cluster doivent correspondre afin qu'il suffise de placer une seule référence NOM TKR dans controlPlane.
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
Exemple 2 de mise à niveau de cluster : utiliser une référence TKR NAME pour chaque pool de nœuds
Le second exemple consiste à placer le NOM TKR dans le bloc tkr.reference.name pour les topologies controlPlane et nodePools[*].
Cette approche a l'avantage d'être prête pour les versions ultérieures lorsque la version Tanzu Kubernetes peut être différente entre les pools de nœuds. Actuellement, elles doivent correspondre.
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
Exemple 3 de mise à niveau de cluster : utiliser les champs de distribution obsolètes
spec.distribution.fullVersion et
spec.distribution.version, puis à supprimer manuellement tous les blocs
tkr.reference.name. Vous devez inclure les deux champs, avec l'un utilisant le format NOM TKR et l'autre annulé. Les raccourcis de version tels que
v1.21.2 et
v1.21 ne sont pas pris en charge.
spec.distribution.version n'est pas prise en charge.
fullVersion avec le NOM TKR et une valeur null (vide) dans le champ
version. Toutes les entrées
tkr.reference.name sont supprimées.
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
version avec le NOM TKR et une valeur null (vide) dans le champ
fullVersion. Même si vous utilisez le champ
version, les raccourcis de version ne sont pas pris en charge. Toutes les entrées
tkr.reference.name sont supprimées.
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
