Notes de mise à jour de NSX Container Plugin 3.0.0

VMware NSX Container Plugin 3.0.0 | 7 avril 2020 | Build 15841604

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.0.0 est destiné aux clients de vSphere with Kubernetes uniquement. Pour toutes les autres distributions Kubernetes, RedHat et Pivotal, attendez la sortie de NSX Container Plugin 3.0.1.

NSX Container Plugin 3.0.0 comprend les nouvelles fonctionnalités suivantes :

Prise en charge de l’assouplissement de la limite d'échelle sur le service d'équilibreur de charge. Pour l'API de stratégie, prise en charge de la limite de membres de pool par service d'équilibreur de charge pour les services Kubernetes LoadBalancer.
Prise en charge de l'ajout à une liste blanche d'adresses IP sources pour les services Kubernetes LoadBalancer et l’entrée pour l'API de stratégie.

Conditions de compatibilité

Produit	Version
NSX-T	3.0.0
vSphere with Kubernetes	7.0

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

Toutes les versions de NCP 2.5.x

Problèmes résolus

Problème 2370137 : les conteneurs nsx-ovs et nsx-node-agent ne parviennent pas à s'exécuter, car les fichiers de base de données OVS ne se trouvent pas dans /etc/openvswitch
Lorsque les conteneurs nsx-ovs et nsx-node-agent démarrent, ils recherchent les fichiers de base de données OVS dans /etc/openvswitch. S'il existe des liens symboliques dans le répertoire lié aux fichiers OVS réels (par exemple, conf.db), les conteneurs nsx-ovs et nsx-node-agent ne s'exécuteront pas.
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è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 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 2397438 : après un redémarrage, NCP signale une erreur MultipleObjects
Avant le redémarrage, NCP n'a pas pu créer des sections de pare-feu distribué en raison d'une erreur ServerOverload. NCP a réessayé jusqu'à ce que le nombre maximal de tentatives soit atteint. Cependant, les sections de pare-feu ont toujours été créées. Lorsque NCP a été redémarré, il a reçu des sections de pare-feu dupliquées et signale l'erreur MultipleObjects.

Solution : supprimez manuellement les sections de pare-feu distribué obsolètes et en double, puis redémarrez NCP.
Problème 2397684 : NCP a trouvé la zone de transport correcte, mais a échoué avec l'erreur « Transport par défaut : la zone n'est pas configurée »
Lorsque vous créez des espaces de noms Kubernetes avec NCP basé sur l'API de stratégie, la création d'un infra segment peut échouer en raison de la présence de plusieurs zones de transport de superposition dans NSX-T. Ce problème se produit si aucune des zones de transport de superposition n'est marquée comme étant par défaut.

Solution : mettez à jour la zone de transport de superposition, configurée dans NCP ConfigMap, puis définissez le champ « is_default » sur « true ».
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
L'installation d'OpenShift attend que l'état d'un nœud soit prêt et c'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 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 2412421 : Docker ne parvient pas à redémarrer un conteneur
Si (1) ConfigMap est mis à jour, (2) le conteneur utilise le sous-chemin pour monter ConfigMap et (3) le conteneur est redémarré, Docker ne parvient pas à démarrer le conteneur.

Solution : supprimez l'espace afin que le DaemonSet recrée l'espace.
Problème 2413383 : la mise à niveau d'OpenShift é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 2410909 : après un redémarrage, NCP peut prendre beaucoup de temps pour initialiser son cache dans un environnement à grande échelle (en particulier s'il existe de nombreuses stratégies réseau) et peut prendre environ une demi-heure pour apparaître et traiter les nouveaux espaces et ressources
Après un redémarrage, NCP peut prendre beaucoup de temps pour apparaître. Le traitement des ressources, telles que les espaces, les espaces de noms et les stratégies réseau, peut prendre un laps de temps supplémentaire en fonction de la quantité de ressources impliquées.

Solution : aucune
Problème 2447127 : lors de la mise à niveau de NCP depuis la version 2.4.1 vers la version 2.5.0 ou 2.5.1, un délai supplémentaire peut être nécessaire avant que NCP ne soit opérationnel
Lors de la mise à niveau de NCP depuis la version 2.4.1 vers la version 2.5.x, NSX-T 2.4.1 peut rencontrer un problème de réponse lente lorsque NCP appelle l'API de profil de commutation pour l'élection du leader. De ce fait, il faut plusieurs minutes avant que NCP ne soit opérationnel.

Solution : aucune.
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 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 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.