Notes de mise à jour de VMware NSX Container Plugin 3.2.1.1

VMware NSX Container Plugin 3.2.1.1 \| 17 mai 2022 \| Build 19750154 Vérifiez les compléments et les mises à jour de ces notes de mise à jour.

VMware NSX Container Plugin 3.2.1.1 | 17 mai 2022 | Build 19750154

Vérifiez les compléments et les mises à jour de ces notes de mise à jour.

Nouveautés

Prise en charge du déploiement de nœuds worker OCP avec plusieurs vNIC

Le déploiement de nœuds worker OCP avec plusieurs vNIC est pris en charge, en partant du principe que la première vNIC est utilisée pour la mise en réseau du conteneur.
Prise en charge de l'option « natfirewallmatch »

L'option « natfirewallmatch » spécifie le comportement du pare-feu de passerelle NSX-T avec les règles NAT créées pour un espace de noms Kubernetes. Cette option s'applique uniquement aux espaces de noms Kubernetes récemment créés et non aux espaces de noms existants.

Avis d'obsolescence

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

La fonctionnalité qui autorise l'accès via NAT aux espaces du contrôleur d'entrée à l'aide de l'annotation ncp/ingress_controller est obsolète et sera supprimée en 2023. La manière recommandée d'exposer des espaces de contrôleur d'entrée consiste à utiliser des services de type LoadBalancer.

Conditions de compatibilité

Produit	Version
Vignette NCP/NSX-T pour Tanzu Application Service (TAS)	3.2.1
NSX-T	3.1.3, 3.2, 3.2.1 (voir les notes ci-dessous)
vSphere	6.7, 7.0
Kubernetes	1.21, 1.22, 1.23
OpenShift 4	4.7, 4.8, 4.9
Système d'exploitation de machine virtuelle sur hôte OpenShift	RHCOS 4.7, 4.8
Système d'exploitation de VM sur hôte Kubernetes	Ubuntu 18.04, 20.04 CentOS 8.2 RHEL 8.4, 8.5 Consultez les remarques ci-dessous.
Tanzu Application Service	Ops Manager 2.7 + TAS 2.7 (LTS) Ops Manager 2.10 + TAS 2.11 Ops Manager 2.10 + TAS 2.12
Tanzu Kubernetes Grid Integrated (TKGI)	1.13.6, 1.14

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 193, 305 et 348, quelle que soit la version de CentOS/RHEL. Notez que la version du noyau par défaut est 193 pour RHEL 8.2, 305 pour RHEL 8.4 et 348 pour RHEL 8.5. 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), ignorez 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/CentOS, 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.

TKGI 1.14.0 fourni avec NCP 3.2.1.0, qui ne prend pas en charge NSX-T 3.2.1.

TKGI 1.13.x et TKGI 1.14.x ne sont pas compatibles avec NSX-T 3.2.0.x.

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

Toutes les version de 3.1.x
Toutes les version précédentes de 3.2.x

Limitations

La fonctionnalité « stratégie de ligne de base » pour NCP crée un groupe dynamique qui sélectionne tous les membres du cluster. NSX-T dispose d'une limite de 8 000 membres effectifs d'un groupe dynamique (pour plus de détails, reportez-vous à la section Valeurs maximales de configuration). Par conséquent, cette fonctionnalité ne doit pas être activée pour les clusters qui sont censés croître au-delà de 8 000 espaces. Le dépassement de cette limite peut entraîner des retards dans la création de ressources pour les espaces.

Problèmes résolus

Problème 3042916 : nsx-kube-proxy échoue après le démarrage avec l'erreur « port non valide ou inconnu pour in_port »

En de rares occasions, nsx-kube-proxy échoue peu après le démarrage, car la liaison montante OVS « ofport » est vide à ce stade. Le journal contient le message d'erreur « RuntimeError: erreur fatale lors de l'exécution de xxx : () : port non valide ou inconnu pour in_port. »

Solution : redémarrez nsx-kube-proxy.
Problème 2863155 : certains services IP de cluster ne sont pas accessibles à partir d'espaces dans un environnement à grande échelle

Dans un environnement à grande échelle, la taille volumineuse du journal peut entraîner des problèmes avec nsx-kube-proxy. Certains services IP de cluster ne seront pas accessibles à partir des espaces, et nsx-kube-proxy ne peut pas signaler son état dans nsxcli.

Solution : redémarrez nsx-kube-proxy.
Problème 2944368 : une règle d'entrée avec « hôte » spécifié correspond à la fois à l'hôte et à l'hôte avec un suffixe

Par exemple, une règle qui spécifie que l'hôte est « test.co » correspondra à la fois à « test.co » et à « test.co.uk ».

Solution : Aucun
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.
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 : Aucun
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 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èmes connus

Problème 3239352 : Dans un environnement TAS, lorsqu'une tâche ne peut pas être allouée, la nouvelle tentative peut ne pas fonctionner

Dans un environnement TAS NCP, lorsqu'une tâche ne peut pas être allouée, Auctioneer rejette la tâche et le BBS réessaie de placer la tâche jusqu'au nombre de fois spécifié par le paramètre task.max_retries. Lorsque le paramètre task.max_retries est atteint, le BBS met à jour la tâche de l'état EN ATTENTE vers l'état TERMINÉ, en la marquant comme En échec et en incluant une FailureReason qui explique que le cluster ne dispose d'aucune capacité pour la tâche.

Lors de la nouvelle tentative, la tâche peut être planifiée sur une nouvelle cellule qui notifie NCP avec un événement task_changed. Étant donné que NCP ne gère pas l'événement task_changed, un nouveau port ne peut pas être attribué à la tâche dans la nouvelle cellule. La tâche ne peut pas s'exécuter correctement.

Solution : Désactivez la nouvelle tentative et définissez la valeur task.max_retries sur 0.
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.
Problème 2960121 : pour les services de type LoadBalancer, la connectivité aux espaces sur les nœuds worker Windows échoue s'ils ne sont pas configurés correctement

Pour les services de type LoadBalancer, la connectivité aux espaces sur les nœuds worker Windows échouera si NCP est configuré pour utiliser le sous-réseau de segment d'équilibreur de charge par défaut. Le sous-réseau par défaut 169.254.128.0/22 appartient à l'espace local de liaison IPv4 et n'est pas transféré sur un nœud Windows.

Solution : configurez NCP pour utiliser un sous-réseau de segment d'équilibreur de charge non défini par défaut. Pour ce faire, définissez le paramètre lb_segment_subnet dans la section nsx_v3. Notez que cela n'aura d'effet que sur les équilibreurs de charge NSX récemment créés.
Problème 2972811 : dans un environnement à grande échelle, la connexion hyperbus à certains nœuds worker est inactive
Dans un environnement à grande échelle, la création d'un espace peut être bloquée pendant 10 à 15 minutes en raison du délai d'expiration du canal RPC. Les problèmes suivants peuvent se produire :
- Dans un cluster Kubernetes, certains espaces auront l'état ContainerCreating pendant 10 à 15 minutes.
- Dans cfgAgent, le tunnel aura l'état COMMUNICATION_ERROR pendant 10 à 15 minutes.
- Dans l'interface utilisateur de NSX, une alarme peut être générée et indiquer que la connexion hyperbus est inactive.
Solution : aucune requise. Ce problème disparaîtra automatiquement après 10 à 15 minutes.
Problème : 2966586 : après la migration des objets du gestionnaire vers la stratégie, la création de l'espace de noms échoue

Si un bloc d'adresses IP est créé en mode Gestionnaire, après la migration des objets de gestionnaire vers la stratégie, la création de l'espace de noms échoue, car NCP ne peut pas allouer de sous-réseaux à partir de ce bloc d'adresses IP.

Solution : créez des blocs d'adresses IP en mode Stratégie et configurez NCP pour utiliser ces nouveaux blocs d'adresses IP.
Problème : 2961789 : après la migration des objets de gestionnaire vers la stratégie, certaines ressources associées de l'espace de contrôle de santé ne peuvent pas être supprimées

Après la migration des objets de gestionnaire vers la stratégie, lorsque vous supprimez l'espace de contrôle de santé, le port de segment associé de l'espace et le groupe cible de la règle de pare-feu distribué ne sont pas supprimés.

Solution : supprimez manuellement ces ressources.
Problème 2923436 : un nom de ressource Kubernetes long entraîne un échec
Si un nom de ressource Kubernetes est trop long, la ressource NSX correspondante ne peut pas être créée, car le nom de la ressource NSX dépassera les limites des noms d'affichage dans NSX. Le journal affiche un message d'erreur tel que « Erreurs de validation au niveau du champ : {display_name ipp-k8scl-two-aaaaaa... a dépassé sa longueur maximale valide de 255 caractères} ». NSX présente les limites suivantes :
- nom complet du segment : 80 caractères
- nom de groupe + nom de domaine : 245 caractères
- nom d'affichage des autres ressources NSX : 255 caractères
Solution : raccourcissez le nom de la ressource Kubernetes.
Problème 2939886 : échec de la migration d'objets du mode Gestionnaire vers le mode Stratégie

La migration d'objets du mode Gestionnaire vers le mode Stratégie échoue si, dans la spécification de la stratégie réseau, la sortie et l'entrée ont le même sélecteur.

Solution : Aucun
Problème 2936436 : l'interface utilisateur de NSX Manager n'affiche pas la version de NCP sur la page du cluster de conteneurs

Lorsque l'interface utilisateur de NSX Manager affiche les clusters de conteneurs dans l'onglet Inventaire, la version de NCP ne s'affiche pas.

Solution : la version de NCP est disponible en appelant l'API /policy/api/v1/fabric/container-clusters.
Problème 2934195 : certains types de groupes NSX ne sont pas pris en charge pour les règles de pare-feu distribué

Les groupes NSX de type « Adresses IP uniquement » ne sont pas pris en charge pour les règles de pare-feu distribué (DFW). Un groupe NSX de type « Générique » avec des adresses IP ajoutées manuellement en tant que membres n'est pas non plus pris en charge.

Solution : Aucun
Problème : 2940772 : la migration des ressources NCP de Gestionnaire vers Stratégie entraîne un échec avec NSX-T 3.2.0

La migration des ressources NCP de Gestionnaire vers Stratégie est prise en charge avec NSX-T 3.1.3 et NSX-T 3.2.1, mais pas avec NSX-T 3.2.0.

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