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

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

TKG v2.1 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.1 est la première version de TKG qui prend en charge la création et la gestion de clusters de charge de travail basés sur une classe avec un cluster de gestion autonome pouvant s'exécuter sur plusieurs infrastructures, y compris vSphere, AWS et Azure.

Tanzu Kubernetes Grid v2.x 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.1 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 2.1.x inclut les nouvelles fonctionnalités ci-après.

Tanzu Kubernetes Grid 2.1.1

Nouvelles fonctionnalités de Tanzu Kubernetes Grid 2.1.1 :

• Prend en charge l'utilisation de NSX Advanced Load Balancer 22.1.2 ou version ultérieure sur vSphere 8 avec un cluster de gestion autonome TKG et ses clusters de charge de travail.
• Vous pouvez installer la version FIPS de TKG v2.1.1. Pour plus d'informations, reportez-vous à la section Versions compatibles FIPS.
• Variables de configuration :
  • Contrôles de santé de la machine : MHC_MAX_UNHEALTHY_CONTROL_PLANE et MHC_MAX_UNHEALTHY_WORKER_NODE. Pour plus d'informations, reportez-vous à la section Contrôles de santé de la machine dans Référence de variable de fichier de configuration.
  • Prise en charge du serveur tdnf avec certificat personnalisé : CUSTOM_TDNF_REPOSITORY_CERTIFICATE (version d'évaluation technique). Pour plus d'informations, reportez-vous à la section Configuration du nœud dans Référence de variable de fichier de configuration.
  • Prise en charge des paramètres de proxy au niveau du nœud : TKG_NODE_SYSTEM_WIDE_PROXY (version d'évaluation technique). Pour plus d'informations, reportez-vous à la section Configuration du proxy dans Référence de variable de fichier de configuration.

Tanzu Kubernetes Grid 2.1.0

Nouvelles fonctionnalités de Tanzu Kubernetes Grid 2.1.0 :

• Prise en charge de TKG 2.x : sur vSphere, AWS ou Azure avec un cluster de gestion autonome, configurez et créez des clusters basés sur une classe comme décrit dans Types de clusters de charge de travail.
• Vous pouvez installer la version FIPS de TKG v2.1.0. Pour plus d'informations, reportez-vous à la section Versions compatibles FIPS.
• CLI Tanzu :
  • Le plug-in package utilise des commandes de style kctrl par défaut. Reportez-vous à la section Module Tanzu dans Référence de commande de la CLI Tanzu.
  • Les commandes du plug-in isolated-cluster, download-bundle et upload-bundle, récupèrent et transfèrent toutes les images de conteneur requises par TKG, comme décrit dans Préparer un environnement à accès restreint à Internet.
  • Les options -A et --all-namespaces pour tanzu cluster list incluent des clusters dans tous les espaces de noms gérés par le cluster de gestion et pour lesquels l'utilisateur dispose d'autorisations d'affichage ou supérieures, pas uniquement l'espace de noms par défaut.
  • Le groupe de commandes context permet aux utilisateurs de définir et de gérer les contextes de la CLI Tanzu, qui incluent le serveur à cibler et le fichier kubeconfig à appliquer. Reportez-vous à la section Contexte Tanzu dans la Référence de commande de la CLI Tanzu.
    • Les versions ultérieures déconseilleront la commande tanzu login en faveur des commandes tanzu context.
  • La catégorie Target des plug-ins modifie le comportement de la CLI et ajoute des fonctionnalités réservées pour une utilisation ultérieure, comme décrit dans la section Modifications de comportement dans Tanzu Kubernetes Grid v2.1, ci-dessous.
  • La fonctionnalité auto-apply-generated-clusterclass-based-configuration applique automatiquement la configuration de cluster basée sur une classe générée par la CLI Tanzu lorsque vous transmettez un fichier de configuration de cluster hérité à tanzu cluster create. La fonctionnalité est définie sur false par défaut. Reportez-vous à la section Fonctionnalités dans Architecture et configuration de la CLI Tanzu.
  • La fonctionnalité allow-legacy-cluster vous permet de créer des clusters basés sur un plan. La fonctionnalité est définie sur false par défaut. Reportez-vous à la section Fonctionnalités dans Architecture et configuration de la CLI Tanzu.
  • Les commandes tanzu mc credentials update et tanzu cluster credentials update ajoutent des options pour Azure. Cela inclut --azure-client-id, --azure-client-secret et --azure-tenant-id.
• Les variables de configuration de cluster suivantes sont prises en charge pour les clusters basés sur une classe et les clusters de gestion autonomes, comme décrit dans Référence de variable de fichier de configuration :
  • Configuration de nœuds : CONTROL_PLANE_NODE_LABELS, CONTROL_PLANE_NODE_NAMESERVERS, CONTROL_PLANE_NODE_SEARCH_DOMAINS, WORKER_NODE_NAMESERVERS, WORKER_NODE_SEARCH_DOMAINS
  • Propriété ExtraArgs : APISERVER_EXTRA_ARGS, CONTROLPLANE_KUBELET_EXTRA_ARGS, ETCD_EXTRA_ARGS, KUBE_CONTROLLER_MANAGER_EXTRA_ARGS, KUBE_SCHEDULER_EXTRA_ARGS, WORKER_KUBELET_EXTRA_ARGS
  • Limitation et synchronisation du débit : NTP_SERVERS, APISERVER_EVENT_RATE_LIMIT_CONF_BASE64
• Les clusters peuvent renouveler automatiquement les certificats de machine virtuelle du nœud de plan de contrôle. Reportez-vous à la section Renouvellement automatique du certificat de nœud de plan de contrôle.
• (vSphere) Vous pouvez déployer des clusters de charge de travail avec plusieurs systèmes d'exploitation qui exécutent des nœuds worker basés sur Windows et sur Linux, comme décrit dans la section Déployer un cluster de charge de travail avec plusieurs systèmes d'exploitation. Dans cette version, les clusters de charge de travail Windows sont remplacés par les clusters de charge de travail à systèmes d'exploitation multiples. Pour plus d'informations, reportez-vous à la section Changements de comportement dans Tanzu Kubernetes Grid v2.1.
  • Vous pouvez déployer des clusters de charge de travail à systèmes d'exploitation multiples avec des travailleurs dans plusieurs zones de disponibilité, comme décrit dans la section Déployer des clusters de charge de travail sur plusieurs zones de disponibilité (version d'évaluation technique de vSphere).
• (vSphere) Les clusters de charge de travail basés sur une classe peuvent être configurés avec la gestion des adresses IP (IPAM) dans le cluster sur un pool d'adresses IP alloué, éliminant ainsi la nécessité de configurer des réservations DHCP lorsque le nombre de nœuds ou les instances changent.
• (vSphere) Les étiquettes d'objets Machine de nœuds de cluster identifient l'adresse de leur hôte ESXi à prendre en charge à l'aide de nodeSelector pour exécuter des charges de travail spécifiques sur du matériel spécialisé.
• (vSphere) Les images OVA Ubuntu utilisent le mode UEFI (Unified Extensible Firmware Interface) pour le démarrage, remplaçant ainsi le mode de microprogramme BIOS traditionnel. Le mode UEFI active les charges de travail GPU (Graphic Processing Unit) et améliore la sécurité des nœuds. Pour plus d'informations sur UEFI sur Ubuntu, reportez-vous à la section UEFI dans la documentation d'Ubuntu.
• Vous pouvez utiliser Kube-VIP en tant que service LoadBalancer L4 pour les charges de travail. Pour plus d'informations, reportez-vous à la section Équilibreur de charge Kube-VIP (version d'évaluation technique).
• Vous pouvez déployer des clusters de charge de travail à nœud unique qui exécutent des charges de travail hébergées et une infrastructure de plan de contrôle sur un hôte ESXi unique, pour les applications en périphérie, comme décrit dans la section Clusters à nœud unique sur vSphere (version d'évaluation technique).
  • Vous pouvez déployer des clusters minimaux à nœud unique basés sur des versions tiny de Tanzu Kubernetes (TKr) qui réduisent l'encombrement.
• Vous pouvez sauvegarder et déployer l'infrastructure de cluster comme décrit dans la section Sauvegarder et restaurer la gestion et l'infrastructure du cluster de charge de travail (version d'évaluation technique).
• Prend en charge les contrôleurs d'admission de sécurité (PSA) de l'espace pour remplacer les stratégies de sécurité de l'espace comme décrit dans les espaces de noms, comme expliqué dans la section Contrôleur d'admission de sécurité d'espace (version d'évaluation technique).

Versions de Kubernetes prises en charge dans Tanzu Kubernetes Grid v2.1

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 Tanzu Kubernetes (TKrs).

Toutes les versions de Tanzu Kubernetes Grid prennent en charge l'ensemble des versions TKr des deux lignes mineures précédentes de Kubernetes, sauf lorsqu'elles sont signalées comme Problème connu. Par exemple, TKG v2.1.x prend en charge les versions v1.23.x et v1.22.x de Kubernetes répertoriées ci-dessous, mais pas les versions v1.21.x ou antérieures.

Version de Tanzu Kubernetes Grid	Version Kubernetes du cluster de gestion	Versions de Kubernetes (TKr) fournies
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
1.5.4	1.22.9	1.22.9, 1.21.11, 1.20.15
1.5.3	1.22.8	1.22.8, 1.21.11, 1.20.15
1.5.2, 1.5.1, 1.5.0	1.22.5	1.22.5, 1.21.8, 1.20.14

Snapshot de produit pour Tanzu Kubernetes Grid v2.1

Tanzu Kubernetes Grid v2.1 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 2.1.1. 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 0.28.1
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.6)
Mise en réseau de conteneur	Antrea (v1.7.2), Calico (v3.24.1)
Registre de conteneur	Harbor (v2.6.3)
Entrée	NSX Advanced Load Balancer Essentials et le contrôleur Avi **** (v21.1.3- v21.1.6, v22.1.1, v22.1.2), Contour (v1.22.3)	Contour (v1.22.3)	Contour (v1.22.3)
Stockage	Interface de stockage de conteneur vSphere (v2.5.2*) et stockage cloud natif vSphere	Pilote Amazon EBS CSI (v1.8.0) et fournisseurs de cloud dans l'arborescence	Pilote Azure Disk CSI (v1.19.0), pilote Azure File CSI (v1.21.0) 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.5)

* Version de vsphere_csi_driver. Pour obtenir la liste complète des composants de vSphere Container Storage Interface inclus dans Tanzu Kubernetes Grid v1.6, 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.

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

Versions des composants

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

Composant	TKG 2.1.1	TKG 2.1.0
aad-pod-identity	v1.8.13+vmware.2*	v1.8.13+vmware.1*
gestionnaire de modules complémentaires	v2.1+vmware.1-tkg.3	v2.1+vmware.1-tkg.3
ako-operator	v1.7.0+vmware.3	v1.7.0+vmware.3*
alertmanager	v0.24.0+vmware.2*	v0.24.0+vmware.1
antrea	v1.7.2+vmware.1-advanced	v1.7.2+vmware.1-advanced*
aws-ebs-csi-driver	v1.8.0+vmware.2	v1.8.0+vmware.2*
azuredisk-csi-driver	v1.19.0+vmware.1	v1.19.0+vmware.1*
azurefile-csi-driver*	v1.21.0+vmware.1	v1.21.0+vmware.1
calico_all	v3.24.1+vmware.1	v3.24.1+vmware.1*
capabilities-package	v0.28.1-dev-capabilities*	v0.28.0-dev-capabilities*
carvel-secretgen-controller	v0.11.2+vmware.1	v0.11.2+vmware.1*
cloud-provider-azure	v1.1.26+vmware.1, v1.23.23+vmware.1, v1.24.10+vmware.1	v1.1.26+vmware.1*, v1.23.23+vmware.1*, v1.24.9+vmware.1*
cloud_provider_vsphere	v1.24.3+vmware.1	v1.24.3+vmware.1*
cluster-api-provider-azure	v1.6.3_vmware.1*	v1.6.1_vmware.1*
cluster_api	v1.2.8+vmware.1	v1.2.8+vmware.1*
cluster_api_aws	v2.0.2+vmware.1	v2.0.2+vmware.1*
cluster_api_vsphere	v1.5.3+vmware.1l*	v1.5.1+vmware.1l*
cni_plugins	v1.1.1+vmware.18*	v1.1.1+vmware.16*
configmap-reload	v0.7.1+vmware.2*	v0.7.1+vmware.1
containerd	v1.6.6+vmware.3*	v1.6.6+vmware.1*
contour	v1.22.3+vmware.1	v1.22.3+vmware.1*
coredns	v1.8.6+vmware.17*	v1.8.6+vmware.15*
crash-diagnostics	v0.3.7+vmware.6	v0.3.7+vmware.6*
cri_tools	v1.23.0+vmware.8*	v1.23.0+vmware.7*
csi_attacher	v3.5.0+vmware.1, v3.4.0+vmware.1, v3.3.0+vmware.1	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	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	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	v3.2.1+vmware.1*, v3.1.0+vmware.2, v3.0.0+vmware.1
dex	v2.35.3+vmware.2	v2.35.3+vmware.2*
envoy	v1.23.3+vmware.2	v1.23.3+vmware.2*
external-dns	v0.12.2+vmware.4	v0.12.2+vmware.4*
external-snapshotter	v6.0.1+vmware.1, v5.0.1+vmware.1	v6.0.1+vmware.1, v5.0.1+vmware.1
etcd	v3.5.6+vmware.6*	v3.5.6+vmware.3*
fluent-bit	v1.9.5+vmware.1	v1.9.5+vmware.1*
gangway	v3.2.0+vmware.2	v3.2.0+vmware.2
grafana	v7.5.17+vmware.1*	v7.5.16+vmware.1
guest-cluster-auth-service	v1.2.0*	v1.1.0*
harbor	v2.6.3+vmware.1	v2.6.3+vmware.1*
image-builder	v0.1.13+vmware.2	v0.1.13+vmware.2*
image-builder-resource-bundle	v1.24.10+vmware.1-tkg.1*	v1.24.9+vmware.1-tkg.1*
imgpkg	v0.31.1+vmware.1	v0.31.1+vmware.1*
jetstack_cert-manager	v1.10.1+vmware.1	v1.10.1+vmware.1*
k8s-sidecar	v1.15.6+vmware.3*, v1.12.1+vmware.5*	v1.15.6+vmware.2, v1.12.1+vmware.3*
k14s_kapp	v0.53.2+vmware.1	v0.53.2+vmware.1*
k14s_ytt	v0.43.1+vmware.1	v0.43.1+vmware.1*
contrôleur kapp	v0.41.5+vmware.1, v0.38.5+vmware.2	v0.41.5+vmware.1*, v0.38.5+vmware.2*
kbld	v0.35.1+vmware.1	v0.35.1+vmware.1*
kube-state-metrics	v2.6.0+vmware.2*	v2.6.0+vmware.1*
kube-vip	v0.5.7+vmware.1	v0.5.7+vmware.1*
kube-vip-cloud-provider*	v0.0.4+vmware.2	v0.0.4+vmware.2
kube_rbac_proxy	v0.11.0+vmware.2	v0.11.0+vmware.2
kubernetes	v1.24.10+vmware.1*	v1.24.9+vmware.1*
kubernetes-csi_external-resizer	v1.4.0+vmware.1, v1.3.0+vmware.1	v1.4.0+vmware.1*, v1.3.0+vmware.1
sigs_kind kubernetes	v1.24.10+vmware.1-tkg.1_v0.17.0*	v1.24.9+vmware.1-tkg.1_v0.17.0*
kubernetes_autoscaler	v1.24.0+vmware.1	v1.24.0+vmware.1*
load-balancer-and-ingress-service (AKO)	v1.8.2+vmware.1	v1.8.2+vmware.1*
metrics-server	v0.6.2+vmware.1	v0.6.2+vmware.1*
multus-cni	v3.8.0+vmware.2	v3.8.0+vmware.2*
pinniped	v0.12.1+vmware.1-tkg.1	v0.12.1+vmware.1-tkg.1
pinniped-post-deploy	v0.12.1+vmware.2-tkg.3	v0.12.1+vmware.2-tkg.3*
prometheus	v2.37.0+vmware.2*	v2.37.0+vmware.1*
prometheus_node_exporter	v1.4.0+vmware.2*	v1.4.0+vmware.1*
pushgateway	v1.4.3+vmware.2*	v1.4.3+vmware.1
sonobuoy	v0.56.13+vmware.1	v0.56.13+vmware.1*
standalone-plugins-package	v0.28.1-dev-standalone-plugins*	v0.28.1-dev-standalone-plugins*
tanzu-framework	v0.28.1*	v0.28.0*
tanzu-framework-addons	v0.28.1*	v0.28.0*
tanzu-framework-management-packages	v0.28.1-tf*	v0.28.0-tf*
tkg-bom	v2.1.1*	v2.1.0*
tkg-core-packages	v1.24.10+vmware.1-tkg.1*	v1.24.9+vmware.1-tkg.1*
tkg-standard-packages	v2.1.1*	v2.1.0*
tkg-storageclass-package	v0.28.1-tkg-storageclass*	v0.28.0-tkg-storageclass*
tkg_telemetry	v2.1.1+vmware.1*	v2.1.0+vmware.1*
Velero	v1.9.5+vmware.1	v1.9.5+vmware.1*
velero-mgmt-cluster-plugin*	v0.1.0+vmware.1	v0.1.0+vmware.1
velero-plugin-for-aws	v1.5.3+vmware.1	v1.5.3+vmware.1*
velero-plugin-for-csi	v0.3.3+vmware.1	v0.3.3+vmware.1*
velero-plugin-for-microsoft-azure	v1.5.3+vmware.1	v1.5.3+vmware.1*
velero-plugin-for-vsphere	v1.4.2+vmware.1	v1.4.2+vmware.1*
vendir	v0.30.1+vmware.1	v0.30.1+vmware.1*
vsphere_csi_driver	v2.6.2+vmware.2	v2.6.2+vmware.2*
whereabouts	v0.5.4+vmware.1	v0.5.4+vmware.1*

^* Indique un nouveau composant ou un nouveau numéro de version depuis la version précédente. TKG 2.1.0 est antérieur à 2.1.1 et 1.6.1 est antérieur à 2.1.0.

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

imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.1.1 -o standard-2.1.1
cd standard-2.1.1/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.1.yaml
• ~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+vmware.1-tkg.1.yaml

Chemins de mise à niveau pris en charge

Dans le chemin de mise à niveau de TKG, la version 2.1 suit immédiatement la version 1.6. TKG v2.0 n'est pas une version téléchargeable de TKG : il s'agit de la version de TKG intégrée au superviseur vSphere with Tanzu dans vSphere 8.

Vous pouvez uniquement effectuer la mise à niveau vers Tanzu Kubernetes Grid v2.1.x à partir de la version 1.6.x. Si vous souhaitez effectuer une mise à niveau vers Tanzu Kubernetes Grid v2.1.x à partir d'une version antérieure à la version 1.6.x, vous devez d'abord effectuer la mise à niveau vers la version 1.6.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 1.21.x vers la version 1.23.x. Vous devez mettre à niveau un cluster v1.21.x vers la version 1.22.x avant de mettre à niveau le cluster vers la version 1.23.x.

Dates de publication

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

• v2.1.0 : 29 janvier 2023
• v2.1.1 : 21 mars 2023

Changements de comportement dans Tanzu Kubernetes Grid v2.1

Tanzu Kubernetes Grid v2.1 introduit les nouveaux comportements suivants par rapport à la version 1.6.1, qui est la dernière version précédente.

• L'option --include-management-cluster pour tanzu cluster list nécessite l'option -A pour répertorier un cluster de gestion autonome. Avec l'option -A, la commande répertorie les clusters dans tous les espaces de noms.

• Le plug-in package de la CLI Tanzu utilise des commandes de style kctrl par défaut. Reportez-vous à la section Module tanzu avec kctrl dans la Référence de commande de la CLI Tanzu.

  • Dans TKG v1.6, le plug-in package s'exécutait par défaut avec le mode kctrl désactivé, appelé mode hérité ci-dessous.

  • Les commandes du mode kctrl et du mode hérité diffèrent comme suit :

    • Pour créer un fichier de valeurs par défaut pour la configuration du module, les commandes kctrl-style tanzu package available get utilisent l'indicateur --generate-default-values-file au lieu de --default-values-file-output.
    • L'indicateur --create-namespace est supprimé. Si vous utilisez -n ou --namespace pour spécifier un espace de noms cible, celui-ci doit déjà exister.
    • L'indicateur --create est supprimé pour package repository update.
    • L'indicateur --package-name est renommé --package pour package installed create et package install.
    • L'indicateur --install est supprimé pour package installed update.
    • L'indicateur global --verbose est supprimé.
    • Les indicateurs --poll-interval et -poll-timeout sont renommés --wait-interval et --wait-timeout.
    • Dans la sortie package available get, un tableau supplémentaire répertorie les versions disponibles pour le module.
    • Dans la sortie package available list, la colonne LATEST-VERSION est supprimée et SHORT-DESCRIPTION ne s'affiche pas par défaut ; utilisez l'indicateur --wide pour l'afficher.
    • Dans la sortie package repository list, les colonnes REPOSITORY et TAG sont remplacées par une colonne SOURCE qui se compose du type de source (par exemple, imgpkg), l'URL du référentiel et la balise.

  • Pour plus d'informations, reportez-vous aux rubriques sous Modules gérés via CLI dans la documentation de TKG 1.6 pour connaître le fonctionnement du plug-in tanzu package avec le mode kctrl désactivé.

• Le référentiel de modules tanzu-standard n'est pas préinstallé sur les clusters basés sur une classe. Pour ajouter le référentiel de modules, reportez-vous à la section Ajouter un référentiel de modules.
• Le processus de création des clusters de gestion de la CLI Tanzu ne prend plus en charge la création d'un VPC. L'interface du programme d'installation n'inclut pas d'option permettant de créer un VPC et les fichiers de configuration de cluster ne prennent plus en charge les options AWS_* pour créer un VPC pour un CIDR spécifié. Si vous souhaitez utiliser un nouveau VPC, avant de déployer un cluster de gestion autonome sur AWS, vous devez créer un VPC pour votre déploiement TKG à l'aide de la console AWS.

• La CLI Tanzu utilise une nouvelle abstraction Cibles (Targets) pour associer différents groupes de commandes au type de serveur auquel s'appliquent les commandes. La commande tanzu context list fait référence au même concept que type de contexte (context type), avec l'indicateur --target. Étant donné que les groupes de commandes sont basés sur des plug-ins de CLI :

  • Les plug-ins qui définissent des commandes pour les clusters Kubernetes ont la Cible (Target) k8s
  • Les plug-ins qui définissent des commandes TMC ont la Cible (Target) tmc réservée pour une utilisation ultérieure
  • Les plug-ins qui définissent des commandes indépendantes du contexte n'ont pas de Cible (Target)
  • Les plug-ins portant des noms identiques pour différentes cibles permettent à la CLI Tanzu d'adapter les commandes sous des groupes de commandes tels que tanzu cluster pour s'adapter au contexte.

  Dans TKG v2.1, le seul type de Cible (Target) ou de contexte pris en charge est k8s, qui est également indiqué par :

  • Kubernetes cluster operations dans la sortie des commandes tanzu help
  • kubernetes dans la colonne TARGET de la sortie de tanzu plugin list
• VMware ne recommande pas de déployer des clusters de charge de travail Windows qui ne disposent que de workers basés sur Windows comme indiqué dans la documentation TKG 1.6. VMware recommande plutôt de créer des clusters avec plusieurs systèmes d'exploitation, comme décrit dans la section Déployer un cluster de charge de travail avec plusieurs systèmes d'exploitation. Les clusters avec plusieurs systèmes d'exploitation peuvent exécuter des conteneurs Windows et Linux, prenant ainsi en charge les composants TKG basés sur Linux et les charges de travail Linux.
• En raison des modifications apportées à la gestion des certificats dans Go 1.18, les machines de démarrage macOS doivent ajouter le certificat vCenter à leurs trousseaux avant de pouvoir exécuter tanzu cluster create avec vérification de l'empreinte numérique. Pour plus d'informations, reportez-vous à la section Conditions préalables pour le déploiement du cluster.

Documentation utilisateur

Une nouvelle publication, Déploiement et gestion de clusters de gestion autonomes TKG 2.1, 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

• Résolu dans la version 2.1.1
• Résolu dans la version 2.1.0

Résolu dans la version 2.1.1

Les problèmes suivants documentés sous Problèmes connus dans Tanzu Kubernetes Grid 2.1.0 sont résolus dans Tanzu Kubernetes Grid 2.1.1.

• Impossible de déployer un CNI personnalisé

  L'option CNI:none ne fonctionne pas sur les clusters de charge de travail déployés à partir d'un cluster de gestion autonome. Les seuls choix disponibles sont antrea (par défaut) et calico.

• Un compte d'utilisateur TKG crée des sessions vCenter inactives.

  Le compte vSphere pour TKG crée des sessions vCenter inactives, comme indiqué dans vSphere > inventaire Hôtes et clusters (Hosts and Clusters) > votre instance de vCenter > onglet Surveiller (Monitor) > Sessions.

  Solution : Supprimez les sessions vCenter inactives en démarrant et arrêtant toutes les sessions :

  1. Connectez-vous via ssh à vCenter en tant que root
  2. Si vous y êtes invité, saisissez shell.
  3. Exécutez service-control --stop --all.
  4. Attendez que les services s'affichent comme Stopped.
  5. Exécutez service-control --start --all.

• Les services LoadBalancer pour les clusters de charge de travail basés sur une classe sur Azure nécessitent une configuration manuelle de passerelle ou de serveur frontal

  En raison d'une non-correspondance de nom entre AzureClusterName et ClusterName, les services de type LoadBalancer qui sont déployés pour être utilisés par des applications sur des clusters de charge de travail Azure basés sur une classe ne sont pas accessibles depuis Internet.

  Solution : fournissez votre propre route pour le service d'équilibrage de charge, par exemple via une passerelle NAT, un proxy ou un autre routage interne, afin de permettre aux nœuds derrière l'équilibrage de charge d'accéder à Internet.

  VMware recommande d’utiliser une passerelle NAT, si disponible, pour la connectivité sortante. Si aucune passerelle NAT n’est disponible :

  1. Dans le portail Azure, accédez à la ressource LoadBalancer créée par CAPZ, qui doit avoir le même nom que celle de AzureCluster.
  2. Sélectionnez Configuration d'adresses IP frontales (Frontend IP configuration), cliquez sur Ajouter (Add).
  3. Créez une adresse IP publique pour le service d’équilibrage de charge.

  4. Configurez et créez le service à l'aide de la spécification ci-dessous, en définissant la valeur loadBalancerIP sur l'adresse IP publique lorsqu'elle est indiquée par IP-ADDRESS :

       apiVersion: v1
       kind: Service
       metadata:
         name: frontend
         labels:
           app: guestbook
           tier: frontend
         namespace: sample-app
       spec:
         # Add the frontend public IP here
         loadBalancerIP: IP-ADDRESS
         type: LoadBalancer
         ports:
         - port: 80
         selector:
           app: guestbook
           tier: frontend
     

• La mise à niveau des clusters ne met pas à jour la version de Kube-VIP

  La mise à niveau de clusters de gestion et de charge de travail autonomes vers la version 2.1 ne met pas à niveau leurs kube-vip vers la version actuelle.

  Solution : pour les clusters mis à niveau qui utilisent Kube-VIP pour leur point de terminaison de plan de contrôle, tel que configuré avec AVI_CONTROL_PLANE_HA_PROVIDER = false, mettez à jour le composant kube-vip :

  1. Récupérez le fichier de nomenclature TKr actuel utilisé pour la mise à niveau du cluster. Recherchez une copie locale de ce fichier dans ~/.config/tanzu/tkg/bom/, avec un nom commençant par tkr-. Par exemple, tkr-bom-v1.24.10+vmware.1-tkg.1.yaml.

  2. Répertoriez la version actuelle de kube-vip du fichier de nomenclature, par exemple :

     $ cat ~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+vmware.1-tkg.1.yaml | yq '.components.kube-vip'
     - version: v0.5.7+vmware.1
       images:
         kubeVipImage:
           imagePath: kube-vip
           tag: v0.5.7_vmware.1
     

  3. Obtenez l'objet kcp pour le cluster. Le nom de cet objet a le format CLUSTER-NAME-control-plane.

     • Les objets du cluster de gestion sont créés dans l'espace de noms tkg-system.
     • Les objets du cluster de charge de travail se trouvent dans l'espace de noms utilisé pour la création du cluster ou default si NAMESPACE n'a pas été défini.

  4. Exécutez kubectl edit pour modifier l'objet kcp et mettre à jour le chemin d'accès à kube-vip pour qu'il corresponde à la version actuelle de l'image de nomenclature. Recherchez l'emplacement de ce paramètre en exécutant :

     kubectl get kcp <cluster-name>-control-plane -o jsonpath='{.spec.kubeadmConfigSpec.files[0]}' | jq
     

• La mise à niveau de clusters de gestion de la version 1.5.x vers la version 2.1.0 entraîne une erreur réseau de nœud en raison d'une valeur avi_ingress_node_network_list null dans le secret de l'opérateur AKO

  Avec des clusters de gestion autonomes créés initialement dans TKG 1.5 ou version antérieure, la mise à niveau vers la version 2.1.0 définit une valeur null pour avi_ingress_node_network_list dans le secret de l'opérateur AKO. Cela entraîne une erreur du réseau de nœud lors de la mise à niveau vers la version 2.1.0 et génère des erreurs de configuration Avi manquante dans les journaux.

  Solution : Après la mise à niveau de la CLI Tanzu vers la version 2.1.0, mais avant l'exécution de tanzu mc upgrade :

  1. Basculez vers le contexte du cluster de gestion :

     kubectl config use-context <MGMT-CLUSTER>-admin@<MGMT-CLUSTER>
     

  2. Récupérez le secret de l'opérateur AKO et décodez ses valeurs de données :

     kubectl get secret <MGMT-CLUSTER>-ako-operator-addon -n tkg-system -o jsonpath="{.data.values\.yaml}" | base64 --decode > values.yaml
     

  3. Ouvrez le fichier values.yaml à l'aide d'un éditeur de texte. Le paramètre avi_ingress_node_network_list ressemble à ceci :

     avi_ingress_node_network_list: '""'
     

  4. Modifiez le paramètre pour qu'il ressemble à ce qui suit, avec la plage de votre réseau de nœuds de cluster :

     avi_ingress_node_network_list: '[{"networkName":"VM Network", "cidrs":["10.191.176.0/20"]}]'
     

  5. Codez en base64 les nouvelles valeurs de données et enregistrez la chaîne de sortie :

     base64 -w 0 values.yaml
     

  6. Modifiez le secret de l'opérateur AKO :

     kubectl edit secret MGMT-CLUSTER-ako-operator-addon -n tkg-system
     

  7. Collez la nouvelle chaîne de valeurs de données codées en tant que valeur de values.yaml dans le secret. Enregistrer et quitter.

• TMC ne peut pas déployer de clusters basés sur une classe avec des moteurs de service ne se trouvant pas dans le groupe de moteurs de service (SEG, Service Engine Group) Default-Group.

  Tanzu Mission Control, qui s'intègre à TKG, ne peut pas déployer de nouveaux clusters basés sur une classe qui utilisent NSX ALB et sont configurés avec des moteurs de service ne figurant pas dans le groupe de moteurs de service Default-Group de NSX ALB. Cette limitation n'affecte pas la mise à niveau des clusters de charge de travail existants configurés avec des moteurs de service personnalisés.

  Pour plus d'informations, reportez-vous aux Notes de mise à jour de Tanzu Mission Control.

• Catalogue TMC non pris en charge pour répertorier et déployer des modules

  Vous ne pouvez pas utiliser la fonctionnalité de catalogue de Tanzu Mission Control (TMC) pour répertorier ou installer des modules sur des clusters de charge de travail TKG 2.1, comme décrit dans la section Afficher les modules de la documentation de TMC. L'interface utilisateur TMC affiche le référentiel de modules bloqué dans un état de rapprochement.

Résolu dans la version 2.1.0

Les problèmes suivants documentés sous Problèmes connus dans Tanzu Kubernetes Grid v1.6.1 sont résolus dans Tanzu Kubernetes Grid v2.1.0.

• Les opérations de cluster et d'espace qui suppriment des espaces peuvent échouer si DaemonSet est configuré pour restaurer automatiquement des volumes persistants

  Dans les installations où un DaemonSet utilise des volumes persistants, la suppression d'une machine peut échouer, car le processus de drainage par défaut ignore les DaemonSets et le système attend indéfiniment que les volumes soient détachés du nœud. Les opérations de cluster affectées incluent la mise à niveau, la réduction de charge et la suppression.

• Sur vSphere with Tanzu, tanzu cluster list génère une erreur pour les utilisateurs DevOps

  Lorsqu'un utilisateur disposant du rôle d'ingénieur DevOps, comme décrit dans Rôles d'utilisateur et workflows vSphere with Tanzu, exécute tanzu cluster list, il peut voir une erreur semblable à Error: unable to retrieve combined cluster info: unable to get list of clusters. User cannot list resource "clusters" at the cluster scope.

  Cela se produit, car la commande tanzu cluster command sans option -n tente d'accéder à tous les espaces de noms, dont certains peuvent ne pas être accessibles à un utilisateur ingénieur DevOps.

  Solution : lors de l'exécution de tanzu cluster list, incluez une valeur --namespace pour spécifier un espace de noms auquel l'utilisateur peut accéder.

Problèmes connus

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

• Mise à niveau
• Modules
• Opérations de cluster
• Mise en réseau
• Gestion des identités et des accès
• Stockage
• CLI
• vSphere
• AWS
• Clusters de charge de travail Windows et à plusieurs systèmes d'exploitation
• Image Builder
• AVS

Mise à niveau

• Connu dans la version 2.1.1
• Connu dans la version 2.1.x

Connu dans la version 2.1.1

Voici les problèmes de mise à niveau connus dans la version 2.1.1.

• La mise à niveau de la version 2.1 vers la version 2.1.1 sur vSphere échoue

  Sur vSphere, la mise à niveau de la version 2.1 vers la version 2.1.1 échoue avec l'erreur Reconcile failed:Error. L'erreur se produit, car le module tkg-clusterclass-vsphere n'est pas rapproché et l'installation est bloquée.

  Solution : annulez les variables de ressources vSphere suivantes si elles sont définies dans l'environnement local :

  unset VSPHERE_CLONE_MODE
  unset VSPHERE_DATACENTER
  unset VSPHERE_DATASTORE
  unset VSPHERE_FOLDER
  unset VSPHERE_NETWORK
  unset VSPHERE_RESOURCE_POOL
  unset VSPHERE_SERVER
  unset VSPHERE_STORAGE_POLICY_ID
  unset VSPHERE_TEMPLATE
  unset VSPHERE_WORKER_DISK_GIB
  unset VSPHERE_WORKER_MEM_MIB
  unset VSPHERE_WORKER_NUM_CPUS
  

Connu dans la version 2.1.x

Voici les problèmes de mise à niveau connus dans la version 2.1.x.

• Échec de la mise à niveau des clusters sur Azure

  Sur Azure, la mise à niveau des clusters de gestion et des clusters de charge de travail échoue avec des erreurs telles que context deadline exceeded ou unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane. Cela se produit, car les opérations sur Azure prennent parfois plus de temps que sur d'autres plates-formes.

  Solution : exécutez la commande tanzu management-cluster upgrade ou tanzu cluster upgrade de nouveau, en spécifiant un délai d'expiration plus long dans l'indicateur --timeout. Le délai d'expiration par défaut est 30 ms.

• La mise à niveau échoue pour les clusters de gestion autonomes créés à l'origine dans TKG v1.3 ou version antérieure

  Dans TKG v2.1, les composants qui transforment un cluster générique en cluster de gestion autonome TKG sont regroupés dans un module Carvel tkg-pkg. Les clusters de gestion autonomes créés à l'origine dans TKG v1.3 ou version antérieure ne disposent pas d'un secret de configuration requis par le processus de mise à niveau pour installer tkg-pkg, ce qui entraîne l'échec de la mise à niveau.

  Solution : suivez les étapes supplémentaires répertoriées dans la section Mettre à niveau des clusters de gestion autonomes pour les clusters de gestion autonomes créés dans TKG v1.3 ou version antérieure.

• La mise à niveau échoue pour les clusters créés avec le caractère générique (*) dans le paramètre TKG_NO_PROXY

  TKG v1.6 n'autorise pas le caractère générique (*) dans les paramètres du fichier de configuration du cluster pour TKG_NO_PROXY. Les clusters créés par les versions précédentes de TKG avec ce paramètre nécessitent un traitement spécial avant la mise à niveau, afin d'éviter l'erreur workload cluster configuration validation failed: invalid string '*' in TKG_NO_PROXY.

  Solution : selon le type de cluster que vous mettez à niveau :

  • Cluster de gestion :

    1. Basculez vers le contexte kubectl du cluster de gestion.

    2. Modifiez la commande configMap kapp-controller-config :

       kubectl edit cm kapp-controller-config -n tkg-system
       

    3. Recherchez le champ data.noProxy et modifiez son nom d'hôte générique en supprimant *. Par exemple, remplacez *.vmware.com to .vmware.com

    4. Enregistrer et quitter. Le cluster est prêt à être mis à niveau.

  • Cluster de charge de travail :

    1. Basculer vers le contexte du cluster de charge de travail kubectl

    2. Définissez des variables d'environnement pour le nom et l'espace de noms de votre cluster, par exemple :

       CLUSTER_NAME=my-test-cluster
       NS=my-test-namespace
       

    3. Obtenez et décodez les valeurs de données du contrôleur kapp pour le cluster de charge de travail :

       kubectl get secret "${CLUSTER_NAME}-kapp-controller-data-values" -n $NS -o json | jq -r '.data."values.yaml"' | base64 -d > "${CLUSTER_NAME}-${NS}-kapp-controller-data-values"
       

    4. Modifiez le fichier ${CLUSTER_NAME}-${NS}-kapp-controller-data-values en supprimant * de son paramètre kappController.config.noProxy. Par exemple, modifiez *.vmware.com to .vmware.com.

    5. Enregistrez et quittez.

    6. Recodez le fichier de valeurs de données ${CLUSTER_NAME}-${NS}-kapp-controller-data-values :

       cat "${CLUSTER_NAME}-${NS}-kapp-controller-data-values" | base64 -w 0
       

    7. Modifiez le secret ${CLUSTER_NAME}-${NS}-kapp-controller-data-values et mettez à jour son paramètre data.value.yaml en collant la chaîne de valeurs de données récemment codée.

       kubectl edit secret "${CLUSTER_NAME}-kapp-controller-data-values" -n "${NS}"
       

    8. Enregistrer et quitter. Le cluster est prêt à être mis à niveau.

• Les anciennes versions TKr ne sont pas disponibles immédiatement après la mise à niveau du cluster de gestion autonome

  La mise à niveau d'un cluster de gestion autonome de TKG v1.6 vers la version 2.1 remplace le contrôleur source TKr par une version plus récente qui prend en charge les clusters basés sur une classe, puis resynchronise les TKr. Par conséquent, une fois la commande tanzu mc upgrade terminée, tanzu cluster available-upgrades get et tanzu kubernetes-release get peuvent ne pas afficher toutes les versions TKr valides et la CLI Tanzu peut ne pas être en mesure de mettre à niveau immédiatement les clusters de charge de travail.

  Solution : attendez quelques minutes que les TKr se téléchargent de nouveau.

Modules

• La mise à jour de la configuration nécessite une mise à niveau pour certains modules

  Problème connu dans : v2.1.1

  Le référentiel de modules Tanzu Standard pour TKG 2.1.1 ne dispose pas des versions de module suivantes qui se trouvent dans le référentiel 2.1.0 :

  • cert-manager : 1.10.1+vmware.1-tkg.1.yml, 1.5.3+vmware.7-tkg.1.yml et 1.7.2+vmware.3-tkg.1.yml
  • external-dns : 0.10.0+vmware.1-tkg.3.yml, 0.11.0+vmware.1-tkg.3.yml et 0.12.2+vmware.4-tkg.1.yml
  • grafana : 7.5.16+vmware.1-tkg.2.yml

  De ce fait, après la mise à niveau d'un cluster de charge de travail de TKG 2.1.0 vers la version 2.1.1, vous ne pouvez pas exécuter tanzu package installed update pour mettre à jour les configurations de ces modules sans mettre à niveau aussi les modules vers les dernières versions :

  • cert-manager : 1.10.1+vmware.1-tkg.2.yml
  • external-dns : 0.12.2+vmware.4-tkg.2.yml
  • grafana : 7.5.17+vmware.1-tkg.1.yml

  Ce problème se produit uniquement si vous devez modifier les configurations des modules ; les modules installés continuent de s'exécuter sans mise à niveau.

  Solution : Effectuez l'une ou l'autre des opérations suivantes :

  • Si vous devez mettre à jour votre configuration du module cert-manager, external-dns ou grafana :

    1. Exécutez tanzu package installed get pour récupérer la version du module.
    2. Comme indiqué ci-dessus, si le référentiel 2.1.1 ne dispose pas de la version du module installée, transmettez la dernière version à l'indicateur -v lors de l'exécution de tanzu package installed update.

  • Après la mise à niveau des clusters de charge de travail vers TKG 2.1.1, mettez à jour les trois modules vers les versions ci-dessus.

  Pour les commandes tanzu package, reportez-vous aux éléments décrits dans la section Installer et gérer des modules.

• Multus CNI échoue sur medium et les espaces plus petits avec NSX Advanced Load Balancer

  Sur vSphere, les clusters de charge de travail avec des nœuds worker medium ou plus petits exécutant le module Multus CNI avec NSX ALB peuvent échouer avec des erreurs Insufficient CPU ou d'autres erreurs.

  Solution : pour utiliser Multus CNI avec NSX ALB, déployez des clusters de charge de travail avec des nœuds worker de taille large ou extra-large.

• Le fichier de nomenclature TKG contient une version de module cert-manager superflue

  Le fichier de nomenclature TKG que la CLI Tanzu installe dans ~/.config/tanzu/tkg répertorie les versions v1.5.3 et v1.7.2 du module cert manager (jetstack_cert-manager). La version correcte à installer est la version 1.5.3, comme décrit dans la section Installer cert-manager.

  Solution : installez la version 1.5.3 de cert-manager.

• La désactivation de Pinniped nécessite la suppression manuelle du Secret sur les clusters hérités

  Lorsque vous désactivez la gestion des identités externes sur un cluster de gestion, l'objet Pinniped Secret inutilisé reste présent sur les clusters de charge de travail hérités.

  Si un utilisateur tente ensuite d'accéder au cluster à l'aide d'un ancien kubeconfig, une fenêtre contextuelle de connexion s'affiche et échoue.

  Solution : supprimez manuellement le code Pinniped Secret du cluster hérité, comme décrit dans la section Désactiver la gestion des identités.

• L'exportation des CVE Harbor peut échouer lorsque l'ID d'exécution dépasse plus de 1 000 000

  Harbor v2.6.3, qui est la version en module pour TKG v2.1, 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.

• Aucune prise en charge du cache de proxy Harbor

  Vous ne pouvez pas utiliser la fonctionnalité cache de proxy de Harbor pour exécuter Tanzu Kubernetes Grid 2.1 dans un environnement à accès restreint à Internet. Vous pouvez toujours utiliser un cache de proxy Harbor pour transmettre par proxy des images de versions antérieures de Tanzu Kubernetes Grid et des images non-Tanzu, telles que des images d'application.

  Solution : aucune.

• 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.

  Solution : définissez les étiquettes audit=privileged et warn=privileged dans les espaces de noms de module affectés, comme décrit dans la section Contrôleur d'admission de sécurité d'espace (version d'évaluation technique).

• 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

• Connu dans la version 2.1.1
• Connu dans la version 2.1

Connu dans la version 2.1.1

Voici les problèmes d'opérations de cluster connus dans la version 2.1.1.

• 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 1.23.10, qui est la version de Kubernetes par défaut dans TKG 1.6.1, comme indiqué dans la section Versions de Kubernetes prises en charge dans Tanzu Kubernetes Grid 2.1.

  TKG v2.1.1 prend entièrement en charge les clusters existants qui exécutent d'autres versions de Kubernetes.

  Solution : Créez un cluster de charge de travail qui exécute Kubernetes 1.24.10, 1.23.16 ou 1.22.17. Le projet Kubernetes recommande d'exécuter des composants sur la version de correctif la plus récente de toute version mineure actuelle.

Connu dans la version v2.1

• 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.

  Solution : À la deuxième étape, lorsque vous exécutez tanzu cluster create une deuxième fois et transmettez le manifeste de cluster généré, spécifiez les mêmes valeurs --tkr et d'autres options que vous avez effectuées à la première étape, comme décrit dans la section Créer un cluster basé sur une classe.

• 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 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. Cela se produit, car dans TKG 2.1.1, les ressources AntreaConfig ont besoin de tkg.tanzu.vmware.com/package-name label pour que le gestionnaire de modules complémentaires installe Antrea dans le cluster de charge de travail désigné. Ce problème ne s'applique pas à la version 2.1.0.

  Solution : Ajoutez les étiquettes manquantes à AntreaConfig dans le fichier de configuration ClusterClass et réessayez de créer le cluster :

  labels:
  tkg.tanzu.vmware.com/cluster-name: rito
  tkg.tanzu.vmware.com/package-name: antrea.tanzu.vmware.com.1.7.2---vmware.1-tkg.1-advanced 
  

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

  TKG 2.1 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 2.1, vous ne pouvez pas exécuter NSX Advanced Load Balancer (ALB) en tant que 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.

Stockage

• La modification de l'objet par défaut StorageClass entraîne l'échec du rapprochement dans les clusters de charge de travail

  La modification des propriétés d'un objet StorageClass par défaut inclus dans TKG entraîne un échec du rapprochement des modules dans les clusters de charge de travail qui utilisent la classe de stockage.

  Solution : pour personnaliser une classe de stockage, créez une définition StorageClass avec une valeur name au lieu de modifier la définition d'objet par défaut, puis reconfigurez le cluster pour utiliser la nouvelle classe de 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

• 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.

• 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.

  Solution : Définissez le ou les paramètres de configuration répertoriés dans la sortie d'erreur en tant que variables d'environnement local. Pour éviter cette erreur, vous pouvez créer des clusters basés sur une classe en une seule étape, sans prévisualiser leur configuration, en définissant la fonctionnalité auto-apply-generated-clusterclass-based-configuration sur true, puis en exécutant tanzu cluster create. Pour définir auto-apply-generated-clusterclass-based-configuration sur true, exécutez la commande suivante :

  tanzu config set features.cluster.auto-apply-generated-clusterclass-based-configuration true
  

  Cette opération configure la CLI Tanzu de manière à toujours créer des clusters basés sur une classe en une seule étape. Pour plus d'informations, reportez-vous à la section Créer un cluster basé sur une classe.

• 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.

• Windows CMD : caractères superflus dans les en-têtes de colonne de sortie de CLI

  Dans l'invite de commande Windows (CMD), la sortie de commande de CLI Tanzu formatée en colonnes inclut des caractères superflus dans les en-têtes de colonne.

  Ce problème ne se produit pas avec le terminal Windows ou PowerShell.

  Solution : sur les machines de démarrage Windows, exécutez la CLI Tanzu depuis votre terminal Windows.

• Erreur AKODeploymentConfig ignorée lors de la création du cluster de gestion

  L'exécution tanzu management-cluster create pour créer un cluster de gestion avec les sorties NSX ALB génère l'erreur suivante : no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???. Vous pouvez ignorer cette erreur. Pour plus d'informations, reportez-vous à cet article dans la base de connaissances.

• Erreurs machinehealthcheck et clusterresourceset ignorées lors de la création du cluster de charge de travail sur vSphere

  Lorsqu'un cluster de charge de travail est déployé sur vSphere à l'aide de la commande tanzu cluster create via vSphere with Tanzu, la sortie peut inclure des erreurs liées à l'exécution de machinehealthcheck et à l'accès aux ressources clusterresourceset, comme indiqué ci-dessous :

  Error from server (Forbidden): error when creating "/tmp/kubeapply-3798885393": machinehealthchecks.cluster.x-k8s.io is forbidden: User "sso:[email protected]" cannot create resource "machinehealthchecks" in API group "cluster.x-k8s.io" in the namespace "tkg"
  ...
  Error from server (Forbidden): error when retrieving current configuration of: Resource: "addons.cluster.x-k8s.io/v1beta1, Resource=clusterresourcesets", GroupVersionKind: "addons.cluster.x-k8s.io/v1beta1, Kind=ClusterResourceSet"
  ...
  

  Le cluster de charge de travail a été créé. Vous pouvez ignorer les erreurs.

• La CLI indique temporairement de manière incorrecte l'état des nœuds récemment supprimés lorsque les MHC sont désactivés

  Lorsque les contrôles de santé de la machine (MHCs) sont désactivés, les commandes de la CLI Tanzu telles que tanzu cluster status peuvent ne pas signaler l'état à jour du nœud pendant la recréation de l'infrastructure.

  Solution : aucune.

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.

• Avec NSX ALB, impossible de créer des clusters avec des noms identiques

  Si vous utilisez NSX Advanced Load Balancer pour les charges de travail (AVI_ENABLE) ou le plan de contrôle (AVI_CONTROL_PLANE_HA_PROVIDER), le contrôleur Avi peut ne pas parvenir à distinguer les clusters portant des noms identiques.

  Solution : définissez une valeur de CLUSTER_NAME unique pour chaque cluster :

  • Clusters de gestion : ne créez pas plusieurs clusters de gestion avec la même valeur CLUSTER_NAME, même à partir de différentes machines de démarrage.

  • Clusters de charge de travail : ne créez pas plusieurs clusters de charge de travail qui ont la même valeur CLUSTER_NAME et se trouvent également dans le même espace de noms de cluster de gestion, tel que défini par leur valeur NAMESPACE.

• L'ajout de la gestion des identités externes à un déploiement existant peut nécessiter la définition d'une valeur de VSPHERE_CONTROL_PLANE_ENDPOINT factice

  L'intégration d'un fournisseur d'identité externe à un déploiement TKG existant peut nécessiter la définition d'une valeur de VSPHERE_CONTROL_PLANE_ENDPOINT factice dans le fichier de configuration du cluster de gestion utilisé pour créer le secret de module complémentaire, comme décrit dans la section Générer le secret de module complémentaire Pinniped pour le cluster de gestion

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.

Clusters de charge de travail Windows et à plusieurs systèmes d'exploitation

• Vous ne pouvez pas créer une image de machine Windows sur une machine MacOS

  En raison d'un problème avec l'utilitaire open source packer utilisé par Kubernetes Image Builder, vous ne pouvez pas créer une image de machine Windows sur une machine MacOS comme décrit dans la section Images de machine personnalisée Windows.

  Solution : Utilisez une machine Linux pour créer vos images de machine Windows personnalisées.

• La sauvegarde et la restauration ne sont pas prises en charge pour les clusters de charge de travail Windows et avec plusieurs systèmes d'exploitation

  Vous ne pouvez pas sauvegarder et restaurer des clusters de charge de travail avec des nœuds worker basés sur Windows.

  Solution : Aucune

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.