times

VMware NSX Container Plugin 3.1.2 | 15 avril 2021 | Build 17855682

Vérifiez régulièrement les ajouts et les mises à jour apportées à ce document.

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés
Conditions de compatibilité
Problèmes résolus
Problèmes connus

Nouveautés

NSX Container Plugin (NCP) 3.1.2 comprend la nouvelle fonctionnalité suivante :

Pour la persistance de l'équilibreur de charge de couche 7, prise en charge de la spécification du nom du cookie

Avis d'obsolescence

L'annotation « ncp/whitelist-source-range » sera obsolète dans NCP 3.3. À partir de NCP 3.1.1, vous pouvez utiliser l'annotation « ncp/allowed-source-range » à la place.

Conditions de compatibilité

Produit	Version
Vignette NCP/NSX-T pour Tanzu Application Service (TAS)	3.1.2
NSX-T	3.0.3, 3.1.0, 3.1.1, 3.1.2, 3.1.3
vSphere	6.7, 7.0
Kubernetes	1.18, 1.19, 1.20
OpenShift 3	3.11 Remarque : la prise en charge d'OpenShift 3.x sera obsolète dans une version ultérieure.
OpenShift 4	RHCOS 4.6, 4.7
Système d'exploitation de VM sur hôte Kubernetes	Ubuntu 18.04, Ubuntu 20.04 CentOS 7.8, CentOS 7.9, CentOS 8.3 RHEL 7.8, RHEL 7.9, RHEL 8.1, RHEL 8.3 Consultez les remarques ci-dessous.
Système d'exploitation de VM sur hôte OpenShift 3	RHEL 7.7, RHEL 7.8 (Remarque : la prise en charge de RHEL pour Kubernetes Vanilla sera obsolète dans une version ultérieure.)
Tanzu Application Service	Ops Manager 2.7 + TAS 2.7 (LTS) Ops Manager 2.9 + TAS 2.9 Ops Manager 2.10 + TAS 2.10 Ops Manager 2.10 + TAS 2.11
Tanzu Kubernetes Grid Integrated (TKGI)	1.11

Remarques :

L'installation du module de noyau nsx-ovs sur CentOS/RHEL nécessite une version de noyau spécifique. Les versions du noyau RHEL prises en charge sont 1127 et 1160, quelle que soit la version de RHEL. Notez que la version du noyau par défaut est 1127 pour RHEL 7.8 et 1160 pour RHEL 7.9. Si vous exécutez une version de noyau différente, vous pouvez ignorer l'installation du module de noyau nsx-ovs en définissant « use_nsx_ovs_kernel_module » sur « False » dans la section « nsx_node_agent » dans le mappage de configuration nsx-node-agent.

À partir de NCP 3.1.2, l'image RHEL ne sera plus distribuée. Pour toutes les intégrations prises en charge, utilisez l'image de base universelle Red Hat. Pour plus d'informations, consultez la section https://www.redhat.com/fr/blog/introducing-red-hat-universal-base-image.

Prise en charge de la mise à niveau vers cette version :

Toutes les versions précédentes de 3.1.x et toutes les versions de NCP 3.0.x

Problèmes résolus

Problème 2707883 : nsx-ncp-operator ne crée pas de ressource Kubernetes liée à NCP si la ressource a été supprimée lorsque nsx-ncp-operator n'était pas en cours d'exécution
Par exemple, si vous supprimez nsx-node-agent ou nsx-ncp-bootstrap DaemonSet lorsque nsx-ncp-operator n'est pas en cours d'exécution, il n'est pas recréé lorsque nsx-ncp-operator est à nouveau en cours d'exécution.

Problèmes connus

Problème 2131494 : NGINX Kubernetes Ingress fonctionne toujours après la redéfinition de la classe Ingress nginx sur nsx
Lorsque vous créez un objet NGINX Kubernetes Ingress, NGINX crée des règles de transfert du trafic. Si vous redéfinissez la classe Ingress sur une autre valeur, NGINX ne supprime pas les règles et continue à les appliquer, même si vous supprimez l'objet Kubernetes Ingress après la modification de la classe. Il s'agit d'une limitation de NGINX.

Solution : pour supprimer les règles créées par NGINX, supprimez l'objet Kubernetes Ingress lorsque la valeur de classe est nginx. Recréez ensuite l'objet Kubernetes Ingress.
Pour un service Kubernetes de type ClusterIP, l'affinité de session basée sur l'adresse IP du client n'est pas prise en charge
NCP ne prend pas en charge l'affinité de session basée sur l'adresse IP du client pour un service Kubernetes de type ClusterIP.

Solution : aucune
Pour un service Kubernetes de type ClusterIP, l'indicateur de mode épingle n'est pas pris en charge
NCP ne prend pas en charge l'indicateur de mode épingle pour un service Kubernetes de type ClusterIP.

Solution : aucune
Problème 2192489 : après la désactivation de « BOSH DNS server » dans TAS director config, le serveur DNS Bosh (169.254.0.2) figure toujours dans le fichier resolve.conf du conteneur.
Dans un environnement TAS exécutant TAS 2.2, après que vous désactivez « BOSH DNS server » dans TAS director config, le serveur DNS Bosh (169.254.0.2) figure toujours dans le fichier resolve.conf du conteneur. Dans ce cas, l'exécution d'une commande ping avec un nom de domaine complet est très longue. Ce problème n'existe pas avec TAS 2.1.

Solution : aucune. Il s'agit d'un problème TAS.
Problème 2224218 : après la suppression d'un service ou d’une application, la libération de l’adresse IP SNAT pour le pool IP dure 2 minutes
Si vous supprimez un service ou une application et que vous le/la recréez en moins de 2 minutes, il/elle obtiendra une nouvelle IP SNAT du pool IP.

Solution : après la suppression d'un service ou d’une application, patientez 2 minutes avant de le/la recréer si vous souhaitez réutiliser la même adresse IP.
Problème 2404302 : si plusieurs profils d'application d'équilibreur de charge pour le même type de ressource (par exemple, HTTP) existent sur NSX-T, NCP choisira l'un d'entre eux à attacher aux serveurs virtuels.
Si plusieurs profils d'application d'équilibreur de charge HTTP existent sur NSX-T, NCP choisira l'un d'entre eux avec la configuration x_forwarded_for appropriée à attacher au serveur virtuel HTTP et HTTPS. Si plusieurs profils d'application FastTCP et UDP existent sur NSX-T, NCP choisira l'un d'entre eux à attacher respectivement aux serveurs virtuels TCP et UDP. Les profils d'application d'équilibreur de charge peuvent avoir été créés par différentes applications avec des paramètres différents. Si NCP choisit d'attacher l'un de ces profils d'application d'équilibreur de charge aux serveurs virtuels créés par NCP, il peut interrompre le workflow d'autres applications.

Solution : aucune
Problème 2397621 : échec de l'installation d'OpenShift 3
L'installation d'OpenShift 3 attend que l'état d'un nœud soit prêt, ce qui est possible après l'installation du plug-in CNI. Dans cette version, il n'existe pas de fichier de plug-in CNI distinct, ce qui provoque l'échec de l'installation d'OpenShift.

Solution : créez le répertoire /etc/cni/net.d sur chaque nœud avant de démarrer l'installation.
Problème 2413383 : la mise à niveau d'OpenShift 3 échoue, car tous les nœuds ne sont pas prêts
Par défaut, l'espace de démarrage NCP n'est pas planifié sur le nœud maître. Par conséquent, l'état du nœud maître est toujours Non prêt.

Solution : attribuez au nœud maître le rôle « calcul » pour permettre aux DaemonSets nsx-ncp-bootstrap et nsx-node-agent de créer des espaces. L'état du nœud passe à « Prêt » une fois que nsx-ncp-bootstrap a installé NSX-CNI.
Problème 2451442 : après le redémarrage répété de NCP et la recréation d'un espace de noms, NCP peut ne pas allouer d'adresses IP à des espaces
Si vous supprimez et recréez plusieurs fois le même espace de noms lors du redémarrage de NCP, celui-ci peut ne pas allouer d'adresses IP à des espaces dans cet espace de noms.

Solution : supprimez toutes les ressources NSX périmées (routeurs logiques, commutateurs logiques et ports logiques) associées à l'espace de noms, puis recréez-les.
Problème 2460219 : la redirection HTTP ne fonctionne pas sans un pool de serveurs par défaut
Si le serveur virtuel HTTP n'est pas lié à un pool de serveurs, la redirection HTTP échoue. Ce problème se produit dans NSX-T 2.5.0 et versions antérieures.

Solution : créez un pool de serveurs par défaut ou effectuez une mise à niveau vers NSX-T 2.5.1.
Problème 2518111 : NCP ne parvient pas à supprimer des ressources NSX-T qui ont été mises à jour à partir de NSX-T
NCP crée des ressources NSX-T en fonction des configurations que vous spécifiez. Si vous effectuez des mises à jour de ces ressources NSX-T via NSX Manager ou l'API NSX-T, NCP peut ne pas parvenir à supprimer ces ressources et les recréer lorsque cela est nécessaire.

Solution : ne mettez pas à jour des ressources NSX-T créées par NCP via NSX Manager ou l'API NSX-T.
Problème 2524778 : NSX Manager indique que NCP est inactif ou défectueux après la suppression du nœud master NCP
Après la suppression d'un nœud master NCP, par exemple, après un basculement réussi vers un nœud de sauvegarde, l'état de santé de NCP indique toujours inactif alors qu'il devrait être actif.

Solution : utilisez l'API Gestionnaire DELETE /api/v1/systemhealth/container-cluster/<cluster-id>/ncp/status pour effacer manuellement l'état obsolète.
Problème 2517201 : impossible de créer un espace sur un hôte ESXi
Après la suppression d'un hôte ESXi d'un cluster vSphere et son rajout au cluster, la création d'un espace sur l'hôte échoue.

Solution : redémarrez NCP.
Problème 2416376 : NCP ne parvient pas à traiter un groupe de sécurité d'application (ASG , App Security Group) TAS qui se lie à plus de 128 espaces
En raison d'une limite dans le pare-feu distribué de NSX-T, NCP ne peut pas traiter un ASG TAS qui se lie à plus de 128 espaces.

Solution : créez plusieurs ASG et liez chacun d'eux à 128 espaces au maximum.
Problème 2534726 : si la mise à niveau vers NCP 3.0.1 via NSX-T Tile échoue, l'utilisation de la ligne de commande BOSH pour rétablir la mise à niveau entraîne des problèmes de performances
Lors de la mise à niveau vers NCP 3.0.1 via NSX-T Tile sur OpsMgr, le processus de mise à niveau marquera les profils de commutation HA dans NSX Manager utilisés par NCP comme étant inactifs. Les profils de commutation seront supprimés lors du redémarrage de NCP. Si la mise à niveau échoue et que vous utilisez une commande BOSH telle que « bosh deploy -d <deployment-id> -n <deployment>.yml » pour rétablir la mise à niveau, les profils de commutation HA ne seront pas supprimés. NCP continuera à s'exécuter mais les performances seront dégradées.

Solution : mettez toujours à niveau NCP via OpsMgr et non par la ligne de commande BOSH.
Problème 2537221 : après la mise à niveau de NSX-T vers 3.0, l'état de la mise en réseau des objets liés au conteneur dans l'interface utilisateur de NSX Manager est indiqué comme Inconnu
Dans l'interface utilisateur de NSX Manager, l'onglet Inventaire > Conteneurs affiche les objets liés au conteneur et leur état. Dans un environnement TKGI, après la mise à niveau de NSX-T vers la version 3.0, l'état de la mise en réseau des objets liés au conteneur est indiqué comme Inconnu. Ce problème est dû au fait que TKGI ne détecte pas le changement de version de NSX-T. Ce problème ne se produit pas si NCP s'exécute en tant qu'espace et que la sonde de réactivité est active.

Solution : après la mise à niveau de NSX-T, redémarrez progressivement les instances NCP (pas plus de 10 en même temps) afin de ne pas surcharger NSX Manager.
Problème 2550474 : dans un environnement OpenShift, la modification d'une route HTTPS vers HTTP peut entraîner un dysfonctionnement de la route HTTP
Si vous modifiez une route HTTPS et que vous supprimez les données liées à TLS pour la convertir en route HTTP, il se peut que la route HTTP ne fonctionne pas comme prévu.

Solution : supprimez la route HTTPS et créez une nouvelle route HTTP.
Problème 2552573 : dans un environnement OpenShift 4.3, l'installation du cluster peut échouer si le protocole DHCP est configuré à l'aide de l'interface utilisateur de Stratégie
Dans un environnement OpenShift 4.3, l'installation du cluster requiert qu'un serveur DHCP soit disponible pour fournir des adresses IP et des informations DNS. Si vous utilisez le serveur DHCP configuré dans NSX-T à l'aide de l'interface utilisateur de Stratégie, l'installation du cluster peut échouer.

Solution : configurez un serveur DHCP à l'aide de l'interface utilisateur de Gestionnaire, supprimez le cluster qui n'a pas pu être installé et recréez-le.
Problème 2552564 : dans un environnement OpenShift 4.3, le redirecteur DNS peut cesser de fonctionner en cas de chevauchement d'adresse
Dans un environnement OpenShift 4.3, l'installation du cluster nécessite la configuration d'un serveur DNS. Si vous utilisez NSX-T pour configurer un redirecteur DNS et que l'adresse IP chevauche le service DNS, le redirecteur DNS cessera de fonctionner et l'installation du cluster échouera.

Solution : configurez un service DNS externe, supprimez le cluster qui n'a pas pu être installé et recréez-le.
Problème 2483242 : trafic IPv6 des conteneurs bloqué par NSX-T SpoofGuard
L'adresse locale de lien IPv6 n'est pas mise automatiquement sur liste blanche lorsque SpooGuard est activé.

Solution : désactivez SpoofGuard en définissant nsx_v3.enable_spoofguard = False dans la configuration NCP.
Problème 2552609 : données X-Forwarded-For (XFF) et X-Forwarded-Port incorrectes
Si vous configurez XFF avec INSERT ou REPLACE pour les règles d'entrée HTTPS (Kubernetes) ou les routes HTTPS (OpenShift), vous pouvez voir des valeurs X-Forwarded-For et X-Forwarded-Port incorrectes dans les en-têtes XFF.

Solution : aucune.
Problème 2555336 : le trafic d'espaces ne fonctionne pas en raison de ports logiques en double créés en mode Gestionnaire
Ce problème est plus susceptible de se produire lorsqu'il existe de nombreux espaces dans plusieurs clusters. Lorsque vous créez un espace, le trafic vers l'espace ne fonctionne pas. NSX-T affiche plusieurs ports logiques créés pour le même conteneur. Dans le journal NCP, seul l'ID de l'un des ports logiques est disponible.

Solution : supprimez l'espace et recréez-le. Les ports obsolètes sur NSX-T seront supprimés lors du redémarrage de NCP.
Problème 2554357 : la mise à l'échelle automatique de l'équilibrage de charge ne fonctionne pas pour IPv6
Dans un environnement IPv6, un service Kubernetes de type LoadBalancer ne sera pas actif lorsque l'échelle d'équilibreur de charge existante sera atteinte.

Solution : définissez nsx_v3.lb_segment_subnet = FE80::/10 dans /var/vcap/jobs/ncp/config/ncp.ini pour les déploiements TKGI et dans nsx-ncp-configmap pour les autres. Puis redémarrez NCP.
Problème 2597423 : lors de l'importation d'objets de gestionnaire dans la stratégie, une restauration entraîne la perte des balises de certaines ressources
Lors de l'importation d'objets de gestionnaire dans la stratégie, si une restauration est nécessaire, les balises des objets suivants ne seront pas restaurées :
- Profils Spoofguard (partie des ressources partagées et de cluster)
- BgpneighbourConfig (partie des ressources partagées)
- BgpRoutingConfig (partie des ressources partagées)
- StaticRoute BfdPeer (partie des ressources partagées)
Solution : pour les ressources qui font partie des ressources partagées, restaurez manuellement les balises. Utilisez la fonctionnalité de sauvegarde et de restauration pour restaurer les ressources qui font partie des ressources du cluster.
Problème 2579968 : lorsque des modifications sont apportées aux services Kubernetes de type LoadBalancer à une fréquence élevée, certains serveurs virtuels et pools de serveurs ne sont pas supprimés comme prévu
Lorsque des modifications sont apportées aux services Kubernetes de type LoadBalancer à une fréquence élevée, certains serveurs virtuels et pools de serveurs peuvent rester dans l'environnement NSX-T lorsqu'ils doivent être supprimés.

Solution : redémarrez NCP. Vous pouvez également supprimer manuellement les serveurs virtuels périmés et les ressources qui leur sont associées. Un serveur virtuel est périmé si aucun service Kubernetes de type LoadBalancer n'a l'identifiant du serveur virtuel dans la balise external_id.
Problème 2536383 : après la mise à niveau de NSX-T vers 3.0 ou version ultérieure, l'interface utilisateur de NSX-T n'affiche pas correctement les informations liées à NCP
Après la mise à niveau de NSX-T vers 3.0 ou version ultérieure, l'onglet Inventaire > Conteneurs dans l'interface utilisateur de NSX-T indique que l'état de mise en réseau des objets liés au conteneur est inconnu. De plus, les clusters NCP ne s'affichent pas dans l'onglet Système > Infrastructure > Nœuds > Clusters NCP. Ce problème se produit généralement dans un environnement TKGI.

Solution : après la mise à niveau de NSX-T, redémarrez progressivement les instances NCP (pas plus de 10 en même temps).
Problème 2622099 : le service Kubernetes de type Initialisation LoadBalancer échoue avec le code d'erreur NCP00113 et le message d'erreur « L'objet a été modifié par un autre utilisateur »
Dans un déploiement à un seul niveau avec une API de stratégie, si vous utilisez une passerelle de niveau 1 existante comme passerelle de niveau supérieur et que la taille d'allocation de pool de la passerelle est le ROUTAGE, un service Kubernetes de type LoadBalancer peut ne pas parvenir à s'initialiser avec le code d'erreur NCP00113 et le message d'erreur «L'objet a été modifié par un autre utilisateur. Veuillez réessayer.»

Solution : lorsque le problème apparaît, patientez 5 minutes. Puis redémarrez NCP. Le problème sera résolu.
Problème 2633679 : NCP Operator ne prend pas en charge les nœuds OpenShift attachés à un segment de niveau 1 créé à l'aide de l'API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id>
NCP Operator ne prend pas en charge les nœuds OpenShift attachés à un segment de niveau 1 créé à l'aide de l'API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id>.

Solution : utilisez l'API /policy/api/v1/infra/segments/<segment-id> pour créer le segment.
NCP ne parvient pas à démarrer lorsque l'option « Connexion au fichier » est activée lors de l'installation de Kubernetes
Ce problème se produit lorsque uid:gid=1000:1000 sur l'hôte de conteneur n'est pas autorisé à accéder au dossier du journal.

Solution : utilisez l'une des méthodes suivantes :
- Modifiez le mode du dossier de journaux sur 777 sur les hôtes de conteneur.
- Accordez l'autorisation « rwx » du dossier de journaux à uid:gid=1000:1000 sur les hôtes de conteneur.
- Désactivez la fonctionnalité « Journalisation dans le fichier ».
Problème 2653214 : erreur lors de la recherche du port de segment pour un nœud après la modification de l'adresse IP du nœud
Après la modification de l'adresse IP d'un nœud, si vous mettez à niveau NCP ou si l'espace de NCP Operator est redémarré, la vérification de l'état de NCP Operator à l'aide de la commande « oc describe co nsx-ncp » affiche le message d'erreur « Erreur lors de la recherche du port de segment pour le nœud ... »

Solution : aucune. L'ajout d'une adresse IP statique sur une interface de nœud qui a également la configuration DHCP n'est pas pris en charge.
Problème 2664457 : lors de l'utilisation de DHCP dans OpenShift, la connectivité peut être temporairement perdue lorsque nsx-node-agent démarre ou redémarre
nsx-ovs crée et active 5 profils de connexion temporaires pour configurer ovs_bridge mais leur activation peut échouer temporairement dans NetworkManager. Ainsi, aucune adresse IP (connectivité) n'est présente sur la machine virtuelle sur ovs_uplink_port et/ou ovs_bridge.

Solution : Redémarrez la VM ou attendez que NetworkManager active tous les profils.
Problème 2672677 : un nœud peut cesser de répondre dans un environnement OpenShift 4 fortement contraint
Dans un environnement OpenShift 4 présentant un niveau élevé de densité d'espace par nœud et une fréquence élevée d'espaces supprimés et créés, il est possible qu'un nœud RHCOS passe à l'état « Non prêt ». Les espaces exécutés sur le nœud affecté, à l'exception des membres daemonset, seront supprimés et recréés sur d'autres nœuds de l'environnement.

Solution : redémarrez le nœud impacté.
Problème 2706551 : l'installation automatisée de pile complète d'OpenShift (appelée IPI) échoue, car les nœuds ne sont plus prêts pendant l'installation
L'espace de survie ajoute le VIP Kubernetes au ovs_bridge sur les nœuds maîtres avant que le serveur d'API Kubernetes ne commence à s'exécuter. Par conséquent, toutes les demandes au serveur d'API Kubernetes échouent et l'installation ne peut pas se terminer.

Solution : aucune
Problème 2697547 : HostPort non pris en charge sur les nœuds RHEL/CentOS/RHCOS
Vous pouvez spécifier des hostPorts sur Kubernetes et TKGI natifs sur des nœuds Ubuntu en spécifiant « enable_hostport_snat » sur True dans nsx-node-agent ConfigMap. Cependant, sur les nœuds RHEL/CentOS/RHCOS hostPort n'est pas pris en charge et le paramètre « enable_hostport_snat » est ignoré.

Solution : aucune
Problème 2707174 : un espace supprimé et recréé avec le même espace de noms et le même nom n'a pas de connectivité réseau
Si un espace est supprimé et recréé avec les mêmes espace de noms et nom lorsque NCP n'est pas en cours d'exécution et que nsx-ncp-agents sont en cours d'exécution, l'espace peut obtenir des configurations réseau erronées et ne pas pouvoir accéder au réseau.

Solution : supprimez l'espace et recréez-le lorsque NCP est en cours d'exécution.
Problème 2713782 : les appels NSX API échouent avec l'erreur « SSL : DECRYPTION_FAILED_OR_BAD_RECORD_MAC »
Parfois, au démarrage de NCP, il peut redémarrer ou ne pas initialiser les services d'équilibreur de charge en raison de la présence d'un serveur d'équilibrage de charge en double ou d'un routeur logique de niveau 1 pour l'équilibreur de charge. En outre, lorsque NCP est en cours d'exécution, un point de terminaison NSX peut être signalé comme étant INACTIF pendant une courte période (moins d'une seconde). Si l'initialisation de l'équilibreur de charge échoue, le journal NCP indiquera le message « Échec de l'initialisation des services d'équilibreur de charge ».

Ce comportement se produit uniquement lorsque NCP fait un équilibrage de charge côté client sur plusieurs instances NSX Manager. Cela ne se produit pas lorsqu'un point de terminaison API unique est configuré dans ncp.ini.

Solution : augmentez la valeur du paramètre nsx_v3.conn_idle_timeout. Notez que cela peut entraîner un temps d'attente plus long pour que les points de terminaison soient détectés comme étant disponibles après une déconnexion temporaire lors de l'utilisation de l'équilibreur de charge côté client.
Problème 2745904 : la fonctionnalité « Utiliser IPSet pour l'ASG en cours d'exécution par défaut » ne prend pas en charge la suppression ou le remplacement d'un bloc d'adresses IP de conteneur existant
Si vous activez « Utiliser IPSet pour l'ASG en cours d'exécution par défaut » sur une vignette NCP, NCP créera un NSGroup dédié pour tous les blocs d'adresses IP de conteneur configurés par « Blocs d'adresses IP de réseaux de conteneurs » sur la même vignette NCP. Ce NSGroup sera utilisé dans les règles de pare-feu créées pour les ASG globaux en cours d'exécution afin d'autoriser le trafic pour tous les conteneurs. Si vous supprimez ou remplacez ultérieurement un bloc d'adresses IP de conteneur existant, il sera supprimé ou remplacé dans le NSGroup. Tous les conteneurs existants dans le bloc d'adresses IP d'origine ne seront plus associés aux ASG globaux en cours d'exécution. Leur trafic peut ne plus fonctionner.

Solution : ajoutez uniquement les nouveaux blocs d'adresses IP aux « Blocs d'adresses IP des réseaux de conteneurs ».
Problème 2744480 : libre accès au service Kubernetes non pris en charge sur KVM
Si un groupe Kubernetes tente d'accéder à lui-même via un service Kubernetes pour lequel l'espace est un point de terminaison, les paquets de réponse seront abandonnés sur l'hôte KVM.

Solution : aucune
Problème 2744361 : la VM de charge de travail dans OpenShift configurée avec une adresse IP statique peut perdre la connectivité lorsque l'espace nsx-node-agent est terminé
Parfois, une VM de charge de travail dans OpenShift configurée avec une adresse IP statique perd la connectivité lorsque l'espace nsx-node-agent est terminé.

Solution : redémarrez la machine virtuelle.
Problème 2746362 : nsx-kube-proxy ne parvient pas à recevoir les événements de service Kubernetes de Kubernetes apiserver
Parfois, dans un cluster OpenShift, nsx-kube-proxy ne reçoit aucun événement de service Kubernetes de kubernetes apiserver. La commande « nsxcli -c get kube-proxy-watchers » donne la sortie « Watcher thread status: Up », mais « Nombre d'événements traités » est 0, ce qui signifie que nsx-kube-proxy n'a reçu aucun événement d'apiserver.

Solution : redémarrez l'espace nsx-kube-proxy.
Problème 2745907 : les commandes « monit » renvoient des informations d'état incorrectes pour nsx-node-agent
Sur une VM diego_cell, lorsque la surveillance redémarre nsx-node-agent, s'il faut plus de 30 secondes pour que nsx-node-agent démarre entièrement, la surveillance affiche « Échec de l'exécution » pour l'état de nsx-node-agent et ne met pas à jour son état sur « En cours d'exécution », même si nsx-node-agent est entièrement fonctionnel ultérieurement.

Solution : aucune.
Problème 2735244 : incident nsx-node-agent et nsx-kube-proxy en raison d'un échec de la sonde de réactivité
nsx-node-agent et nsx-kube-proxy utilisent sudo pour exécuter certaines commandes. S'il existe de nombreuses entrées dans /etc/resolv.conf sur le serveur DNS et les domaines de recherche, sudo peut prendre beaucoup de temps pour résoudre les noms d'hôte. Cela entraîne le blocage de nsx-node-agent et nsx-kube-proxy par la commande sudo pendant un long moment, et la sonde de réactivité échouera.

Solution : utilisez l'une des deux actions suivantes :
- Ajoutez des entrées de nom d'hôte à /etc/hosts. Par exemple, si le nom d'hôte est « host1 », ajoutez l'entrée « 127.0.0.1 host1 ».
- Définissez une valeur plus élevée pour le délai d'expiration de la sonde de réactivité de nsx-node-agent. Exécutez la commande « kubectl edit ds nsx-node-agent -nsx-system » pour mettre à jour la valeur du délai d'expiration pour les conteneurs nsx-node-agent et nsx-kube-proxy.
Problème 2744557 : modèles d'expression régulière complexes contenant à la fois un groupe de capture () et {0} non pris en charge pour la correspondance de chemin d'accès d'entrée
Par exemple, si le modèle d'expression régulière (regex) est : /foo/bar/(abc){0,1}, il ne correspondra pas à /foo/bar/.

Solution : n'utilisez pas le groupe de capture () et {0} lors de la création d'une règle regex d'entrée. Utilisez le modèle normal EQUALS pour correspondre à /foo/bar/.
Problème 2751080 : après une mise à niveau de l'hôte KVM, les hôtes de conteneur ne peuvent pas exécuter les espaces Kubernetes
Après une mise à niveau de l'hôte KVM, les hôtes de conteneur déployés sur l'hôte mis à niveau ne pourront pas exécuter les espaces Kubernetes. Les espaces resteront dans l'état de création du conteneur. Si NCP Operator est déployé, l'état du nœud peut devenir NotReady et la condition du nœud networkUnavailable est True. Ce problème se voit uniquement avec RHEL et pas avec Ubuntu.

Solution : redémarrez nsx-opsagent sur l'hyperviseur KVM.
Problème 2736412 : le paramètre members_per_small_lbs est ignoré si max_allowed_virtual_servers est défini
Si max_allowed_virtual_servers et members_per_small_lbs sont définis, les serveurs virtuels peuvent ne pas être attachés à un équilibreur de charge disponible, car seul max_allowed_virtual_servers est pris en compte.

Solution : assouplissez les contraintes d'échelle au lieu d'activer la mise à l'échelle automatique.
Problème 2740552 : lors de la suppression d'un espace statique à l'aide d'api-server, nsx-node-agent ne supprime pas le port de pont OVS de l'espace et le réseau de l'espace statique qui est automatiquement recréé par Kubernetes n'est pas disponible
Kubernetes n'autorise pas la suppression d'un espace statique par api-server. Kubernetes crée un espace de mise en miroir d'un espace statique pour qu'api-server puisse rechercher l'espace statique. Lors de la suppression de l'espace par api-server, seul l'espace de mise en miroir sera supprimé et NCP recevra et traitera la demande de suppression pour supprimer toutes les ressources NSX allouées à l'espace. Toutefois, l'espace statique existe toujours et nsx-node-agent n'aura pas la demande de suppression de CNI pour supprimer le port de pont OVS de l'espace statique.

Solution : supprimez l'espace statique en supprimant le fichier manifeste au lieu de le supprimer par api-server.
Problème 2795268 : la connexion entre nsx-node-agent, les basculements hyperbus et l'espace Kubernetes est bloquée à l'état de création.
Dans un environnement à grande échelle, nsx-node-agent peut ne pas se connecter à Kubernetes apiserver pour obtenir des informations sur l'espace. En raison de la grande quantité d'informations transférées, les messages keepalive ne peuvent pas être envoyés à hyperbus et hyperbus fermera la connexion.

Solution : redémarrez nsx-node-agent. Assurez-vous que Kubernetes apiserver est disponible et que le certificat à connecter à apiserver est correct.
Problème 2795482 : un groupe en cours d'exécution est bloqué dans l'état ContainerCreating après le redémarrage du nœud/de l'hyperviseur ou toute autre opération
Si l'indicateur wait_for_security_policy_sync est true, un groupe peut passer à l'état ContainerCreating après avoir été en état d'exécution pendant plus d'une heure en raison du redémarrage matériel d'un nœud worker, du redémarrage de l'hyperviseur ou d'une autre raison. L'espace restera toujours à l'état de création.

Solution : supprimez puis recréez l'espace.
Problème 2871314 : après la mise à niveau de TKGI de la version 1.10.x vers la version 1.11.x (antérieure à la version 1.11.6), les certificats d'entrée pour l'équilibreur de charge NSX sont supprimés.
À partir de NCP 3.1.1, les certificats sont suivis avec un numéro de révision. Cela provoque un problème lors de la mise à niveau de TKGI 1.10.x vers TKGI 1.11.x (antérieur à 1.11.6), ce qui entraîne la suppression et la non-réimportation des certificats d'entrée de l'équilibreur de charge NSX.

Solution : utilisez l'une des méthodes suivantes :
1. redémarrez NCP. Ou,
2. supprimez la clé secrète dans l'environnement Kubernetes et recréez la même clé secrète. Ou,
3. mettez à niveau vers TKGI 1.11.6 ou une version ultérieure.
Problème 2871321 : après la mise à niveau de TKGI de la version 1.10.x vers la version 1.11.x (antérieure à la version 1.11.6), si CRD LoadBalancer utilise la persistance des cookies L7, il perd l'adresse IP.
Ce problème est dû à une nouvelle fonctionnalité de NCP 3.1.1 qui prend en charge la mise à jour du nom du cookie dans l'équilibreur de charge NSX.

Solution : utilisez l'une des méthodes suivantes :
1. Utilisez la persistance de l'adresse IP source au lieu de la persistance des cookies.
2. Mettez à niveau vers TKGI 1.11.6 ou une version ultérieure.
Problème 3033821 : après la migration Gestionnaire vers Stratégie, les règles de pare-feu distribué ne sont pas appliquées correctement
Après une migration Gestionnaire vers Stratégie, les règles de pare-feu distribué (DFW) liées aux stratégies réseau récemment créées auront une priorité plus élevée que les règles DFW migrées.

Solution : utilisez l'API de stratégie pour modifier la séquence de règles DFW si nécessaire.