Notes de mise à jour de VMware Tanzu Kubernetes Grid v2.2

Sauf indication contraire, ces notes de mise à jour s'appliquent à toutes les versions de correctif v2.2.x de Tanzu Kubernetes Grid (TKG).

TKG v2.2 est distribué sous la forme d'un module de la CLI Tanzu téléchargeable qui déploie un cluster de gestion autonome TKG avec version. TKG v2.2 prend en charge la création et la gestion de clusters de charge de travail avec un cluster de gestion autonome pouvant s'exécuter sur plusieurs infrastructures, notamment vSphere 6.7, 7 et 8, AWS et Azure.

Tanzu Kubernetes Grid v2.0, v2.2 et le superviseur vSphere with Tanzu dans vSphere 8

Important
Le superviseur vSphere with Tanzu dans vSphere 8.0.1c et versions ultérieures exécute TKG v2.2. Les versions antérieures de vSphere 8 exécutent TKG v2.0, qui n'a pas été publié indépendamment du superviseur. Les clusters de gestion autonomes qui exécutent TKG 2.x sont disponibles à partir de TKG 2.1 et versions ultérieures. Les versions ultérieures de TKG seront intégrées dans le superviseur dans les futures versions de mise à jour vSphere. Par conséquent, la version de TKG intégrée à la dernière version de vSphere with Tanzu à un moment donné peut ne pas être la même que la version autonome de TKG que vous utilisez. Toutefois, les versions de la CLI Tanzu compatibles avec toutes les versions de TKG v2.x sont entièrement compatibles avec le superviseur dans toutes les versions de vSphere 8.

Tanzu Kubernetes Grid v2.2 et vSphere with Tanzu dans vSphere 7

Attention :
Les versions de la CLI Tanzu compatibles avec TKG 2.x et disposant du superviseur vSphere with Tanzu dans vSphere 8 ne sont pas compatibles avec le cluster superviseur dans vSphere 7. Pour utiliser la CLI Tanzu avec un cluster superviseur vSphere with Tanzu sur vSphere 7, utilisez la version de la CLI Tanzu de TKG v1.6. Pour utiliser les versions de la CLI Tanzu compatibles avec TKG 2.x et un superviseur, effectuez une mise à niveau vers vSphere 8. Vous pouvez déployer un cluster de gestion TKG 2.x autonome sur vSphere 7 si aucun cluster superviseur vSphere with Tanzu n'est présent. Pour plus d'informations sur la compatibilité entre la CLI Tanzu et les produits VMware, reportez-vous à la documentation de la CLI Tanzu.

Nouveautés

Tanzu Kubernetes Grid v2.2.x inclut les nouvelles fonctionnalités suivantes :

Prise en charge de Kubernetes v1.25.7, 1.24.11 et 1.23.17. Reportez-vous à la section Versions de Kubernetes prises en charge dans Tanzu Kubernetes Grid v2.2 ci-dessous.
Pour les clusters de gestion autonomes et les clusters de charge de travail basés sur une classe, vous pouvez configurer l'approbation de plusieurs registres d'images privés à l'aide de variables ADDITIONAL_IMAGE_REGISTRY* d'un fichier de configuration du cluster ou de paramètres additionalImageRegistries d'une spécification d'objet Cluster. Reportez-vous à la section Registres approuvés pour un cluster basé sur une classe.
Supprime la réclamation de volume persistant jobservice.scandataExports de Harbor v2.7.1. Si vous avez appliqué précédemment Harbor Scandata Volume EmptyDir Overlay au module Harbor, reportez-vous à la section Mettre à jour un déploiement Harbor en cours d'exécution avant de mettre à jour le module Harbor vers la version v2.7.1.
À partir de TKG 2.2.0, VMware fournit un support au niveau de l'environnement d'exécution pour les modules compatibles VMware, tels que Harbor, Contour et Velero, lorsqu'ils sont déployés sur Tanzu Kubernetes Grid.
Le module CSI de vSphere prend en charge la configuration vsphereCSI.netpermissions.

Versions de Kubernetes et de TKG prises en charge

Avec TKG v2.2, la stratégie de prise en charge de VMware change pour les anciennes versions de correctifs de TKG et les versions de Tanzu Kubernetes (TKr, Tanzu Kubernetes Release) qui intègrent les versions de Kubernetes pour TKG. Les stratégies de prise en charge de TKG v2.1 et les versions mineures antérieures de TKG ne changent pas.

Les sections ci-dessous résument la prise en charge de toutes les versions actuellement compatibles de TKG et des TKr sous les stratégies de prise en charge qui s'appliquent à chacune d'elles.

Versions de Kubernetes prises en charge

Chaque version de Tanzu Kubernetes Grid ajoute la prise en charge de la version Kubernetes de son cluster de gestion, ainsi que des versions supplémentaires de Kubernetes distribuées en tant que versions de Tanzu Kubernetes (TKr), sauf indication contraire comme Problème connu.

Versions mineures : VMware prend en charge TKG v2.2 avec Kubernetes v1.25, v1.24 et v1.23 au moment de la publication et aussi longtemps que TKG v2.1 est également pris en charge. Une fois que TKG v2.1 atteint son étape de fin de support général, VMware ne prend plus en charge Kubernetes v1.23 et v1.24 avec TKG.

Versions de correctifs : Lorsque VMware publie une nouvelle version de correctif TKr pour une gamme mineure, il conserve la prise en charge des versions de correctifs plus anciennes pendant deux mois. Cela donne aux clients un délai de 2 mois pour effectuer une mise à niveau vers les nouvelles versions de correctifs de TKr. À partir de TKG v2.2, VMware ne prend plus en charge toutes les versions de correctifs TKr des gammes mineures précédentes de Kubernetes.

Versions de TKG et TKr prises en charge

Les versions de correctifs TKG actuellement prises en charge prennent en charge les versions de correctifs TKr, comme indiqué ci-dessous.

Version de Tanzu Kubernetes Grid	Version Kubernetes du cluster de gestion	Versions de Kubernetes (TKr) fournies
2.2.0	1.25.7	1.25.7, 1.24.11, 1.23.17
2.1.1	1.24.10	1.24.10, 1.23.16, 1.22.17
2.1.0	1.24.9	1.24.9, 1.23.15, 1.22.17
1.6.1	1.23.10	1.23.10, 1.22.13, 1.21.14
1.6.0	1.23.8	1.23.8, 1.22.11, 1.21.14

Versions de TKr prises en charge avec TKG v2.2.0

TKG v2.2.0 prend en charge les versions de correctifs TKr, comme indiqué dans le tableau ci-dessous, en fonction des dates de publication suivantes :

v2.2.0 : 18 mai 2023
v2.1.1 : 21 mars 2023

Version mineure de Kubernetes	Correctif Kubernetes	Publié avec TKG	Date de fin du support (s'il ne s'agit pas de la plus récente)
v1.25	v1.25.7	v2.2.0	Dernière prise en charge
v1.24	v1.24.11	v2.2.0	Dernière prise en charge
	v1.24.10	v2.1.1	11 juillet 2023
	v1.24.9	v2.1.0	21 mai 2023
v1.23	v1.23.17	v2.2.0	Dernière prise en charge
	v1.23.16	v2.1.1	11 juillet 2023
	v1.23.15	v2.1.0	21 mai 2023

Versions de Tanzu Kubernetes Grid prises en charge

VMware prend en charge les versions de TKG comme suit :

Versions mineures : VMware prend en charge TKG conformément à la Stratégie de cycle de vie N-2, qui s'applique aux deux versions mineures (la plus récente et la précédente) de TKG. Avec la version de TKG v2.2.0, TKG v1.5 n'est plus pris en charge. Pour plus d'informations, reportez-vous à la Matrice de cycle de vie des produits VMware.

Versions de correctifs : VMware ne prend pas en charge toutes les versions de correctifs TKG précédentes. Lorsque VMware publie une nouvelle version de correctif de TKG, il conserve la prise en charge de la version de correctif antérieure pendant deux mois. Cela donne aux clients un délai de 2 mois pour effectuer une mise à niveau vers les nouvelles versions de correctifs de TKG.

Par exemple, la prise en charge de TKG v2.2.0 se terminera deux mois après la disponibilité générale de TKG v2.2.1.

Clarification de la prise en charge du module de référentiel Tanzu Standard

VMware fournit la prise en charge suivante des modules facultatifs fournis dans le référentiel VMware Tanzu Standard :

VMware fournit la validation de l'installation et de la mise à niveau des modules inclus dans le référentiel VMware Tanzu Standard facultatif lorsqu'ils sont déployés sur Tanzu Kubernetes Grid. Cette validation est limitée à l'installation et à la mise à niveau du module, mais inclut toutes les mises à jour disponibles requises pour traiter les CVE. L'ensemble des correctifs de bogues, des améliorations des fonctionnalités et des correctifs de sécurité sont fournis dans les nouvelles versions du module lorsqu'ils sont disponibles dans le projet de module en amont.
VMware ne fournit pas de support au niveau de l'environnement d'exécution pour les composants fournis par le référentiel Tanzu Standard. Le débogage de la configuration, les problèmes liés aux performances ou le débogage et la correction du module lui-même ne sont pas fournis par VMware.

Pour plus d'informations sur le support VMware pour les modules Tanzu Standard, reportez-vous aux sections Nouveautés ci-dessus et Avis futurs des changements de comportement ci-dessous.

Snapshot de produit pour Tanzu Kubernetes Grid v2.2

Tanzu Kubernetes Grid v2.2 prend en charge les plates-formes d'infrastructure et les systèmes d'exploitation (SE) suivants, ainsi que la création et la gestion de clusters, la mise en réseau, le stockage, l'authentification, la sauvegarde et la migration, ainsi que les composants d'observabilité. Les versions des composants répertoriées entre parenthèses sont incluses dans Tanzu Kubernetes Grid v2.2.0. Pour plus d'informations, reportez-vous à la section Versions des composants.

	vSphere	AWS	Azure
Plate-forme d'infrastructure	vSphere 6.7U3 vSphere 7 vSphere 8 VMware Cloud on AWS** Azure VMware Solution Oracle Cloud VMware Solution (OCVS) Google Cloud VMware Engine (GCVE)	AWS natif	Azure natif
CLI, API et infrastructure de modules	Tanzu Framework v0.29.0
Création et gestion du cluster	API de cluster principal (v1.2.8), fournisseur d'API de cluster vSphere (v1.5.3)	API de cluster principal (v1.2.8), fournisseur d'API de cluster AWS (v2.0.2)	API de cluster principal (v1.2.8), fournisseur d'API de cluster Azure (v1.6.3)
Système d'exploitation du nœud Kubernetes distribué avec TKG	Photon OS 3, Ubuntu 20.04	Amazon Linux 2, Ubuntu 20.04	Ubuntu 18.04, Ubuntu 20.04
Créer votre propre image	Photon OS 3, Red Hat Enterprise Linux 7*** et 8, Ubuntu 18.04, Ubuntu 20.04, Windows 2019	Amazon Linux 2, Ubuntu 18.04, Ubuntu 20.04	Ubuntu 18.04, Ubuntu 20.04
Exécution de conteneur	Containerd (v1.6.18)
Mise en réseau de conteneur	Antrea (v1.9.0), Calico (v3.24.1)
Registre de conteneur	Harbor (v2.7.1)
Entrée	NSX Advanced Load Balancer Essentials et Contrôleur Avi **** (v21.1.5-v21.1.6, v22.1.2-v22.1.3), Contour (v1.23.5)	Contour (v1.23.5)	Contour (v1.23.5)
Stockage	Interface de stockage de conteneur vSphere (v2.7.1*) et stockage cloud natif vSphere	Pilote Amazon EBS CSI (v1.16.0) et fournisseurs de cloud dans l'arborescence	Pilote Azure Disk CSI (v1.27.0), pilote Azure File CSI (v1.26.1) et fournisseurs de cloud dans l'arborescence
Authentification	OIDC via Pinniped (v0.12.1), LDAP via Pinniped (v0.12.1) et Dex
Observabilité	Fluent Bit (v1.9.5), Prometheus (v2.37.0)***** et Grafana (v7.5.17)
Sauvegarde et migration	Velero (v1.9.7)

* Version de vsphere_csi_driver. Pour obtenir la liste complète des composants de l'interface de stockage de conteneur vSphere inclus dans Tanzu Kubernetes Grid v2.2, reportez-vous à la section Versions des composants.

** Pour obtenir la liste des versions de SDDC VMware Cloud on AWS compatibles avec cette version, reportez-vous à la Matrice d'interopérabilité des produits VMware.

*** Tanzu Kubernetes Grid v1.6 est la dernière version qui prend en charge la création d'images Red Hat Enterprise Linux 7.

**** Sur vSphere 8 pour utiliser NSX Advanced Load Balancer avec un cluster de gestion autonome TKG et ses clusters de charge de travail, vous devez NSX ALB 22.1.2 ou version ultérieure et TKG 2.1.1 ou version ultérieure.

***** Si vous mettez à niveau un cluster vers Kubernetes v1.25, vous devez mettre à niveau Prometheus vers la version 2.37.0+vmware.3-tkg.1. Les versions antérieures du module Prometheus, par exemple version 2.37.0+vmware.1-tkg.1, ne sont pas compatibles avec Kubernetes 1.25.

Pour obtenir la liste complète des versions de Kubernetes fournies avec Tanzu Kubernetes Grid v2.2, reportez-vous à la section Versions de Kubernetes prises en charge dans Tanzu Kubernetes Grid v2.2 ci-dessus.

Versions des composants

Les versions de Tanzu Kubernetes Grid v2.2.x incluent les versions de composants logiciels suivantes :

Composant	TKG v2.2
aad-pod-identity	v1.8.15+vmware.1^*
addons-manager	v2.2+vmware.1^*
ako-operator	v1.8.0_vmware.1^*
alertmanager	v0.25.0_vmware.1^*
antrea	v1.9.0_vmware.2-tkg.1-advanced^*
aws-ebs-csi-driver	v1.16.0_vmware.1-tkg.1^*
azuredisk-csi-driver	v1.27.0_vmware.2-tkg.1^*
azurefile-csi-driver	v1.26.1_vmware.2-tkg.1^*
calico	v3.24.1_vmware.1-tkg.2^*
capabilities-package	v0.29.0-dev-capabilities^*
carvel-secretgen-controller	v0.11.2+vmware.1
cloud-provider-azure	v1.1.26+vmware.1, v1.23.23+vmware.1, v1.24.10+vmware.1
cloud_provider_vsphere	v1.25.1+vmware.2^*
cluster-api-provider-azure	v1.6.3_vmware.2^*
cluster_api	v1.2.8+vmware.2^*
cluster_api_aws	v2.0.2+vmware.2^*
cluster_api_vsphere	v1.5.3+vmware.2^*
cni_plugins	v1.1.1+vmware.20^*
configmap-reload	v0.7.1+vmware.2
containerd	v1.6.18+vmware.1^*
contour	v1.23.5+vmware.1-tkg.1^*
coredns	v1.9.3_vmware.8^*
crash-diagnostics	v0.3.7+vmware.6
cri_tools	v1.24.2+vmware.8^*
csi_attacher	v3.5.0+vmware.1, v3.4.0+vmware.1, v3.3.0+vmware.1
csi_livenessprobe	v2.7.0+vmware.1, v2.6.0+vmware.1, v2.5.0+vmware.1, v2.4.0+vmware.1
csi_node_driver_registrar	v2.5.1+vmware.1, v2.5.0+vmware.1, v2.3.0+vmware.1
csi_provisioner	v3.2.1+vmware.1, v3.1.0+vmware.2, v3.0.0+vmware.1
dex	v2.35.3_vmware.3^*
envoy	v1.24.5_vmware.1^*
external-dns	v0.12.2+vmware.5^*
external-snapshotter	v6.0.1+vmware.1, v5.0.1+vmware.1
etcd	v3.5.6+vmware.9^*
fluent-bit	v1.9.5+vmware.1
gangway	v3.2.0+vmware.2
grafana	v7.5.17+vmware.2
guest-cluster-auth-service	v1.3.0^*
harbor	v2.7.1+vmware.1^*
image-builder	v0.1.13+vmware.3^*
image-builder-resource-bundle	v1.25.7+vmware.2-tkg.1^*
imgpkg	v0.31.1+vmware.1
jetstack_cert-manager	v1.10.2+vmware.1^*
k8s-sidecar	v1.15.6+vmware.5^, v1.12.1+vmware.6^
k14s_kapp	v0.53.2+vmware.1
k14s_ytt	v0.43.1+vmware.1
kapp-controller	v0.41.7_vmware.1-tkg.1^*
kbld	v0.35.1+vmware.1
kube-state-metrics	v2.7.0+vmware.2^*
kube-vip	v0.5.7+vmware.2^*
kube-vip-cloud-provider^*	v0.0.4+vmware.4^*
kube_rbac_proxy	v0.11.0+vmware.2
kubernetes	v1.25.7+vmware.2^*
kubernetes-csi_external-resizer	v1.4.0+vmware.1, v1.3.0+vmware.1
sigs_kind kubernetes	v1.25.7+vmware.2-tkg.2_v0.17.0^*
kubernetes_autoscaler	v1.25.0+vmware.1^*
load-balancer-and-ingress-service (AKO)	v1.9.3_vmware.1-tkg.1^*
metrics-server	v0.6.2+vmware.1
multus-cni	v3.8.0+vmware.3^*
pinniped	v0.12.1_vmware.3-tkg.4^*
pinniped-post-deploy	v0.12.1+vmware.2-tkg.3
prometheus	v2.37.0+vmware.3^*
prometheus_node_exporter	v1.4.0+vmware.3^*
pushgateway	v1.4.3+vmware.3^*
sonobuoy	v0.56.16+vmware.1^*
standalone-plugins-package	v0.29.0-dev-standalone-plugins^*
tanzu-framework	v0.29.0^*
tanzu-framework-addons	v0.29.0^*
tanzu-framework-management-packages	v0.29.0-tf^*
tkg-bom	v2.2.0^*
tkg-core-packages	v1.25.7+vmware.2-tkg.1^*
tkg-standard-packages	v2.2.0^*
tkg-storageclass-package	v0.29.0-tkg-storageclass^*
tkg_telemetry	v2.2.0+vmware.1^*
Velero	v1.9.7+vmware.1^*
velero-mgmt-cluster-plugin^*	v0.1.0+vmware.1
velero-plugin-for-aws	v1.5.5+vmware.1^*
velero-plugin-for-csi	v0.3.5+vmware.1^*
velero-plugin-for-microsoft-azure	v1.5.5+vmware.1^*
velero-plugin-for-vsphere	v1.4.3+vmware.1^*
vendir	v0.30.1+vmware.1
vsphere_csi_driver	v2.7.1+vmware.2^*
whereabouts	v0.5.4+vmware.2^*

^* Indique un nouveau composant ou un nouveau numéro de version depuis la version précédente. TKG v2.1.1 est antérieur à v2.2.0.

Pour obtenir la liste complète des versions de composants logiciels fournies avec TKG v2.2, utilisez imgpkg pour extraire le bundle de référentiels, puis répertorier son contenu. Pour TKG v2.2.0, par exemple :

imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.2.0 -o standard-2.2.0
cd standard-2.2.0/packages
tree

Les fichiers de nomenclature locaux tels que les fichiers suivants répertorient également les versions de module, mais peuvent ne pas être à jour :

~/.config/tanzu/tkg/bom/tkg-bom-v2.2.0.yaml
~/.config/tanzu/tkg/bom/tkr-bom-v1.25.7+vmware.1-tkg.1.yaml

Chemins de mise à niveau pris en charge

Dans le chemin de mise à niveau de TKG, la version v2.2 suit immédiatement la version v2.1.1.

Vous pouvez uniquement effectuer la mise à niveau vers Tanzu Kubernetes Grid v2.2.x à partir de la version v2.1.x. Si vous souhaitez effectuer une mise à niveau vers Tanzu Kubernetes Grid v2.2.x à partir d'une version antérieure à la version v2.1.x, vous devez d'abord effectuer une mise à niveau vers la version v2.1.x.

Lors de la mise à niveau des versions de Kubernetes sur des clusters de charge de travail, vous ne pouvez pas ignorer les versions mineures. Par exemple, vous ne pouvez pas mettre à niveau un cluster Tanzu Kubernetes directement de la version v1.23.x vers la version v1.25.x. Vous devez mettre à niveau un cluster v1.23.x vers la version v1.24.x avant de mettre à niveau le cluster vers la version v1.25.x.

Dates de publication

Les dates de publication de Tanzu Kubernetes Grid v2.2 sont les suivantes :

v2.2.0 : 9 mai 2023

Changements de comportement dans Tanzu Kubernetes Grid v2.2

Tanzu Kubernetes Grid v2.2 n'ajoute aucun nouveau comportement par rapport à la version v2.1.1, qui est la version précédente la plus récente.

Avis des futurs changements de comportement

Cette section fournit un avis préalable des changements de comportement qui prendront effet dans les versions ultérieures, après la version TKG v2.2.

Référentiel VMware Tanzu Standard

Important
Tanzu Kubernetes Grid v2.2.x est la version mineure finale de TKG dans laquelle le référentiel VMware Tanzu Standard est fourni dans le cadre de la version. TKG v2.2.x et les versions précédentes incluent un ensemble de modules facultatifs dans le référentiel Tanzu Standard, que vous pouvez déployer sur des clusters pour ajouter des fonctionnalités, telles que le transfert de journaux, le contrôle d'entrée, un registre de conteneur, etc. Dans une future version mineure de TKG v2.x, le référentiel Tanzu Standard ne sera pas automatiquement téléchargé lorsque vous installerez la CLI Tanzu et déploierez un cluster de gestion. Pour utiliser cet ensemble facultatif de modules, vous devez utiliser la CLI Tanzu pour les télécharger et les ajouter manuellement. La séparation des modules facultatifs des versions TKG permet à VMware de fournir des mises à jour de modules incrémentielles en dehors des versions de TKG et de mieux répondre aux CVE.

Remarques concernant l'obsolescence

Dans une future version de TKG, le composant Dex sera supprimé, car il n'est plus nécessaire pour que Pinniped fonctionne avec les fournisseurs LDAP. Avec cette modification, les variables de configuration de cluster suivantes pour l'authentification LDAP seront requises : LDAP_BIND_DN et LDAP_BIND_PASSWORD. Pour plus d'informations, reportez-vous à la section Fournisseurs d'identité - LDAP de la Référence de variable du fichier de configuration.

Documentation utilisateur

La section Déploiement et gestion de clusters de gestion autonomes TKG 2.2 inclut des rubriques spécifiques aux clusters de gestion autonomes qui ne sont pas pertinentes pour l'utilisation de TKG avec un superviseur vSphere with Tanzu.

Pour plus d'informations, reportez-vous à la section Rechercher les documents TKG appropriés pour votre déploiement sur la page Documentation de VMware Tanzu Kubernetes Grid.

Problèmes résolus

Les problèmes suivants documentés sous Problèmes connus dans les versions antérieures de Tanzu Kubernetes Grid sont résolus dans Tanzu Kubernetes Grid v2.2.0.

La création d'un fichier de configuration ClusterClass à partir d'un fichier de configuration hérité et --dry-run inclut une configuration d'Antrea vide

La création d'un fichier de configuration ClusterClass en utilisant tanzu cluster create --dry-run -f avec un fichier de configuration hérité qui inclut une entrée ANTREA_NODEPORTLOCAL entraîne une configuration d'Antrea générée automatiquement qui n'inclut aucune étiquette, ce qui entraîne l'échec du rapprochement d'Antrea.
Les modules ne sont pas conformes au profil PSA de ligne de base par défaut

Avec les contrôleurs PSA sur TKG, dans un état de version d'évaluation technique non pris en charge, certains modules TKG ne sont pas conformes au profil baseline par défaut.
Erreur de validation lors de l'exécution de tanzu cluster create

Par défaut, lorsque vous transmettez un fichier de configuration clé-valeur plat à l'option --file de tanzu cluster create, la commande convertit le fichier de configuration en fichier de spécification d'objet de style Kubernetes, puis se ferme. Ce comportement est contrôlé par la fonctionnalité auto-apply-generated-clusterclass-based-configuration, qui est définie par défaut sur false. Dans certains cas, lorsque vous transmettez le fichier de spécification d'objet de style Kubernetes généré par l'option --file à tanzu cluster create, la commande échoue avec une erreur semblable à la suivante :
```
Error: workload cluster configuration validation failed...
```
Cette erreur peut également se produire lorsque vous transmettez un fichier de spécification d'objet de style Kubernetes généré par l'option --dry-run à tanzu cluster create.
tanzu cluster create ne valide pas correctement les spécifications de cluster générées avec des versions de Kubernetes qui ne sont pas par défaut

Lors de la création d'un cluster de charge de travail basé sur une classe à partir d'un fichier de configuration à l'aide de l'un des processus en deux étapes décrits dans la section Créer un cluster basé sur une classe et que vous spécifiez une valeur --tkr dans la première étape pour baser le cluster sur une version autre que celle par défaut de Kubernetes, la seconde étape peut échouer avec des erreurs de validation.

Problèmes connus

Voici les problèmes connus dans Tanzu Kubernetes Grid v2.2.x. Tous les problèmes connus présents dans la version v2.2.0 qui ont été résolus dans une version de correctif v2.2.x ultérieure sont répertoriés sous la section Problèmes résolus pour cette version de correctif.

Vous trouverez des solutions supplémentaires aux problèmes fréquemment rencontrés dans les sections Dépannage des problèmes de cluster de gestion et Dépannage des problèmes de cluster de charge de travail ou dans les articles de la base de connaissances VMware.

Modules
Opérations de cluster
Mise en réseau
Gestion des identités et des accès
Stockage
CLI
vSphere
AWS
Image Builder
AVS

Modules

L'installation de Grafana échoue sur vSphere 6.7 avec NSX ALB v21.1.4 ou une version antérieure

Vous ne pouvez pas installer le module Grafana v7.5.17 sur des clusters de charge de travail TKG v2.2 sur vSphere v6.7U3 qui utilisent NSX ALB v21.1.4 ou une version antérieure comme service d'équilibrage de charge.

Solution : Si vos clusters de charge de travail utilisent Grafana et NSX ALB, mettez à niveau vSphere vers les versions v7.0 et ultérieures et NSX ALB vers les versions v21.1.5 et ultérieures avant la mise à niveau de TKG vers la version v2.2.
L'exportation des CVE Harbor peut échouer lorsque l'ID d'exécution dépasse plus de 1 000 000

Harbor v2.7.1, qui est la version en module pour TKG v2.2, présente un problème connu que les rapports CVE exportent avec l'erreur « Page 404 introuvable » (404 page not found) lorsque l'ID d'incrémentation automatique de la clé principale d'exécution atteint plus de 1 000 000.

Ce problème de Harbor est résolu dans les versions ultérieures de Harbor qui doivent être incluses dans les versions ultérieures de TKG.
Vulnérabilité Golang dans le composant Notary de Harbor

La vulnérabilité CVE-2021-33194 est présente dans Notary. Le composant Notary est déconseillé dans Harbor v2.6 et versions ultérieures, et sa suppression est prévue dans une version ultérieure, comme indiqué dans les Notes de mise à jour de Harbor v2.6.0. VMware recommande d'utiliser Sigstore Cosign plutôt que Notary pour la signature et la vérification des conteneurs.
L'ajout d'un référentiel standard échoue pour les clusters à nœud unique

L'exécution de tanzu package repository add pour ajouter le référentiel tanzu-standard à un cluster à nœud unique du type décrit dans la section Clusters à nœud unique sur vSphere (version d'évaluation technique) peut échouer.

Cela se produit, car les clusters à nœud unique démarrent avec cert-manager en tant que module complémentaire principal, qui entre en conflit avec le module cert-manager différent dans le référentiel tanzu-standard.

Solution : Avant d'ajouter le référentiel tanzu-standard, corrigez les annotations du module cert-manager, comme décrit dans la section Installer le gestionnaire de certificats.

Opérations de cluster

Impossible de créer des clusters de charge de travail basés sur des versions TKr non actuelles avec la CNI Antrea

Vous ne pouvez pas créer un cluster de charge de travail qui utilise la CNI Antrea et exécute des versions de Kubernetes livrées avec des versions antérieures de TKG, telles que Kubernetes v1.23.10, qui était la version de Kubernetes par défaut dans TKG v1.6.1, comme indiqué dans la section Versions de Kubernetes prises en charge dans Tanzu Kubernetes Grid v2.2.

Solution : Créez un cluster de charge de travail qui exécute Kubernetes 1.25.7, 1.24.11 ou 1.23.17. Le projet Kubernetes recommande d'exécuter des composants sur la version de correctif la plus récente de toute version mineure actuelle.
La mise à l'échelle automatique pour les clusters basés sur une classe nécessite des annotations manuelles

En raison d'un problème de propagation d'étiquette dans l'API de cluster, les paramètres AUTOSCALER_MIN_SIZE_* et AUTOSCALER_MAX_SIZE_* dans le fichier de configuration du cluster pour les clusters de charge de travail basés sur une classe ne sont pas définis dans les objets MachineDeployment du cluster.

Solution : après avoir créé un cluster de charge de travail basé sur une classe avec l'option de mise à l'échelle automatique de cluster activée, ajoutez manuellement le paramètre de nombre de machines minimal et maximal pour chaque zone de disponibilité, comme décrit dans la section Ajouter manuellement des annotations de taille minimale et maximale.
Les labels et d'autres propriétés de configuration de pool de nœuds ne peuvent pas être modifiés

Vous ne pouvez pas ajouter les propriétés labels, az, nodeMachineType ou les propriétés vSphere à un pool de nœuds existant ni les modifier, comme indiqué dans la section Propriétés de configuration.

Solution : créez un nouveau pool de nœuds dans le cluster avec les propriétés souhaitées, migrez les charges de travail vers le nouveau pool de nœuds et supprimez l'instance d'origine.
Vous ne pouvez pas mettre à l'échelle les nœuds du plan de contrôle du cluster de gestion vers un nombre pair

Si vous exécutez tanzu cluster scale sur un cluster de gestion et transmettez un nombre pair à l'option --controlplane-machine-count, TKG ne met pas à l'échelle les nœuds de plan de contrôle et la CLI ne génère pas d'erreur. Pour maintenir le quorum, le nombre de nœuds du plan de contrôle doit toujours être impair.

Solution : Ne mettez pas à l'échelle le nombre de nœuds du plan de contrôle sur un nombre pair.
Les noms des clusters basés sur une classe sont limités à 25 caractères avec NSX ALB comme équilibreur de charge ou contrôleur d'entrée.

Lorsque NSX Advanced Load Balancer (ALB) est utilisé comme service d'équilibrage de charge ou contrôleur d'entrée d'un cluster basé sur une classe avec un cluster de gestion autonome, ses noms d'application incluent à la fois le nom du cluster et load-balancer-and-ingress-service, le nom interne du module AKO. Lorsque le nom combiné dépasse la limite de 64 caractères pour les applications du contrôleur Avi, la commande tanzu cluster create peut échouer avec une erreur indiquant que l'espace de noms avi-system est introuvable.

Solution : Limitez la longueur du nom de cluster basé sur une classe à 25 caractères ou moins lorsque vous utilisez NSX ALB comme équilibreur de charge ou contrôleur d'entrée.

Mise en réseau

Remarque
à partir de la version 4.0, VMware NSX-T Data Center est renommé « VMware NSX ».

La mise en réseau IPv6 n'est pas prise en charge sur vSphere 8

TKG v2.2 ne prend pas en charge la mise en réseau IPv6 sur vSphere 8, bien qu'il prenne en charge la mise en réseau IPv6 à pile unique à l'aide de Kube-Vip sur vSphere 7, comme décrit dans la section Mise en réseau IPv6.

Solution : si vous avez besoin ou que vous utilisez actuellement TKG dans un environnement IPv6 sur vSphere, n'installez pas vSphere 8 ni ne procédez à la mise à niveau vers cette version.
Le mode d'entrée NodePortLocal de NSX ALB n'est pas pris en charge pour le cluster de gestion

Dans TKG v2.2, vous ne pouvez pas exécuter NSX Advanced Load Balancer (ALB) comme type de service avec le mode d'entrée NodePortLocal pour le trafic vers le cluster de gestion.

Ce problème n'affecte pas la prise en charge de l'entrée NodePortLocal aux clusters de charge de travail, comme décrit dans la section Entrée L7 en mode NodePortLocal.

Solution : configurez les clusters de gestion avec AVI_INGRESS_SERVICE_TYPE défini sur NodePort ou ClusterIP. La valeur par défaut est NodePort.
La création d'un cluster de gestion échoue ou les performances sont lentes avec les anciennes versions de NSX-T et les machines virtuelles Photon 3 ou Ubuntu avec le noyau Linux 5.8

Le déploiement d'un cluster de gestion avec l'infrastructure et la configuration suivantes peut échouer ou entraîner une restriction du trafic entre les espaces :
- vSphere avec l'une des versions suivantes de NSX-T :
  - NSX-T v3.1.3 avec chemin de données optimisé activé
  - NSX-T version 3.1.x antérieure à la version 3.1.3
  - NSX-T version 3.0.x antérieure au correctif à chaud v3.0.2
  - NSX-T v2.x. Cela inclut Azure VMware Solution (AVS) v2.0, qui utilise NSX-T v2.5
- Image de base : Photon 3 ou Ubuntu avec noyau Linux 5.8
Cette combinaison expose un problème de total de contrôle entre les anciennes versions de NSX-T et de la CNI Antrea.

TMC : si le cluster de gestion est enregistré dans Tanzu Mission Control (TMC), il n'existe aucune solution à ce problème. Sinon, reportez-vous aux solutions ci-dessous.

Solutions :
- Déployez des clusters de charge de travail configurés avec ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD défini sur "true". Ce paramètre désactive le déchargement du total de contrôle UDP d'Antrea, ce qui évite les problèmes connus avec certains pilotes réseau de sous-couche et de carte réseau physique.
- Mise à niveau vers le correctif à chaud NSX-T v3.0.2, v3.1.3 ou version ultérieure, sans l'option Chemin de données optimisé activée
- Utilisez une image de base Ubuntu avec le noyau Linux 5.9 ou version ultérieure.

Gestion des identités et des accès

La recréation d'un cluster de gestion autonome ne restaure pas l'authentification Pinniped

Après la recréation d'un cluster de gestion autonome comme décrit dans la section Sauvegarder et restaurer l'infrastructure du cluster de charge de travail et de gestion (version d'évaluation technique), les utilisateurs ne peuvent pas se connecter aux clusters de charge de travail via l'authentification Pinniped.

Solution : après avoir recréé le cluster de gestion, reconfigurez la gestion des identités comme décrit dans Activer et configurer la gestion des identités dans un déploiement existant.
Vulnérabilité Golang dans le composant Pinniped

La vulnérabilité CVE-2022-41723 est présente dans Pinniped v0.12.1. L'exploitation de cette vulnérabilité peut entraîner une attaque DDoS du service Pinniped. Pour réduire la probabilité d'exploitation à une valeur faible, vous pouvez utiliser le filtrage d'entrée pour autoriser uniquement le trafic provenant d'adresses IP connues, telles qu'un CIDR VPN d'entreprise. Cette vulnérabilité sera résolue dans une version ultérieure de Tanzu Kubernetes Grid.
La génération et l'utilisation de kubeconfig pour le cluster de charge de travail déployé par le superviseur provoquent l'erreur « indicateur inconnu » (unknown flag)

Dans Tanzu CLI v0.25.0 et versions antérieures, le plug-in cluster génère les fichiers kubeconfig qui peuvent contenir l'argument --concierge-is-cluster-scoped. Le plug-in pinniped-auth de la CLI Tanzu v0.29.0 ne reconnaît pas cet argument. Cette régression temporaire a été corrigée dans les versions suivantes.

Étant donné que vSphere 8.0 intègre le plug-in de cluster v0.25.0, la connexion à un cluster déployé par le superviseur à partir de la CLI v0.29.0, la version dans TKG v2.2, peut générer cette erreur :
```
Error: unknown flag: --concierge-is-cluster-scoped
Unable to connect to the server: getting credentials: exec: executable tanzu failed with exit code 1
```
Solution : Dans votre fichier kubeconfig, supprimez la ligne sous args qui définit --concierge-is-cluster-scoped.

Stockage

Le cluster de charge de travail ne peut pas distribuer le stockage sur plusieurs banques de données

Vous ne pouvez pas activer un cluster de charge de travail pour distribuer le stockage entre plusieurs banques de données, comme décrit dans la section Déployer un cluster qui utilise un cluster de banques de données. Si vous balisez plusieurs banques de données dans un cluster de banques de données comme base de la stratégie de stockage d'un cluster de charge de travail, ce cluster n'utilise qu'une seule des banques de données.

Solution : Aucune

CLI Tanzu

Les caractères non alphanumériques ne peuvent pas être utilisés dans les mots de passe de proxy HTTP/HTTPS

Lors du déploiement de clusters de gestion avec la CLI, les caractères non alphanumériques # ` ^ | / ? % ^ { [ ] } \ " < > ne peuvent pas être utilisés dans les mots de passe. En outre, vous ne pouvez pas utiliser des caractères non alphanumériques dans les mots de passe de proxy HTTP/HTTPS lors du déploiement d'un cluster de gestion avec l'interface utilisateur.

Solution : vous pouvez utiliser des caractères non alphanumériques autres que # ` ^ | / ? % ^ { [ ] } \ " < > dans les mots de passe lors du déploiement du cluster de gestion avec la CLI.
La CLI Tanzu ne fonctionne pas sur les machines macOS avec des processeurs ARM

La CLI Tanzu v0.11.6 ne fonctionne pas sur les machines macOS dotées de puces ARM (Apple M1), comme identifié sous Outil de recherche > À propos de ce Mac > Présentation.

Solution : utilisez une machine de démarrage avec un système d'exploitation Linux ou Windows, ou une machine macOS avec un processeur Intel.
La CLI Tanzu répertorie tanzu management-cluster osimage

Le groupe de commandes management-cluster répertorie tanzu management-cluster osimage. Cette fonctionnalité est actuellement en développement, et réservée pour une utilisation ultérieure.

Solution : n'utilisez pas tanzu management-cluster osimage.
L'option --default-values-file-output de tanzu package available get génère un fichier de modèle de configuration incomplet pour le module Harbor

L'exécution de tanzu package available get harbor.tanzu.vmware.com/PACKAGE-VERSION --default-values-file-output FILE-PATH crée un fichier de modèle de configuration incomplet pour le module Harbor. Pour obtenir un fichier complet, utilisez la commande imgpkg pull, comme décrit dans la section Installer Harbor pour le registre de service.

vSphere

Les pools de nœuds créés avec des nœuds small peuvent se bloquer à l'état Provisioning

Les pools de nœuds créés avec le nœud SIZE configurés comme small peuvent se bloquer à l'état Provisioning et ne jamais passer à l'état Running.

Solution : configurez le pool de nœuds avec des nœuds de taille au moins medium.

AWS

Un problème de balisage des ressources CAPA entraîne un échec du rapprochement lors du déploiement et de la mise à niveau du cluster de gestion AWS.

En raison d'un problème de balisage des ressources dans le fournisseur d'API de cluster AWS (CAPA, Cluster API Provider AWS) en amont, les déploiements hors ligne ne peuvent pas accéder à l'API ResourceTagging, ce qui entraîne des échecs de rapprochement lors de la création ou de la mise à niveau du cluster de gestion.

Solution : dans un environnement AWS hors ligne, définissez EXP_EXTERNAL_RESOURCE_GC=false dans votre environnement local ou dans le fichier de configuration du cluster de gestion avant d'exécuter tanzu mc create ou tanzu mc upgrade.
Les pools de nœuds de cluster de charge de travail sur AWS doivent se trouver dans la même zone de disponibilité que le cluster de gestion autonome.

Lors de la création d'un pool de nœuds configuré avec une variable az différente de l'emplacement du cluster de gestion, le nouveau pool de nœuds peut rester bloqué avec l'état ScalingUp, tel que répertorié par tanzu cluster node-pool list et ne jamais atteindre l'état Ready.

Solution : créez uniquement des pools de nœuds dans la même zone de disponibilité que le cluster de gestion autonome.
La suppression du cluster sur AWS échoue si le cluster utilise des ressources de mise en réseau non déployées avec Tanzu Kubernetes Grid.

Les commandes tanzu cluster delete et tanzu management-cluster delete peuvent se bloquer avec des clusters qui utilisent des ressources de mise en réseau créées par AWS Cloud Controller Manager indépendamment du processus de déploiement Tanzu Kubernetes Grid. Ces ressources peuvent inclure des équilibrages de charge et d'autres services de mise en réseau, comme indiqué dans la section The Service Controller de la documentation du fournisseur de cloud AWS Kubernetes.

Pour plus d'informations, reportez-vous à la section Problème de l'API de cluster Drain workload clusters of service Type=Loadbalancer on teardown.

Solution : utilisez kubectl delete pour supprimer des services de type LoadBalancer du cluster. Si cela échoue, utilisez la console AWS pour supprimer manuellement tous les objets LoadBalancer et SecurityGroup créés pour ce service par Cloud Controller Manager.

Attention :
ne supprimez pas les équilibrages de charge ou les groupes de sécurité gérés par Tanzu, qui ont les balises key: sigs.k8s.io/cluster-api-provider-aws/cluster/CLUSTER-NAME, value: owned.

Azure

Échec de la suppression du cluster lorsque le volume de stockage utilise un compte avec un point de terminaison privé

Avec un cluster de charge de travail Azure dans un groupe de ressources non géré, lorsque le pilote CSI Azure crée un volume persistant qui utilise un compte de stockage avec un point de terminaison privé, il crée une ressource privateEndpoint et une ressource vNet qui ne sont pas supprimées lorsque le volume persistant est supprimé. Par conséquent, la suppression du cluster échoue avec une erreur telle que subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use.

Solution : avant de supprimer le cluster Azure, supprimez manuellement l'interface réseau du point de terminaison privé du compte de stockage :
1. Dans un navigateur, connectez-vous à Azure Resource Explorer.
2. Cliquez sur Abonnements (Subscriptions) à gauche et développez votre abonnement.
3. Sous votre abonnement, développez resourceGroups à gauche, puis développez le groupe de ressources de votre déploiement TKG.
4. Sous le groupe de ressources, développez fournisseurs (providers) > Microsoft.Network > networkinterfaces.
5. Sous networkinterfaces, sélectionnez la ressource de carte réseau dont la suppression échoue.
6. Cliquez sur le bouton Lecture/Écriture (Read/Write) en haut, puis sur l'onglet Actions(POST, DELETE) juste en dessous.
7. Cliquez sur Supprimer.
8. Une fois la carte réseau supprimée, supprimez le cluster Azure.

Windows

Travailleurs Windows non pris en charge dans les environnements à accès restreint à Internet

VMware ne prend pas en charge les clusters de charge de travail TKG avec des nœuds worker Windows dans des environnements en proxy ou isolés.

Solution : Contactez votre représentant VMware. Certains utilisateurs TKG ont créé des images personnalisées Windows et exécutent des clusters de charge de travail avec des travailleurs Windows dans des environnements hors ligne, par exemple, comme décrit dans ce référentiel non officiel.

Image-Builder

Échecs de test goss ignorés lors du processus de création d'image

Lorsque vous exécutez Kubernetes Image Builder pour créer une image de machine personnalisée Linux personnalisée, les tests goss python-netifaces, python-requests et ebtables échouent. La sortie de la commande signale les échecs. Les erreurs peuvent être ignorées ; elles n'empêchent pas la création d'une image réussie.

AVS

La suppression du volume vSphere CSI peut échouer sur AVS

Sur la Azure vSphere Solution (AVS), la suppression des volumes persistants vSphere CSI peut échouer. La suppression d'un volume persistant nécessite l'autorisation cns.searchable. Le compte d'administrateur par défaut pour AVS, [email protected], n'est pas créé avec cette autorisation. Pour plus d'informations, reportez-vous à la section Rôles et privilèges dans vSphere.

Solution : pour supprimer un volume persistant vSphere CSI sur AVS, contactez le support Azure.