Notes de mise à jour de NSX Container Plugin 3.0.2

VMware NSX Container Plugin 3.0.2 | 10 septembre 2020 | Build 16863080

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 3.0.2 comprend les nouvelles fonctionnalités suivantes :

Prise en charge d'OpenShift 4.4 (avec NSX-T Data Center 3.0.1.1 ou version ultérieure)
Prise en charge de l'authentification du client JWT pour l'entrée (avec NSX-T Data Center 3.0.0 ou version ultérieure)
Prise en charge du service Kubernetes de type LoadBalancer sans sélecteur
Possibilité de spécifier une adresse IP SNAT spécifique par espace de noms et service via une annotation
Nouvelle annotation pour activer le trafic de journalisation pour les règles de pare-feu distribué
Prise en charge de Photon OS
Prise en charge de la stratégie de sécurité de l'espace
Prise en charge de l'attribut pathType pour l'entrée

NSX Container Plugin 3.0.2.2 est une version de correctif. Elle résout un problème de compilation du module de noyau OVS sur Pivotal Stemcells 621.85 et versions ultérieures, 456.121 et versions ultérieures.

Conditions de compatibilité

Produit	Version
Vignette NCP/NSX-T pour Tanzu Application Service (PCF)	3.0.2
NSX-T	2.5.2, 2.5.2.1, 2.5.2.2, 2.5.3, 3.0.0, 3.0.1, 3.0.2, 3.0.3
vSphere	6.7, 7.0
Kubernetes	1.17, 1.18
OpenShift 3	3.11
OpenShift 4	RHCOS 4.3, 4.4
Système d'exploitation de VM sur hôte Kubernetes	Ubuntu 16.04, Ubuntu 18.04, CentOS 7.7, CentOS 7.8, CentOS 8.1, RHEL 7.8, RHEL 8.1 Remarque : pour RHEL/CentOS 7.8, 8.1, nsx-ovs n'est pas pris en charge. Il est uniquement compatible avec l'OVS en amont.
Système d'exploitation de VM sur hôte OpenShift	RHEL 7.7, RHEL 7.8
OpenShift BMC (obsolète dans cette version)
Tanzu Application Service (Pivotal Cloud Foundry)	Ops Manager 2.8 + PAS 2.8 Ops Manager 2.9 + PAS 2.9 Ops Manager 2.10 + PAS 2.10

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

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

Problèmes résolus

Problème 2518312 : Le conteneur de démarrage NCP ne parvient pas à installer le module de noyau nsx-ovs sur Ubuntu 18.04.4, noyau 4.15.0-88
Le conteneur de démarrage NCP (nsx-ncp-bootstrap) ne parvient pas à installer le module de noyau nsx-ovs sur Ubuntu 18.04.4, noyau 4.15.0-88.

N'installez pas NSX-OVS sur ce noyau en définissant use_nsx_ovs_kernel_module = False dans nsx-node-agent-config. Utilisez plutôt le module de noyau OVS en amont (Ubuntu est fourni par défaut avec un module de noyau OVS) sur l'hôte. S'il n'y a aucun module de noyau OVS sur l'hôte, installez-en un manuellement et définissez use_nsx_ovs_kernel_module = False dans nsx-node-agent-config ou rétrogradez la version du noyau à la version 4.15.0-76 pour que NSX-OVS puisse être installé.
Problème 2548815 : dans un cluster NCP importé de Gestionnaire vers Stratégie, NCP ne parvient pas à supprimer un routeur de niveau 1 mis à l'échelle automatiquement
Un routeur de niveau 1 mis à l'échelle automatiquement ne peut pas être supprimé par NCP exécuté en mode Stratégie après l'importation de Gestionnaire vers Stratégie, car il est toujours référencé par son LocaleService.

Solution : supprimez manuellement le routeur de niveau 1 à l'aide de l'interface utilisateur de NSX Manager.
Problème 2549433 : le nœud OpenShift utilisant une interface unique configurée en tant qu'ovs_uplink_port perd les informations du serveur de noms lorsque le bail DHCP expire
Un nœud OpenShift avec une interface unique, configuré en tant qu'ovs_uplink_port dans la configuration de l'agent nsx-node, perd les informations du serveur de noms lorsque le bail DHCP d'ovs_uplink_port expire.

Solution : utilisez une adresse IP statique.
Problème 2550625 : après la migration d'un cluster de Gestionnaire vers Stratégie, les adresses IP dans un pool d'adresses IP partagé ne sont pas publiées
Après la migration d'un cluster de Gestionnaire vers Stratégie, la suppression d'un espace de noms ne libère pas les adresses IP qui ont été allouées à cet espace de noms.

Solution : aucune.
Problème 2549765 : l'importation d'objets de Gestionnaire vers Stratégie échoue si une règle NAT comporte plusieurs ports de destination
Le processus d'importation de Gestionnaire vers Stratégie échouera s'il existe une règle NAT avec plusieurs ports de destination sur le routeur de niveau supérieur. Un tel scénario se produit lorsque le paramètre Kubernetes ingress_mode est « nat » dans la configuration NCP et qu'il existe un espace avec l'annotation « ncp/ingress-controller » dans Kubernetes.

Solution : tant que NCP n'est pas en cours d'exécution et avant de lancer l'importation, modifiez la règle NAT et supprimez les ports de destination « 80 » et « 443 ».
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.
NCP échoue au démarrage lorsqu'aucun bloc d'adresses IP de conteneur n'est configuré
Pour les déploiements entièrement routés avec uniquement « aucun bloc d'adresses IP SNAT » configuré, mais pas « bloc d'adresses IP de conteneur » configuré, NCP 3.0.1 échoue au démarrage avec « IndexError : index de liste hors de la plage ».

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 PAS director config, le serveur DNS Bosh (169.254.0.2) figure toujours dans le fichier resolve.conf du conteneur.
Dans un environnement PAS exécutant PAS 2.2, après que vous désactivez « BOSH DNS server » dans PAS director config, le serveur DNS Bosh (169.254.0.2) figure toujours dans le fichier resove.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 PAS 2.1.

Solution : aucune. Il s'agit d'un problème PAS.
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 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 2416376 : NCP ne parvient pas à traiter un PAS ASG (groupe de sécurité d'application) 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 PAS ASG 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 PKS, 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 est indiqué comme Inconnu. Ce problème est dû au fait que PKS 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 2552918 : échec de la restauration de l'importation de Gestionnaire vers Stratégie pour le pare-feu distribué, ce qui entraîne l'échec de la restauration du cluster
Dans de rares cas, le processus d'importation de Gestionnaire vers Stratégie doit effectuer une restauration, ce qui n'aboutit pas pour les sections et les règles de pare-feu distribué. Cela entraîne l'échec de la restauration du cluster et laisse des ressources obsolètes dans NSX Manager.

Solution : utilisez la fonctionnalité de sauvegarde et de restauration pour restaurer NSX Manager dans un état sain.
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 PKS 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 PKS.

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