Note di rilascio di VMware NSX Container Plugin 4.1.1

VMware NSX Container Plugin 4.1.1 | 17 agosto 2023 | Build 22071564 Verificare la disponibilità di informazioni aggiuntive e aggiornamenti relativi a queste note di rilascio.

Novità

• A partire da questa versione, le nuove distribuzioni di TAS saranno consentite solo con Criterio di NSX. Per le basi di esistenti, le impostazioni di NCP non verranno modificate al momento degli aggiornamenti.

• Le risorse NSX create da TKGi per la rete di distribuzione vengono ora migrate in Criterio durante la migrazione da MP a Criterio.

• NCP supporta fino a 500 route OCP in un determinato Server virtuale di bilanciamento del carico di NSX.

• È possibile eseguire il backup di e successivamente ripristinare NSX a uno stato precedente. NCP garantirà che le risorse di un cluster OpenShift e NSX si trovino in uno stato coerente.

• L'operatore OpenShift può semplificare la distribuzione di NCP automatizzando determinate configurazioni delle opzioni. È stata migliorata anche la convalida delle opzioni immesse dalla mappa di configurazione.

Avviso di deprecazione

La funzionalità che consente l'accesso tramite NAT ai pod del controller di ingresso tramite l'annotazione "ncp/ingress_controller" è stata deprecata e verrà rimossa nel 2023. Per esporre i pod del controller di ingresso, è consigliabile utilizzare servizi di tipo LoadBalancer.

Il modulo kernel nsx-ovs è deprecato. È supportato solo il modulo del kernel OVS upstream, ovvero il comportamento predefinito. L'opzione di configmap "use_nsx_ovs_kernel_module" nella sezione "nsx_node_agent" nella configmap nsx-node-agent è stata rimossa.

Requisiti di compatibilità

Prodotto	Versione
NCP/NSX Tile for 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
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.4, 8.5, 8.6 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 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

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.

Per una nuova distribuzione su TAS, è supportata solo la modalità Criterio.

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 3049209: Dopo la migrazione da Manager a Criterio, l'eliminazione dei cluster non comporta l'eliminazione della risorsa mp_default_LR_xxx_user_rules

  Dopo aver eseguito una migrazione da Manager a Criterio e aver quindi eliminato i cluster, è possibile che alcune risorse "GatewayPolicy" denominate mp_default_LR_xxxx_user_rules non vengano eliminate.

  Soluzione: eliminare le risorse manualmente.

• Problema 3113985: Quando si esegue la migrazione di una singola topologia di livello, non vengono migrate tutte le route statiche

  In una singola topologia di livello 1 con più risorse personalizzate di tipo loadbalancers.vmware.com, alcune route statiche create da NCP in modalità Manager per i bilanciamenti del carico non vengono migrate.

  Soluzione: dopo aver eliminato la risorsa personalizzata di tipo loadbalancers.vmware.com da Kubernetes, eliminare manualmente la route statica con l'API di Manager. La route statica avrà l'UID della risorsa personalizzata nei propri tag con ambito "ncp/crd_lb_uid".

• Problema 3055618: Quando si creano più pod di Windows contemporaneamente in un nodo, alcuni pod non hanno una scheda di rete

  Quando si applica un file YAML per creare più pod di Windows nello stesso nodo, alcuni pod non hanno una scheda di rete.

  Soluzione: riavviare i pod.

• Problema 3088138: Dopo aver impostato log_file nella mappa di configurazione nsx-node-agent-config, i pod di nsx-node-agent non vengono avviati

  Se si imposta l'opzione log_file nella mappa di configurazione nsx-node-agent-config e si riavviano i pod nsx-ncp-bootstrap prima dei pod nsx-node-agent, i pod nsx-node-agent non vengono avviati e il loro stato è CrashLoopBackOff.

  Soluzione: riavviare i pod nsx-node-agent prima di riavviare i pod nsx-ncp-bootstrap dopo aver impostato l'opzione log_file nella mappa di configurazione nsx-node-agent-config.

• Problema 3091318: La creazione del pod non riesce dopo l'aggiornamento della subnet statica di uno spazio dei nomi quando NCP è inattivo

  Se si crea uno spazio dei nomi con ncp/subnet impostate, ad esempio 172.70.0.0/29, e non è ancora stato creato alcun pod nello spazio dei nomi, se si arresta NCP e si aggiorna ncp/subnet, ad esempio 172.71.0.0/29, dopo il riavvio di NCP, è possibile che la creazione di un pod nello spazio dei nomi non riesca e che il pod rimanga bloccato nello stato "ContainerCreating".

  Soluzione: creare nuovamente il pod.

• Problema 3110833: Non è possibile avviare i pod nel nodo worker Windows di TKGI. Lo stato è "ContainerCreating".

  L'avvio di ogni nodo nel nodo worker Windows non riesce. Il registro nsx-node-agent nel nodo segnala continuamente "Failed to process cif config request with error [...]. Restart node agent service to recover."

  Soluzione: riavviare il servizio nsx-node-agent nel nodo.

Problemi noti

• Problema 3306543: Dopo l'eliminazione di un pod, un nuovo pod creato con lo stesso nome ha una configurazione di rete non corretta

  In rari casi, se si elimina un pod e si crea un nuovo pod con lo stesso nome, il nuovo pod avrà la configurazione di rete del pod precedente. La configurazione di rete del nuovo pod non è corretta.

  Soluzione: eliminare il nuovo pod, riavviare nsx-node-agent e quindi ricreare il pod.

• 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 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 3161931: il pod nsx-ncp-bootstrap non viene eseguito correttamente nelle macchine virtuali host Ubuntu 18.04 e Ubuntu 20.04

  Il container nsx-ncp-bootstrap nel pod nsx-ncp-bootstrap non riesce a ricaricare "AppArmor" e nel registro viene visualizzato il messaggio seguente: "Failed to load policy-features from '/etc/apparmor.d/abi/2.13': No such file or directory." Il problema è causato da versioni diverse del pacchetto "AppArmor" installate nell'immagine utilizzata per eseguire il pod nsx-ncp-bootstrap e il sistema operativo host. Questo problema non esiste nelle macchine virtuali host Ubuntu 22.04.

  Soluzione: Ubuntu 18.04 non è supportato con NCP 4.1.1. In Ubuntu 20.04, aggiornare "AppArmor" alla versione minima 2.13.3-7ubuntu5.2. Il pacchetto è disponibile tramite aggiornamenti focali.

• 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 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 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 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

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