VMware NSX Container Plugin 3.2.0.1   |   11 novembre 2021   |   Build 18876345

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

NSX Container Plugin (NCP) 3.2.0.1 comprend les nouvelles fonctionnalités suivantes :
Remarque : toutes les nouvelles fonctionnalités sont prises en charge en mode Stratégie uniquement, sauf si la prise en charge du mode Gestionnaire est mentionnée.
  • Prise en charge de l'utilisation du même certificat générique dans Kubernetes Ingress pour plusieurs clusters Kubernetes (plusieurs instances de NCP).
  • Prise en charge de l'installation d'OpenShift avec NCP à l'aide de la méthode IPI (Installer Provisioned Infrastructure), en plus de la méthode UPI (User Provisioned Infrastructure).
  • Nouvelle option de configuration « baseline_policy_type: allow_namespace_strict ». Avec cette option définie, la stratégie par défaut consiste à abandonner toute communication entre les espaces de noms et les services externes, sauf si cela est spécifiquement autorisé par la stratégie réseau Kubernetes ou les stratégies d'administration manuelles NSX-T.
  • Prise en charge du nouveau champ endPort pour les stratégies réseau Kubernetes.
  • Possibilité de spécifier des sous-réseaux pour un espace de noms Kubernetes.
  • Allocation d'adresses IP persistantes StatefulSet basée sur le sous-réseau d'espace de noms.
  • Possibilité de créer l'affinité de session basée sur l'adresse IP du client pour un service Kubernetes de type ClusterIP. Cette fonctionnalité est également disponible en mode Gestionnaire.

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.2
NSX-T 3.1.2, 3.1.3
vSphere 6.7, 7.0
Kubernetes 1.19, 1.20, 1.21, 1.22
OpenShift 4 RHCOS 4.6, 4.7, 4.8
Système d'exploitation de VM sur hôte Kubernetes Ubuntu 18.04, 20.04
CentOS 7.8, 7.9, 8.2
RHEL 8.2, 8.4
Consultez les remarques ci-dessous.
Tanzu Application Service Ops Manager 2.7 + TAS 2.7 (LTS)
Ops Manager 2.10 + TAS 2.10
Ops Manager 2.10 + TAS 2.11
Ops Manager 2.10 + TAS 2.12
Tanzu Kubernetes Grid Integrated (TKGI) 1.13

Remarques :

L'installation du module de noyau nsx-ovs sur CentOS/RHEL nécessite une version de noyau spécifique. Les versions du noyau CentOS/RHEL sont 1127, 1160, 193, 240 et 305, quelle que soit la version de CentOS/RHEL. Notez que la version du noyau par défaut est 1127 pour RHEL 7.8, 1160 pour RHEL 7.9, 193 pour RHEL 8.2, 240 pour RHEL 8.3 et 305 pour RHEL 8.4. Si vous exécutez une version de noyau différente, vous pouvez (1) modifier la version de votre noyau vers une version prise en charge. Lors de la modification de la version du noyau, puis du redémarrage de la machine virtuelle, assurez-vous que les routes IP et statiques sont conservées sur l'interface de liaison montante (spécifiée par ovs_uplink_port) pour garantir que la connectivité au serveur d'API Kubernetes n'est pas perdue. Ou (2), 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.

Pour exécuter le module de noyau nsx-ovs sur RHEL 8.2 (version de noyau 193), vous devez désactiver l'option « Démarrage sécurisé UEFI » sous « Options de démarrage » dans les paramètres de la VM dans vCenter Server.

À partir de NCP 3.1.2, l'image RHEL ne sera pas 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 version précédentes de 3.1.x

 

Problèmes résolus

  • 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

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

  • 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 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 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 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 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 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 2860091 : le trafic DNS échoue si baseline_policy_type est défini sur allow_namespace

    Dans un environnement OpenShift ou Kubernetes, si baseline_policy_type est défini sur allow_namespace, il bloque les espaces (hostNetwork: False) dans d'autres espaces de noms pour empêcher l'accès au service DNS.

    Solution : ajoutez une stratégie réseau de règle pour autoriser le trafic d'autres espaces vers les espaces DNS.

  • Problème 2841030 : avec Kubernetes 1.22, l'état de nsx-node-agent est toujours « AppArmor »

    Avec Kubernetes 1.22, lorsque les espaces nsx-node-agent sont « Prêts», leur état n'est pas mis à jour de « AppArmor » à « En cours d'exécution ». Cela n'a pas d'incidence sur la fonctionnalité de NCP ou de nsx-node-agent.

    Solution : redémarrez les espaces nsx-node-agent.

  • Problème 2824129 : un nœud a l'état network-unavailable égal à true pendant plus de 3 minutes après un redémarrage

    Si vous utilisez NCP Operator pour gérer le cycle de vie de NCP, lorsqu'un daemonset nsx-node-agent récupère d'un état non en cours d'exécution, son nœud aura l'état network-unavailable égal à true jusqu'à ce qu'il ait été exécuté pendant 3 minutes. Il s'agit du comportement attendu.

    Solution : attendez au moins 3 minutes après le redémarrage de nsx-node-agent.

  • Problème 2867361 : les alarmes nsx-node-agent et hyperbus ne sont pas supprimées après le nettoyage de NCP

    Si les alarmes nsx-node-agent et hyperbus s'affichent pour une raison quelconque (telles que l'arrêt de tous les agents de nœud NSX) et que vous arrêtez NCP et exécutez le script de nettoyage, les alarmes resteront après le nettoyage.

    Solution : aucune

  • Problème 2869247 : sur le système d'exploitation hôte Ubuntu 18.04, le conteneur nsx-ovs continue de redémarrer

    Le conteneur nsx-ovs continue de redémarrer, car sa sonde de réactivité continue d'échouer. /var/log/nsx-ujo/openvswitch/ovs-vswitchd.log contient un journal qui indique qu'il continue à redémarrer. Par exemple :

    2021-10-28T17:38:49.364Z|00004|backtrace(monitor)|WARN|Backtrace using libunwind not supported. 
    2021-10-28T17:38:49.364Z|00005|daemon_unix(monitor)|WARN|2 crashes: pid 282 died, killed (Aborted), core dumped, waiting until 10 seconds since last restart 
    2021-10-28T17:38:57.364Z|00006|daemon_unix(monitor)|ERR|2 crashes: pid 282 died, killed (Aborted), core dumped, restarting 

    Ce problème est dû à une incompatibilité entre les modules d'espace utilisateur OVS en amont installés dans le conteneur nsx-ovs et le module de noyau OVS sur l'hôte.

    Solution : mettez à niveau le système d'exploitation hôte vers Ubuntu 20.0 ou effectuez les étapes ci-dessous pour utiliser les modules de noyau OVS fournis par NSX :

    1. Définissez use_nsx_ovs_kernel_module sur True dans le mappage de configuration de nsx-node-agent.
    2. Supprimez les commentaires des montages de volume dans DaemonSet nsx-ncp-bootstrap (recherchez « Annuler le commentaire de ces montages si vous installez le module de noyau NSX-OVS » et « Annuler le commentaire de ces volumes si vous installez le module de noyau NSX-OVS ») dans le fichier ncp-ubuntu*.yaml.
    3. Appliquez à nouveau le fichier ncp-ubuntu*.yaml et redémarrez les espaces nsx-node-agent.
  • Problème 2867871 : l'accès au service clusterIP à partir des espaces auxquels le service fait référence échoue si le nom de nœud Kubernetes des espaces est différent du nom d'hôte

    NCP prend actuellement en charge le libre accès de l'espace au service clusterIP uniquement lorsque le nom du nœud Kubernetes est identique au nom d'hôte. Cela est dû au fait que nsx-kube-proxy ajoute le flux en libre accès uniquement si le nom d'hôte est identique au nom du nœud.

    Solution : aucune

  • Problème 2868572 : Open vSwitch (OVS) doit être désactivé sur la VM hôte avant d'exécuter NCP

    Pour déployer NCP sur une machine virtuelle hôte, vous devez d'abord arrêter les processus liés à OVS et supprimer certains fichiers sur l'hôte à l'aide des commandes suivantes :

    1. sudo systemctl disable openvswitch-switch.service
    2. sudo systemctl stop openvswitch-switch.service
    3. rm -rf /var/run/openvswitch

    Si vous avez déjà déployé NCP sur une machine virtuelle hôte et si OVS ne s'exécute pas correctement, procédez comme suit pour récupérer :

    1. Effectuez les 3 étapes ci-dessus.
    2. Supprimez les espaces nsx-node-agent sur les nœuds présentant le problème de redémarrage des espaces d'agent de nœud à l'aide de la commande « kubectl delete pod $agent-pod -nsx-system ».

    Solution : reportez-vous à la section ci-dessus.

  • Problème 2832480 : pour un service Kubernetes de type ClusterIP, sessionAffinityConfig.clientIP.timeoutSeconds ne peut pas dépasser 65535

    Pour un service Kubernetes de type ClusterIP, si vous définissez sessionAffinityConfig.clientIP.timeoutSeconds sur une valeur supérieure à 65 535, la valeur réelle sera 65 535.

    Solution : aucune

  • Problème 2882699 : dans un environnement IPv6, la définition de baseline_policy_type sur allow_namespace_strict entraîne un échec de communication

    Dans un environnement IPv6, avec baseline_policy_type défini sur allow_namespace_strict, les espaces ne peuvent pas accéder aux nœuds Kubernetes.

    Solution : ajoutez une règle de pare-feu distribué avec une priorité plus élevée que la règle de ligne de base pour autoriser le trafic des espaces vers les nœuds Kubernetes.

check-circle-line exclamation-circle-line close-line
Scroll to top icon