Notes de mise à jour de NSX Container Plugin 3.0.1

VMware NSX Container Plugin 3.0.1 | 30 avril 2020 | Build 16118386

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

Prise en charge de la connectivité IPAM et L3, de l'adresse IP du cluster de services et de l'équilibrage de charge dans les clusters Kubernetes IPv6
Prise en charge de plusieurs interfaces par espace (fonctionnalité de type Multus)
Prise en charge d'OpenShift Container Platform (OCP) 4
Exposer les options de journalisation de la règle DFW dans NCP configmap
Exposer les paramètres du routeur de niveau 1 dans NCP configmap
Exposer les paramètres de profil HTTP d'équilibreur de charge pour le dimensionnement et les délais d'expiration d'en-tête dans NCP configmap
Ajouter la prise en charge de CRD d'équilibreur de charge dans l'API de stratégie
Prise en charge du port x-forwarded
Relais SSL (commutation d'hôte basé sur SNI) et rechiffrement
Amélioration des rapports d'erreurs pour le contrôleur de stratégie réseau
Prise en charge de l'importation d'objets de gestionnaire dans la stratégie
Prise en charge de la multidiffusion de couche 3 pour les charges de travail de conteneur (topologie de niveau 0 partagée à un seul niveau uniquement)
Fichier YAML dédié pour les déploiements NCP en mode Stratégie

Conditions de compatibilité

Produit	Version
Vignette NCP/NSX-T pour Tanzu Application Service (PCF)	3.0.1
NSX-T	2.5.0, 2.5.1, 2.5.2, 2.5.2.2, 2.5.3, 3.0.0, 3.0.1
vSphere	6.7, 7.0
Kubernetes	1.17, 1.18
OpenShift 3	3.11
OpenShift 4	RHCOS 4.3
Système d'exploitation de VM sur hôte Kubernetes	Ubuntu 16.04, Ubuntu 18.04, CentOS 7.7, RHEL 7.7, RHEL 7.8 Remarque : pour RHEL 7.8, 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.6, RHEL 7.7
OpenShift BMC (sera obsolète dans une version ultérieure)	RHEL 7.6, RHEL 7.7
Tanzu Application Service (Pivotal Cloud Foundry)	Ops Manager 2.6 + PAS 2.6 Ops Manager 2.8 + PAS 2.8 Ops Manager 2.9 + PAS 2.9

Avis d’obsolescence : VMware envisage de déconseiller la prise en charge d'OpenShift bare metal dans une version ultérieure.

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

NCP 3.0 et toutes les version de NCP 2.5.x

Problèmes résolus

Problème 2330811 : lors de la création de services Kubernetes de type LoadBalancer alors que NCP est inactif, les services peuvent ne pas être créés lors du redémarrage de NCP
Lorsque des ressources NSX-T sont épuisées pour les services Kubernetes de type LoadBalancer, vous pouvez créer des services après la suppression de certains services existants. Toutefois, si vous supprimez et créez les services alors que NCP est inactif, NCP ne parvient pas à créer les services.

Solution : lorsque des ressources NSX-T sont épuisées pour les services Kubernetes de type LoadBalancer, n'effectuez pas les opérations de suppression et de création lorsque NCP est inactif.
Problème 2408100 : dans un cluster Kubernetes de grande taille avec plusieurs instances de NCP en mode actif-en veille ou une sonde de réactivité activée, NCP redémarre fréquemment
Dans un cluster Kubernetes de grande taille (environ 25 000 espaces, 2 500 espaces de noms et 2 500 stratégies réseau), si plusieurs instances de NCP s'exécutent en mode actif-en veille ou si la sonde de réactivité est activée, les processus NCP peuvent être arrêtés et redémarrés fréquemment en raison d'une erreur « Acquisition de verrou en conflit » ou d'un échec de la sonde de réactivité.

Solution : suivez les étapes décrites ci-dessous :
1. définissez le nombre de replicas du déploiement NCP sur 1 ou augmentez l'option de configuration ha.master_timeout dans ncp.ini de la valeur par défaut 18 à 30.
2. Augmentez les arguments de la sonde de réactivité comme suit :
```
  containers:
    - name: nsx-ncp
      livenessProbe:
        exec :
          commande :
            - /bin/sh
            - -c
            - timeout 20 check_pod_liveness nsx-ncp
        initialDelaySeconds: 20
        timeoutSeconds: 20
        periodSeconds: 20
        failureThreshold: 5
```
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è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 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 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 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 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 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 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 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 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 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 PKS et dans nsx-ncp-configmap pour les autres. Puis redémarrez NCP.
Problème 2593017 : ports de routeur logique périmés non supprimés sur NSX-T
Dans une topologie à deux niveaux avec l'API de gestionnaire, les ports de routeur logique périmés ne sont parfois pas supprimés. Lorsqu'un grand nombre de ports de routeur périmés sont présents, le comportement du routeur peut être affecté.

Solution : dans NSX Manager, supprimez manuellement les ports de routeur périmés.
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.