Note di rilascio di VMware NSX Container Plugin 4.1.2

VMware NSX Container Plugin 4.1.2 | 19 ottobre 2023 | Build 22596735 Verificare la disponibilità di informazioni aggiuntive e aggiornamenti relativi a queste note di rilascio.

Novità

• Supporto per la creazione di nuovi cluster in TAS in modalità Manager. Si tenga presente che questa funzionalità non sarà supportata nella prossima versione.

• Supporto per la migrazione delle basi TAS dalla modalità Manager alla modalità Criterio.

• Nuovo runbook per generare un report di debug per i passaggi di configurazione di NCP.

Avviso di deprecazione

• Il supporto NAT per i controller di ingresso di terze parti è obsoleto e verrà rimosso in una versione futura.

  Questa funzionalità è controllata dal parametro k8s.ingress_mode e viene abilitata nei pod del controller di ingresso che utilizzano l'annotazione ncp/ingress_controller. Con questa funzionalità, il pod del controller di ingresso verrà esposto con una regola DNAT. Il modo preferito per esporre questi pod consiste nell'utilizzare un servizio di tipo LoadBalancer.

• I moduli del kernel OVS di NSX sono obsoleti e verranno rimossi nella prossima versione.

• Multus non è più supportato. Verrà rimosso nella prossima versione.

Requisiti di compatibilità

Prodotto	Versione
NCP/NSX Tile for Tanzu Application Service (TAS)	4.1.2
NSX	3.2.3, 4.0.1, 4.1.1, 4.1.2
Kubernetes	1.25, 1.26, 1.27
OpenShift 4	4.11, 4.12
Kubernetes Host VM OS	Ubuntu 20.04 Ubuntu 22.04 con kernel 5.15 (sono supportati sia il modulo kernel nsx-ovs sia il modulo kernel OVS upstream) Ubuntu 22.04 con kernel successivo a 5.15 (è supportato solo il modulo kernel OVS upstream) RHEL 8.6, 8.8, 9.2 Vedere le note seguenti.
Tanzu Application Service (TAS)	Ops Manager 2.10 + TAS 2.13 Ops Manager 3.0 + TAS 2.13 Ops Manager 2.10 + TAS 4.0 Ops Manager 3.0 + TAS 4.0 Ops Manager 2.10 + TAS 5.0 Ops Manager 3.0 + TAS 5.0
Tanzu Kubernetes Grid Integrated (TKGI)	1.18.0

Note:

Per tutte le integrazioni supportate, utilizzare Red Hat Universal Base Image (UBI). Per ulteriori informazioni, vedere https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image.

Supporto per l'aggiornamento a questa versione:

• 4.1.0. 4.1.1 e tutte le versioni 4.0.x.

Limitazioni

• La funzionalità "Criterio base di confronto" per NCP crea un gruppo dinamico che seleziona tutti i membri nel cluster. In NSX-T, un gruppo dinamico può includere al massimo 8.000 membri effettivi (per informazioni dettagliate, vedere Valori massimi della configurazione). È quindi consigliabile non abilitare questa funzionalità per i cluster che si prevede conterranno oltre 8.000 pod. Il superamento di questo limite può causare ritardi nella creazione delle risorse per i pod.

• Bilanciamento del carico in modalità trasparente

  • È supportato solo il traffico nord-sud per un cluster Kubernetes. Il traffico all'interno del cluster non è supportato.

  • Non supportato per i servizi collegati a un CRD LoadBalancer o quando è abilitata la scalabilità automatica. Affinché questa funzionalità funzioni, è necessario disabilitare la scalabilità automatica.

  • È consigliabile utilizzare questa funzionalità solo nei cluster appena distribuiti.

• Migrazione da Manager a criterio

  • Non è possibile eseguire la migrazione di un cluster Kubernetes se una migrazione precedente non è riuscita ed è stato eseguito il rollback del cluster. Questa è una limitazione valida solo per NSX 4.0.0.1 o versioni precedenti.

• Esiste un rischio di peggioramento significativo delle prestazioni nel calcolo del membro effettivo del gruppo, con un impatto sul traffico di rete quando si implementano criteri di rete che utilizzano criteri a più selettori nelle regole di ingresso/uscita. Per risolvere questa limitazione, è disponibile una nuova opzione di configurazione, enable_mixed_expression_groups, che influisce sui criteri di rete Kubernetes utilizzando più selettori in modalità Criterio. I cluster in modalità Manager non sono interessati. Il valore predefinito di questa opzione è False. Si consigliano i valori seguenti nel cluster:

  • TKGi

    • Nuovi cluster, modalità Criterio: False

    • Cluster esistenti (basati su criteri): True

    • Dopo la migrazione da Manager a criterio: True

  • OC: Impostare su True per garantire la conformità del criterio di rete Kubernetes

  • DIY Kubernetes

    • Nuovi cluster (basati su criteri): False

    • Cluster esistenti (basati su criteri): True

    • Dopo la migrazione da Manager a criterio: True

  Questa limitazione si applica quando enable_mixed_expression_groups è impostato su True. Questo influisce sulle installazioni che utilizzano NCP 3.2.0 e versioni successive e NSX-T 3.2.0 e versioni successive. Non vi è alcuna limitazione al numero di spazi dei nomi su cui il criterio di rete influisce. Se questa opzione è impostata su True e NCP viene riavviato, NCP sincronizzerà nuovamente tutti i criteri di rete per implementare questo comportamento.

  Quando enable_mixed_expression_groups è impostato su False, i criteri di rete che utilizzano i criteri a più selettori nelle regole di ingresso/uscita sono realizzati con gruppi di NSX dinamici che non sono interessati da alcuna riduzione delle prestazioni nel calcolo dei membri effettivi. Tuttavia, le regole possono essere applicate solo a un massimo di 5 spazi dei nomi, in base agli altri criteri definiti nel criterio di rete. Se il criterio di rete influisce su più di 5 spazi dei nomi in qualsiasi momento, verrà annotato con "ncp/error: NETWORK_POLICY_VALIDATION_FAILED" e non applicato in NSX. Si noti che ciò può verificarsi quando viene creato un nuovo spazio dei nomi che soddisfa le condizioni del multi-selettore o quando viene aggiornato uno spazio dei nomi esistente. Se questa opzione è impostata su False e NCP viene riavviato, NCP sincronizzerà nuovamente tutti i criteri di rete per implementare questo comportamento.

Problemi risolti

• Problema 3239352: In un ambiente TAS, quando non è possibile allocare un'attività, un nuovo tentativo potrebbe non funzionare

  In un ambiente TAS NCP, quando non è possibile allocare un'attività, il gestore dell'asta rifiuta l'attività e BBS ritenta il posizionamento dell'attività fino al numero di volte specificato nell'impostazione task.max_retries. Quando viene raggiunto il valore di task.max_retries, BBS aggiorna l'attività dallo stato IN SOSPESO allo stato COMPLETATO, contrassegnandola come Non riuscita e includendo un FailureReason che spiega che il cluster non dispone di capacità per l'attività.

  Durante il nuovo tentativo, l'attività può essere pianificata in una nuova cella che notifica a NCP un evento task_changed. Poiché NCP non gestisce l'evento task_changed, all'attività non può essere assegnata una nuova porta nella nuova cella. L'attività non può essere eseguita correttamente.

  Soluzione: disabilitare il nuovo tentativo e impostare il valore di task.max_retries su 0.

• Problema 3043496: Se la migrazione da Manager a criterio non riesce, l'esecuzione di NCP viene interrotta

  NCP fornisce il processo migrate-mp2p per eseguire la migrazione delle risorse di NSX utilizzate da NCP e TKGI. Se la migrazione non riesce, viene eseguito il rollback di tutte le risorse migrate ma NCP non viene riavviato in modalità Manager.

  Soluzione:

  1. Assicurarsi che sia stato eseguito il rollback di tutte le risorse. A tale scopo, controllare i registri del processo migrate-mp2p. I registri devono terminare con la riga "All imported MP resources to Policy completely rolled back" che indica che è stato eseguito il rollback di tutte le risorse MP importate in Criterio.

  2. Se è stato eseguito il rollback di tutte le risorse, accedere tramite SSH a ogni nodo master ed eseguire il comando "sudo /var/vcap/bosh/bin/monit start ncp".

• Problema 2939886: La migrazione degli oggetti dalla modalità Manager alla modalità Criterio non riesce

  La migrazione degli oggetti dalla modalità Manager alla modalità Criterio non riesce se nella specifica del criterio di rete l'uscita e l'ingresso hanno lo stesso selettore.

  Soluzione: Nessuna

Problemi noti

• Problema 3293981: La creazione di due ingressi con defaultBackend in un breve periodo di tempo causa l'errore DEFAULT_BACKEND_IN_USE

  Se in un breve periodo di tempo vengono creati due ingressi con defaultBackend specificato, è possibile che in entrambi gli ingressi si verifichi l'errore DEFAULT_BACKEND_IN_USE.

  Soluzione: creare un ingresso alla volta. Per risolvere l'errore DEFAULT_BACKEND_IN_USE, eliminare defaultBackend da entrambi gli ingressi e aggiungerlo nuovamente a un ingresso alla volta.

• Problema 3292003: In un ambiente OCP, il nodo diventa inattivo dopo l'applicazione di taint con effetto NoExecute

  In un ambiente OCP, se si rimuove la tolleranza {"effect":"NoExecute","operator":"Exists"} per il DaemonSet dell'agente del nodo e si aggiunge un taint con effetto NoExecute in un nodo, ad esempio test=abc:NoExecute, è possibile che il nodo diventi inattivo. In questo scenario, il pod dell'agente del nodo verrà rimosso dal nodo con taint. Durante la rimozione del pod dell'agente del nodo, è possibile che il nodo perda la connettività perché il pod dell'agente del nodo non esce normalmente e l'interfaccia di uplink del nodo non viene configurata correttamente da br-int a ens192.

  Soluzione: riavviare la macchina virtuale del nodo da vCenter Server.

• Problema 3293969: In un ambiente OCP, durante l'aggiornamento di NCP, un nodo diventa non pronto

  In un ambiente OCP, durante l'aggiornamento di NCP, l'agente del nodo viene riavviato. È possibile che un nodo perda la connettività perché il pod dell'agente del nodo non viene chiuso normalmente e l'interfaccia di uplink del nodo non viene configurata correttamente da br-int a ens192. Lo stato del nodo diventa Non pronto.

  Soluzione: riavviare la macchina virtuale del nodo da vCenter Server.

• Problema 3252571: La migrazione da Manager a criterio non viene mai completata se NSX Manager diventa non disponibile

  Se NSX Manager diventa non disponibile durante la migrazione da Manager a criterio, la migrazione potrebbe non essere mai completata. Un'indicazione è che i registri non conterranno aggiornamenti sulla migrazione.

  Soluzione: Ristabilire la connessione a NSX Manager e riavviare la migrazione.

• Problema 3248662: Il nodo di lavoro non riesce ad accedere a un servizio. Il flusso OVS per il servizio non viene creato nel nodo.

  Nel registro di nsx-kube-proxy è presente il messaggio di errore "greenlet.error: cannot switch to a different thread".

  Soluzione: Riavviare nsx-kube-proxy nel nodo.

• Problema 3241693: Le route di livello 7 impiegano più di 10 minuti per iniziare a funzionare quando il numero di route create supera alcuni limiti

  In un ambiente OpenShift, è possibile distribuire più di 1000 route impostando i contrassegni "relax_scale_validation" su True e su "l4_lb_auto_scaling" su False in ConfigMap. Tuttavia, le route impiegheranno più di 10 minuti per iniziare a funzionare quando il numero di route create supera i limiti. I limiti sono 500 route HTTPs e 2000 route HTTP.

  Soluzione: Non superare i limiti per il numero di route. Se si creano 500 route HTTPS più 2000 HTTP, è necessario distribuire le route utilizzando una macchina virtuale Edge di grandi dimensioni.

• Problema 3158230: impossibile inizializzare il container nsx-ncp-bootstrap durante il caricamento dei profili AppArmor in Ubuntu 20.04

  Il container nsx-ncp-bootstrap in DaemonSet nsx-ncp-bootstrap non viene inizializzato a causa di versioni diverse del pacchetto di AppArmor nel sistema operativo host e nell'immagine del container. I registri del container mostrano messaggi del tipo "Failed to load policy-features from '/etc/apparmor.d/abi/2.13': No such file or directory".

  Soluzione: Aggiornare AppArmor alla versione 2.13.3-7ubuntu5.2 o alla versione più recente disponibile da aggiornamenti focali nel sistema operativo host.

• Problema 3179549: La modifica della modalità NAT per uno spazio dei nomi esistente non è supportata

  Per uno spazio dei nomi con pod esistenti, se si modifica la modalità NAT da SNAT a NO_SNAT, i pod utilizzeranno comunque gli indirizzi IP allocati dai blocchi di IP specificati nel container_ip_blocks. Se la subnet del segmento nello spazio dei nomi dispone ancora di indirizzi IP, i pod appena creati continueranno a utilizzare gli indirizzi IP della subnet del segmento esistente. Per un segmento appena creato, la subnet viene allocata da no_snat_ip_block. Ma nello spazio dei nomi, la regola SNAT verrà eliminata.

  Soluzione: nessuna.

• Problema 3218243: Il Criterio di sicurezza in NSX creato per il Criterio di rete Kubernetes che utilizza criteri multi-selettore viene rimosso dopo l'aggiornamento di NCP alla versione 4.1.1 o quando l'utente crea/aggiorna lo spazio dei nomi

  Verificare che l'opzione "enable_mixed_expression_groups" sia impostata su False in NCP (il valore predefinito è False). In questo caso, il Criterio di rete comporta la creazione di più di 5 criteri di gruppo in NSX, che non è supportata.

  Soluzione: Impostare enable_mixed_expression_groups su True nella mappa di configurazione di NCP e riavviare NCP. Si noti che in questo caso esiste il rischio di una riduzione significativa delle prestazioni nel calcolo del membro effettivo del gruppo, con un impatto sul traffico di rete.

• Problema 3235394: Il criterio della base di confronto con l'impostazione dello spazio dei nomi non funziona in una configurazione di TKGI

  In un ambiente TGKI, se si imposta baseline_policy_type su allow_namespace o allow_namespace_strict, NCP creerà un criterio di base di confronto esplicito per consentire solo ai pod all'interno dello stesso spazio dei nomi di comunicare tra loro e negare l'ingresso agli altri spazi dei nomi. Questo criterio della base di confronto impedirà inoltre a uno spazio dei nomi del sistema, ad esempio kube-system, di accedere ai pod in spazi dei nomi differenti.

  Soluzione: nessuna. NCP non supporta questa funzionalità in una configurazione di TKGI.

• Problema 3179960: L'istanza dell'applicazione non è raggiungibile dopo vMotion e ha lo stesso indirizzo IP di un'altra istanza di applicazione

  Quando si verifica vMotion in blocco, ad esempio durante l’aggiornamento dell'host NSX, gli host passano alla modalità di manutenzione uno alla sola e le celle Diego migrano tra host. Dopo vMotion, alcune porte dei segmenti potrebbero risultare mancanti, alcune istanze di applicazioni potrebbero essere irraggiungibili e due istanze di applicazioni potrebbero avere lo stesso indirizzo IP. È più probabile che questo problema si verifichi con TAS 2.13.18.

  Soluzione: Ricreare le istanze di applicazioni interessate da questo problema.

• Problema 3108579: Non è possibile eseguire l'eliminazione di CRD LB e la sua ricreazione immediata con lo stesso segreto

  In modalità Manager, se si elimina l'ingresso in un CRD LB, si elimina il CRD LB e si ricrea immediatamente l’ingresso e il CRD LB con lo stesso certificato, è possibile che venga visualizzato il messaggio di errore "Tentativo di importazione di un certificato già importato". Ciò è causato da un problema di temporizzazione perché l'eliminazione del CRD LB deve attendere il completamento dell'eliminazione dell'ingresso.

  Soluzione: eseguire una delle operazioni seguenti:

  - Eseguire il comando seguente per attendere il completamento dell'eliminazione dell'ingresso, quindi eliminare il CRD LB.

  • kubectl exec -ti <pod name> -nnsx-system -- nsxcli -c get ingress-caches|grep 'name: <nome ingresso>'

  - Attendere almeno 2 minuti prima di ricreare l’ingresso e il CRD LB.

• Problema 3221191: La creazione del gruppo di domini non riesce quando il cluster include più di 4000 pod

  Se l'opzione NCP k8s.baseline_policy_type è impostata su allow_cluster, allow_namespace o allow_namespace_strict e il cluster include più di 4000 pod, non sarà possibile creare il gruppo di domini (con un nome come dg-k8sclustername), che contiene tutti gli indirizzi IP dei pod. Ciò è causato da una limitazione in NSX.

  Soluzione: Non impostare l'opzione k8s.baseline_policy_type o assicurarsi che nel cluster siano presenti meno di 4000 pod.

• Problema 2131494: L'ingresso Kubernetes NGINX funziona ancora dopo la modifica della classe Ingresso da nginx a nsx

  Quando si crea un ingresso Kubernetes NGINX, NGINX crea regole di inoltro del traffico. Se si modifica la classe Ingresso impostandola su qualsiasi altro valore, NGINX non elimina le regole e continua ad applicarle, anche se si elimina l'ingresso Kubernetes dopo aver modificato la classe. Questo è un limite di NGINX.

  Soluzione: per eliminare le regole create da NGINX, eliminare l'ingresso Kubernetes quando il valore della classe è nginx. Ricreare quindi l'ingresso Kubernetes.

• Problema 2999131: I servizi ClusterIP non sono raggiungibili dai pod

  In un ambiente TKGi su larga scala, i servizi ClusterIP non sono raggiungibili dai pod. Altri problemi correlati sono: (1) nsx-kube-proxy interrompe l'output dei registri di nsx-kube-proxy e (2) i flussi di OVS non vengono creati nel nodo.

  Soluzione: riavviare nsx-kube-proxy.

• Problema 2984240: L'operatore "NotIn" in matchExpressions non funziona in namespaceSelector per la regola di un criterio di rete

  Quando si specifica una regola per un criterio di rete, se si specifica namespaceSelector, matchExpressions e l'operatore "NotIn", la regola non funziona. Nel registro di NCP è presente il messaggio di errore "L'operatore NotIn non è supportato nei selettori NS".

  Soluzione: riscrivere matchExpressions per evitare di utilizzare l'operatore "NotIn".

• Problema 3033821: Dopo la migrazione da manager a criterio, le regole del firewall distribuito non vengono applicate correttamente

  Dopo una migrazione da manager a criterio, le regole del firewall distribuito (DFW) correlate al criterio di rete appena create avranno una priorità più alta rispetto alle regole DFW migrate.

  Soluzione: utilizzare l'API del criterio per modificare la sequenza delle regole DFW in base alle esigenze.

• Per un servizio Kubernetes di tipo ClusterIP, il flag della modalità hairpin non è supportato

  NCP non supporta il flag della modalità hairpin per un servizio Kubernetes di tipo ClusterIP.

  Soluzione: Nessuna

• Problema 2224218: Dopo l'eliminazione di un servizio o un'app, sono necessari 2 minuti per rilasciare nuovamente l'IP SNAT nel pool di IP

  Se si elimina un servizio o un'app e li si ricrea entro 2 minuti, otterranno un nuovo IP SNAT dal pool di IP.

  Soluzione: dopo aver eliminato un servizio o un'app, attendere 2 minuti prima di ricrearli se si desidera riutilizzare lo stesso IP.

• Problema 2404302: Se in NSX-T sono presenti più profili di applicazione di bilanciamento del carico per lo stesso tipo di risorsa (ad esempio HTTP), NCP sceglierà uno di tali profili da collegare ai server virtuali.

  Se in NSX-T sono presenti più profili di applicazione di bilanciamento del carico HTTP, NCP sceglierà uno di tali profili con la configurazione x_forwarded_for appropriata da collegare ai server virtuali HTTP e HTTPS. Se in NSX-T sono presenti più profili di applicazione FastTCP e UDP, NCP sceglierà uno di tali profili da collegare ai server virtuali TCP e UDP, rispettivamente. I profili di applicazione di bilanciamento del carico potrebbero essere stati creati da applicazioni diverse con impostazioni diverse. Se NCP sceglie di collegare uno di questi profili di applicazione di bilanciamento del carico ai server virtuali creati da NCP, è possibile che interrompa il workflow delle altre applicazioni.

  Soluzione: Nessuna

• Problema 2518111: NCP non riesce a eliminare le risorse di NSX-T aggiornate da NSX-T

  NCP crea risorse di NSX-T in base alle configurazioni specificate. Se si aggiornano tali risorse di NSX-T tramite NSX Manager o NSX-T API, è possibile che NCP non riesca a eliminare le risorse e a ricrearle quando è necessario.

  Soluzione: non aggiornare le risorse di NSX-T create da NCP tramite NSX Manager o NSX-T API.

• Problema 2416376: NCP non riesce a elaborare un ASG (App Security Group) di TAS associato a più di 128 spazi

  A causa di un limite del firewall distribuito di NSX-T, NCP non è in grado di elaborare un ASG di TAS associato a più di 128 spazi.

  Soluzione: creare più ASG e associare ciascun ASG a non più di 128 spazi.

• L'avvio di NCP non riesce quando è abilitata la "registrazione su file" durante l'installazione di Kubernetes

  Questo problema si verifica quando uid:gid=1000:1000 nell'host del container non dispone dell'autorizzazione necessaria per la cartella del registro.

  Soluzione: eseguire una delle operazioni seguenti:

  • Impostare la modalità della cartella del registro su 777 negli host del container.

  • Concedere l'autorizzazione "rws" della cartella del registro a uid:gid=1000:1000 negli host del container.

  • Disabilitare la funzionalità "registrazione su file".

• Problema 2653214: Si verifica un errore durante la ricerca della porta del segmento per un nodo dopo la modifica dell'indirizzo IP del nodo

  Dopo aver modificato l'indirizzo IP di un nodo, se si aggiorna NCP o se il pod di NCP Operator viene riavviato, il controllo dello stato di NCP Operator con il comando "oc describe co nsx-ncp" causa la visualizzazione del messaggio di errore "Errore durante la ricerca della porta del segmento per il nodo..."

  Soluzione: nessuna. L'aggiunta di un indirizzo IP statico nell'interfaccia di un nodo che dispone anche di una configurazione DHCP non è supportata.

• Problema 2672677: In un ambiente di OpenShift 4 con un carico elevato, un nodo può smettere di rispondere

  In un ambiente di OpenShift 4 con un livello elevato di densità di pod per nodo e un'alta frequenza di eliminazione e creazione di pod, un nodo RHCOS potrebbe passare allo stato "Non pronto". I pod in esecuzione nel nodo interessato, ad eccezione dei membri del daemonset, verranno rimossi e ricreati negli altri nodi dell'ambiente.

  Soluzione: riavviare il nodo interessato.

• Problema 2707174: Un pod eliminato e ricreato con lo stesso spazio dei nomi e lo stesso nome non dispone di connettività di rete

  Se un pod viene eliminato e ricreato con lo stesso spazio dei nomi e lo stesso nome quando NCP non è in esecuzione e le istanze di nsx-ncp-agent sono in esecuzione, il pod potrebbe ricevere configurazioni di rete errate e non essere in grado di accedere alla rete.

  Soluzione: eliminare il pod e ricrearlo quando NCP è in esecuzione.

• Problema 2745907: I comandi "monit" restituiscono informazioni di stato errate per nsx-node-agent

  In una macchina virtuale diego_cell, quando monit riavvia nsx-node-agent, se occorrono più di 30 secondi per l'avvio completo di nsx-node-agent, monit mostrerà lo stato di nsx-node-agent come "Esecuzione non riuscita" e non aggiornerà lo stato impostandolo su "in esecuzione" anche quando più tardi nsx-node-agent sarà completamente funzionante.

  Soluzione: nessuna.

• Problema 2735244: Si verifica l'arresto anomalo di nsx-node-agent e nsx-kube-proxy a causa di un errore del probe di attività

  nsx-node-agent e nsx-kube-proxy utilizzano sudo per eseguire alcuni comandi. Se in /etc/resolv.conf sono presenti molte voci relative al server DNS e ai domini di ricerca, è possibile che sudo impieghi molto tempo per risolvere i nomi host. In questo modo, nsx-node-agent e nsx-kube-proxy verranno bloccati dal comando sudo per un lungo periodo di tempo e il probe di attività non riuscirà.

  Soluzione: eseguire una delle azioni seguenti:

  • Aggiungere le voci del nome host in /etc/hosts. Ad esempio, se il nome host è "host1", aggiungere la voce "127.0.0.1 host1".

  • Impostare un valore maggiore per il timeout del probe di attività di nsx-node-agent. Eseguire il comando "kubectl edit ds nsx-node-agent -n nsx-system" per aggiornare il valore del timeout per entrambi i container nsx-node-agent e nsx-kube-proxy.

• Problema 2736412: Il parametro members_per_small_lbs viene ignorato se è impostato max_allowed_virtual_servers

  Se sono impostati sia max_allowed_virtual_servers sia members_per_small_lbs, è possibile che i server virtuali non si colleghino a un bilanciamento del carico disponibile perché viene considerato solo max_allowed_virtual_servers.

  Soluzione: rendere meno rigidi i vincoli di scalabilità anziché abilitare la scalabilità automatica.

• Problema 2740552: Quando si elimina un pod statico utilizzando api-server, nsx-node-agent non rimuove la porta del bridge OVS del pod e la rete del pod statico che viene ricreata automaticamente da Kubernetes non è disponibile

  Kubernetes non consente la rimozione di un pod statico tramite api-server. Kubernetes crea un pod di mirroring del pod statico in modo che il pod statico possa essere cercato da api-server. Quando si elimina il pod tramite api-server, viene eliminato solo il pod di mirroring e NCP riceve e gestisce la richiesta di eliminazione per rimuovere tutte le risorse NSX allocate per il pod. Tuttavia, il pod statico esiste ancora e nsx-node-agent non riceve la richiesta di eliminazione da CNI per rimuovere la porta del bridge OVS del pod statico.

  Soluzione: rimuovere il pod statico eliminando il file manifesto anziché rimuovere il pod statico tramite api-server.

• Problema 2824129: Un nodo ha lo stato network-unavailable uguale a true per più di 3 minuti dopo un riavvio

  Se si utilizza NCP Operator per gestire il ciclo di vita di NCP, quando un daemonset di nsx-node-agent viene ripristinato da uno stato non in esecuzione, il nodo avrà lo stato network-unavailable uguale a true finché non saranno passati 3 minuti. Si tratta di un comportamento previsto.

  Soluzione: attendere almeno 3 minuti dopo il riavvio di nsx-node-agent.

• Problema 2832480: Per un servizio Kubernetes di tipo ClusterIP, sessionAffinityConfig.clientIP.timeoutSeconds non può superare 65535

  Per un servizio Kubernetes di tipo ClusterIP, se si imposta sessionAffinityConfig.clientIP.timeoutSeconds su un valore maggiore di 65535, il valore effettivo sarà 65535.

  Soluzione: Nessuna

• Problema 2940772: La migrazione delle risorse NCP da Manager a Criterio causa un errore con NSX-T 3.2.0

  La migrazione delle risorse NCP da Manager a Criterio è supportata con NSX-T 3.1.3 e NSX-T 3.2.1, ma non con NSX-T 3.2.0.

  Soluzione: Nessuna

• Problema 2934195: Alcuni tipi di gruppi di NSX non sono supportati per le regole del firewall distribuito

  Un gruppo di NSX di tipo "Solo indirizzi IP" non è supportato per le regole del firewall distribuito (DFW). Non è supportato nemmeno un gruppo di NSX di tipo "Generico" con indirizzi IP aggiunti manualmente come membri.

  Soluzione: Nessuna

• Problema 3066449: Le subnet dello spazio dei nomi non vengono sempre allocate dal primo blocco IP disponibile quando il parametro use_ip_blocks_in_order è impostato su True

  Quando si creano più spazi dei nomi con il parametro use_ip_blocks_in_order impostato su True, a volte la subnet del primo spazio dei nomi non viene allocata dal primo blocco IP disponibile. Si supponga ad esempio che container_ip_blocks = "172.52.0.0/28,172.53.0.0/28", la lunghezza del prefisso della subnet sia 29 e la subnet 172.52.0.0/29 sia già allocata. Se si creano 2 spazi dei nomi ns-1 e ns-2, l'allocazione delle subnet può essere (1) ns-1: 172.52.0.8/29, ns-2: 172.53.0.0/29, o (2) ns-1: 172.53.0.0/29, ns-2: 172.52.0.8/29.

  Il parametro use_ip_blocks_in_order garantisce solo che blocchi IP diversi vengano utilizzati nell'ordine in cui vengono visualizzati nel parametro container_ip_blocks. Quando si creano più spazi dei nomi contemporaneamente, ogni spazio dei nomi può richiedere una subnet tramite una chiamata API prima di un altro spazio dei nomi. Pertanto, non è possibile garantire che a un determinato spazio dei nomi verrà allocata una subnet da un blocco IP specifico.

  Soluzione: creare gli spazi dei nomi separatamente, ovvero creare il primo spazio dei nomi, assicurarsi che la relativa subnet sia stata allocata e quindi creare lo spazio dei nomi successivo.