Notes de mise à jour de VMware NSX Container Plugin 4.1.1

VMware NSX Container Plugin 4.1.1 \| 17 août 2023 \| Build 22071564 Vérifiez les compléments et les mises à jour de ces notes de mise à jour.

VMware NSX Container Plugin 4.1.1 | 17 août 2023 | Build 22071564

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

Nouveautés

À partir de cette version, les nouveaux déploiements TAS ne sont autorisés qu'avec la stratégie NSX. Pour les fondations existantes, les paramètres NCP ne seront pas modifiés lors des mises à niveau.
Les ressources NSX créées par TKGi pour le réseau de déploiement sont désormais migrées vers la stratégie lors de la migration de MP vers la stratégie.
NCP prend en charge jusqu'à 500 routes OCP sur un serveur virtuel d'équilibreur de charge NSX donné.
Vous pouvez sauvegarder NSX et le restaurer ultérieurement à un état précédent. NCP s'assure que l'état des ressources dans un cluster OpenShift et NSX est cohérent.
L'opérateur OpenShift peut simplifier le déploiement de NCP en automatisant certaines configurations d'options. La validation des options entrées à partir du configmap a également été améliorée.

Avis d'obsolescence

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.

Le module de noyau nsx-ovs est obsolète. Seul le module de noyau OVS en amont est pris en charge (il s'agit du comportement par défaut). L'option configmap « use_nsx_ovs_kernel_module » sous la section « nsx_node_agent » du configmap nsx-node-agent a été supprimée.

Conditions de compatibilité

Produit	Version
Vignette NCP/NSX pour Tanzu Application Service (TAS)	4.1.1
NSX	3.2.2, 3.2.3, 4.0.1.1, 4.1.0, 4.1.1
Kubernetes	1.24, 1.25, 1.26
OpenShift 4	4.10, 4.11, 4.12
Système d'exploitation de VM sur hôte Kubernetes	Ubuntu 20.04 Ubuntu 22.04 avec le noyau 5.15 (le module de noyau nsx-ovs et le module de noyau OVS en amont sont pris en charge) Ubuntu 22.04 avec un noyau ultérieur à la version 5.15 (seul le module de noyau OVS en amont est pris en charge) RHEL : 8.4, 8.5, 8.6 Consultez les remarques ci-dessous.
Tanzu Application Service (TAS)	Ops Manager 2.10 + TAS 2.13 Ops Manager 3.0 + TAS 2.13 Ops Manager 2.10 + TAS 3.0 Ops Manager 3.0 + TAS 3.0 Ops Manager 2.10 + TAS 4.0 Ops Manager 3.0 + TAS 4.0
Tanzu Kubernetes Grid Integrated (TKGI)	1.17

Remarques :

Pour toutes les intégrations prises en charge, utilisez l'image de base universelle Red Hat. Pour plus d'informations, reportez-vous à https://www.redhat.com/fr/blog/introducing-red-hat-universal-base-image.

Pour un nouveau déploiement sur TAS, seul le mode Stratégie est pris en charge.

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

4.1.0. 4.1.1 et toutes les versions 4.0.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.
Équilibrage de charge en mode transparent
- Seul le trafic nord-sud d'un cluster Kubernetes est pris en charge. Le trafic à l'intérieur d'un cluster n'est pas pris en charge.
- Non pris en charge pour les services attachés à une CRD LoadBalancer ou lorsque la mise à l'échelle automatique est activée. La mise à l'échelle automatique doit être désactivée pour que cette fonctionnalité soit opérationnelle.
- Il est recommandé d'utiliser cette fonctionnalité uniquement sur les clusters récemment déployés.
Migration Gestionnaire vers Stratégie
- Il n'est pas possible de migrer un cluster Kubernetes si une migration précédente a échoué et que le cluster est restauré. Il s'agit d'une limitation avec NSX 4.0.0.1 ou versions antérieures uniquement.
Il existe un risque de dégradation significative des performances dans le calcul des membres de groupe réels, avec une incidence sur le trafic réseau, lors de l'implémentation de stratégies réseau qui utilisent des critères à plusieurs sélecteurs dans les règles d'entrée/sortie. Pour résoudre cette limitation, une nouvelle option de configuration, enable_mixed_expression_groups, affecte les stratégies réseau Kubernetes utilisant plusieurs sélecteurs en mode stratégie. Les clusters en mode gestionnaire ne sont pas affectés. La valeur par défaut de cette option est False. Nous vous recommandons les valeurs suivantes dans votre cluster :
- TKGi
  - Nouveaux clusters, mode stratégie : False
  - Clusters existants (basés sur la stratégie) : True
  - Après la migration du gestionnaire vers la stratégie : True
- OC : Définir sur True pour garantir la conformité de la stratégie réseau Kubernetes
- DIY Kubernetes
  - Nouveaux clusters (basés sur la stratégie) : False
  - Clusters existants (basés sur la stratégie) : True
  - Après la migration du gestionnaire vers la stratégie : True
Cette limitation s'applique lorsque enable_mixed_expression_groups est défini sur True. Cela affecte les installations qui utilisent NCP 3.2.0 et versions ultérieures, et NSX-T 3.2.0 et versions ultérieures. Le nombre d'espaces de noms affectés par la stratégie réseau n'est pas limité. Si cette option est définie sur True et que NCP est redémarré, NCP resynchronise toutes les stratégies réseau pour implémenter ce comportement.

Lorsque enable_mixed_expression_groups est défini sur False, les stratégies réseau qui utilisent des critères à plusieurs sélecteurs dans les règles d'entrée/sortie sont réalisées avec des groupes NSX dynamiques qui ne sont affectés par aucune dégradation des performances lors du calcul des membres réels. Cependant, les règles ne peuvent être appliquées que sur 5 espaces de noms au maximum, en fonction des autres critères définis dans la stratégie réseau. Si la stratégie réseau affecte plus de 5 espaces de noms à un moment donné, elle est annotée avec « ncp/error: NETWORK_POLICY_VALIDATION_FAILED » et n'est pas appliquée dans NSX. Notez que cela peut se produire lorsque vous créez un espace de noms qui répond aux conditions de plusieurs sélecteurs ou lors de la mise à jour d'un espace de noms existant. Si cette option est définie sur False et que NCP est redémarré, NCP resynchronise toutes les stratégies réseau pour implémenter ce comportement.

Problèmes résolus

Problème 3049209 : après la migration du gestionnaire vers la stratégie, la suppression de clusters ne supprime pas la ressource mp_default_LR_xxx_user_rules

Après l'exécution d'une migration de gestionnaire vers stratégie, puis la suppression de clusters, certaines ressources « GatewayPolicy » nommées mp_default_LR_xxxx_user_rules risquent de ne pas être supprimées.

Solution : supprimez les ressources manuellement.
Problème 3113985 : lors de la migration d'une topologie à un seul niveau 1, toutes les routes statiques ne sont pas migrées

Dans une topologie à un seul niveau 1 avec plusieurs ressources personnalisées de type loadbalancers.vmware.com, certaines routes statiques créées par NCP en mode Gestionnaire pour les équilibreurs de charge ne sont pas migrées.

Solution : après la suppression de la ressource personnalisée de type loadbalancers.vmware.com de Kubernetes, supprimez manuellement la route statique avec l'API de gestionnaire. La route statique aura l'UID de la ressource personnalisée dans ses balises avec l'étendue « ncp/crd_lb_uid ».
Problème 3055618 : lors de la création simultanée de plusieurs espaces Windows sur un nœud, certains espaces n'ont pas d'adaptateur réseau.

Lors de l'application d'un fichier YAML pour créer plusieurs espaces Windows sur le même nœud, certains espaces n'ont pas d'adaptateur réseau.

Solution : redémarrez les espaces.
Problème 3088138 : après la définition de log_file dans le configmap nsx-node-agent-config, les espaces nsx-node-agent ne parviennent pas à démarrer.

Si vous définissez l'option log_file dans le configmap nsx-node-agent-config et redémarrez les espaces nsx-ncp-bootstrap avant les espaces nsx-node-agent, les espaces nsx-node-agent ne parviennent pas à démarrer et sont dans l'état CrashLoopBackOff.

Solution : redémarrez les espaces nsx-node-agent avant de redémarrer les espaces nsx-ncp-bootstrap après avoir défini l'option log_file dans le configmap nsx-node-agent-config.
Problème 3091318 : la création de l'espace échoue après la mise à jour du sous-réseau statique d'un espace de noms lorsque NCP est inactif.

Si vous créez un espace de noms avec NCP ou des sous-réseaux définis, par exemple, sur 172.70.0.0/29, et qu'aucun espace n'a encore été créé dans l'espace de noms, lorsque vous arrêtez NCP et mettez à jour NCP ou les sous-réseaux sur, par exemple, 172.71.0.0/29, la création d'un espace dans l'espace de noms peut échouer après le redémarrage de NCP et l'espace est bloqué à l'état « ContainerCreating ».

Solution : recréez l'espace.
Problème 3110833 : les espaces sur le nœud worker Windows TKGI ne peuvent pas démarrer, car l'état est « ContainerCreating »

Chaque nœud sur le nœud worker Windows ne parvient pas à démarrer. Le journal nsx-node-agent sur le nœud signale continuellement « Failed to process cif config request with error [...]. Restart node agent service to recover. »

Solution : redémarrez le service nsx-node-agent sur le nœud.

Problèmes connus

Problème 3306543 : après la suppression d'un espace, un nouvel espace créé avec le même nom a une configuration de mise en réseau incorrecte

En de rares occasions, si vous supprimez un espace et en créez un autre avec le même nom, le nouvel espace aura la configuration réseau de l'ancien espace. La configuration réseau du nouvel espace sera incorrecte.

Solution : supprimez le nouvel espace, redémarrez nsx-node-agent, puis recréez l'espace.
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 3252571 : la migration du gestionnaire vers la stratégie ne se termine jamais si NSX Manager devient indisponible

Si NSX Manager devient indisponible lors de la migration du gestionnaire vers la stratégie, la migration peut ne jamais se terminer. Une indication est que les journaux ne disposent d'aucune mise à jour sur la migration.

Solution : rétablissez la connexion à NSX Manager et redémarrez la migration.
Problème 3248662 : le nœud worker ne parvient pas à accéder à un service. Le flux OVS du service n'est pas créé sur le nœud.

Le journal nsx-kube-proxy contient le message d'erreur « greenlet.error: cannot switch to a different thread. »

Solution : redémarrez nsx-kube-proxy sur le nœud.
Problème 3241693 : il faut plus de 10 minutes avant que les routes de couche 7 ne commencent à fonctionner lorsque le nombre de routes créées dépasse certaines limites

Dans un environnement OpenShift, vous pouvez déployer plus de 1 000 routes en définissant les indicateurs « relax_scale_validation » sur True et « l4_lb_auto_scaling » sur False dans le ConfigMap. Toutefois, il faut plus de 10 minutes avant que les routes ne commencent à fonctionner lorsque le nombre de routes créées dépasse la limite. Les limites sont de 500 routes HTTPS et de 2 000 routes HTTP.

Solution : ne dépassez pas les limites liées au nombre de routes. Si vous créez 500 routes HTTPS plus 2 000 routes HTTP, vous devez déployer les routes à l'aide d'une machine virtuelle Edge de grande taille.
Problème 3158230 : l'initialisation du conteneur nsx-ncp-bootstrap échoue lors du chargement des profils AppArmor sur Ubuntu 20.04

Le conteneur nsx-ncp-bootstrap dans le DaemonSet nsx-ncp-bootstrap ne parvient pas à s'initialiser en raison de versions différentes du module AppArmor sur le système d'exploitation hôte et l'image du conteneur. Les journaux du conteneur affichent des messages tels que « Failed to load policy-features from '/etc/apparmor.d/abi/2.13': No such file or directory. »

Solution : mettez à jour AppArmor vers la version 2.13.3-7ubuntu5.2 ou la dernière version disponible à partir de focal-updates sur le système d'exploitation hôte.
Problème 3179549 : la modification du mode NAT pour un espace de noms existant n'est pas prise en charge

Dans le cas d'un espace de noms avec des espaces existants, si le mode NAT passe de SNAT à NO_SNAT, les espaces utilisent toujours les adresses IP allouées à partir des blocs d'adresses IP spécifiés dans container_ip_blocks. Si des adresses IP sont encore disponibles dans le sous-réseau de segment, les espaces récemment créés utilisent toujours les adresses IP du sous-réseau de segment existant. Pour un segment récemment créé, le sous-réseau est alloué à partir de no_snat_ip_block. Mais sur l'espace de noms, la règle SNAT est supprimée.

Solution : aucune.
Problème 3218243 : la stratégie de sécurité dans NSX créée pour la stratégie réseau Kubernetes qui utilise des critères à plusieurs sélecteurs est supprimée après la mise à niveau de NCP vers la version 4.1.1 ou lorsque l'utilisateur crée/met à jour un espace de noms

Vérifiez que l'option « enable_mixed_expression_groups » est définie sur False dans NCP (la valeur par défaut est False). Si c'est le cas, la stratégie réseau conduit à la création de plus de 5 critères de groupe sur NSX, ce qui n'est pas pris en charge.

Solution : définissez enable_mixed_expression_groups sur True dans le mappage de configuration NCP et redémarrez NCP. Notez qu'il existe un risque de dégradation significative des performances dans le calcul des membres de groupe réels, avec une incidence sur le trafic réseau dans ce cas.
Problème 3235394 : la stratégie de ligne de base avec le paramètre d'espace de noms ne fonctionne pas dans une configuration TKGI

Dans un environnement TGKI, si vous définissez baseline_policy_type sur allow_namespace ou allow_namespace_strict, NCP crée une stratégie de ligne de base explicite qui autorise uniquement les espaces du même espace de noms à communiquer entre eux et qui refuse l'entrée d'autres espaces de noms. Cette stratégie de ligne de base empêche également un espace de noms système, tel que kube-system, d'accéder à des espaces dans différents espaces de noms.

Solution : aucune. NCP ne prend pas en charge cette fonctionnalité dans une configuration TKGI.
Problème 3179960 : l'instance d'application n'est pas accessible après une opération vMotion et son adresse IP est identique à celle d'une autre instance d'application

Lors d'une opération vMotion en bloc, par exemple, pendant la mise à niveau des hôtes NSX, les hôtes passent l'un après l'autre en mode de maintenance et les cellules Diego migrent entre les hôtes. Après l'opération vMotion, il est possible que certains ports de segment soient manquants, que certaines instances d'application soient inaccessibles et que deux instances d'application aient la même adresse IP. Ce problème est plus susceptible de se produire avec TAS 2.13.18.

Solution : recréez les instances d'application affectées par ce problème.
Problème 3108579 : échec de la suppression de la CRD d'équilibrage de charge et de sa recréation immédiate avec le même secret

En mode Gestionnaire, si vous supprimez l'entrée sur une CRD d'équilibrage de charge, supprimez la CRD d'équilibrage de charge et recréez immédiatement l'entrée et la CRD d'équilibrage de charge avec le même certificat, l'erreur « Tentative d'importation d'un certificat qui a déjà été importé » peut s'afficher. Cela est dû à un problème de synchronisation, car la suppression de la CRD d'équilibrage de charge doit attendre la fin de l'opération de suppression de l'entrée.
Solution : utilisez l'une des méthodes suivantes :

- Exécutez la commande suivante pour attendre la fin de l'opération de suppression de l'entrée, puis supprimez la CRD d'équilibrage de charge.
- kubectl exec -ti <pod name> -nnsx-system -- nsxcli -c get ingress-caches|grep 'name: <Ingress name>'
- Attendez au moins 2 minutes avant de recréer l'entrée et la CRD d'équilibrage de charge.
Problème 3161931 : l'espace nsx-ncp-bootstrap ne parvient pas à s'exécuter sur les machines virtuelles hôtes Ubuntu 18.04 et Ubuntu 20.04

Le conteneur nsx-ncp-bootstrap dans l'espace nsx-ncp-bootstrap ne parvient pas à recharger « AppArmor » avec les messages de journal suivants : « Échec du chargement de policy-features à partir de '/etc/apparmor.d/abi/2.13 » : aucun fichier ou répertoire de ce type. » Ce problème est dû à différentes versions du module « AppArmor » installé dans l'image utilisée pour exécuter l'espace nsx-ncp-bootstrap et le système d'exploitation hôte. Ce problème n'existe pas sur les machines virtuelles hôtes Ubuntu 22.04.

Solution : Ubuntu 18.04 n'est pas pris en charge avec NCP 4.1.1. Sous Ubuntu 20.04, mettez à jour « AppArmor » vers la version minimale 2.13.3-7ubuntu5.2. Le module est disponible via des mises à jour focales.
Problème 3221191 : la création d'un groupe de domaines échoue lorsque le cluster contient plus de 4 000 espaces

Si l'option NCP k8s.baseline_policy_type est définie sur allow_cluster, allow_namespace ou allow_namespace_strict et que le cluster contient plus de 4 000 espaces, le groupe de domaines (portant un nom tel que dg-k8sclustername), qui contient toutes les adresses IP des espaces, ne peut pas être créé. Cela est dû à une limitation sur NSX.

Solution : ne définissez pas l'option k8s.baseline_policy_type ou assurez-vous que le cluster compte moins de 4 000 espaces.
Problème 3043496 : NCP cesse de s'exécuter si la migration Gestionnaire vers Stratégie échoue

NCP fournit la tâche migrate-mp2p pour migrer les ressources NSX utilisées par NCP et TKGI. Si la migration échoue, toutes les ressources migrées sont restaurées, mais NCP n'est pas redémarré en mode Gestionnaire.
Solution :
1. assurez-vous que toutes les ressources ont été restaurées. Pour ce faire, consultez les journaux de la tâche migrate-mp2p. Les journaux doivent se terminer par la ligne « Toutes les ressources MP importées vers la stratégie ont été entièrement restaurées. »
2. Si toutes les ressources ont été restaurées, utilisez ssh dans chaque nœud master et exécutez la commande « sudo /var/vcap/bosh/bin/monit start ncp ».
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.
Problème 2999131 : Services ClusterIP inaccessibles à partir des espaces

Dans un environnement TKGi à grande échelle, les services ClusterIP ne sont pas accessibles depuis les espaces. Autres problèmes associés : (1) nsx-kube-proxy cesse de générer les journaux de nsx-kube-proxy ; et (2) Les flux OVS ne sont pas créés sur le nœud.

Solution : redémarrez nsx-kube-proxy.
Problème 2984240 : L'opérateur « NotIn » dans matchExpressions ne fonctionne pas dans namespaceSelector pour la règle d'une stratégie réseau

Lorsque vous spécifiez une règle pour une stratégie réseau, la règle ne fonctionne pas si vous spécifiez namespaceSelector, matchExpressions et l'opérateur « NotIn ». Le journal NCP contient le message d'erreur « L'opérateur NotIn n'est pas pris en charge dans les sélecteurs NS ».

Solution : Réécrivez matchExpressions pour éviter d'utiliser l'opérateur « NotIn ».
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.
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 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 : Aucun
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.
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 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 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 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 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 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 : 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 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 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 3066449 : les sous-réseaux d'espace de noms ne sont pas toujours alloués à partir du premier bloc d'adresses IP disponible lorsque use_ip_blocks_in_order est défini sur True

Lors de la création de plusieurs espaces de noms avec use_ip_blocks_in_order défini sur True, le sous-réseau du premier espace de noms n'est parfois pas alloué à partir du premier bloc d'adresses IP disponible. Par exemple, supposons que container_ip_blocks = '172.52.0.0/28,172.53.0.0/28', que la longueur du préfixe de sous-réseau soit de 29 et que le sous-réseau 172.52.0.0/29 soit déjà alloué. Si vous créez 2 espaces de noms ns-1 et ns-2, l'allocation de sous-réseaux peut être (1) ns-1 : 172.52.0.8/29, ns-2 : 172.53.0.0/29 ou (2) ns-1 : 172.53.0.0/29, ns-2 : 172.52.0.8/29.

Le paramètre use_ip_blocks_in_order garantit uniquement que différents blocs d'adresses IP sont utilisés dans l'ordre dans lequel ils apparaissent dans le paramètre container_ip_blocks. Lors de la création de plusieurs espaces de noms simultanément, n'importe quel espace de noms peut demander un sous-réseau via un appel d'API avant un autre espace de noms. Par conséquent, il n'existe aucune garantie qu'un espace de noms spécifique se voie allouer un sous-réseau à partir d'un bloc d'adresses IP spécifique.

Solution : créez les espaces de noms séparément, c'est-à-dire, créez le premier espace de noms. Assurez-vous que son sous-réseau a été alloué, puis créez l'espace de noms suivant.