Note di rilascio di VMware NSX Container Plugin 3.2.1.1

VMware NSX Container Plugin 3.2.1.1 \| 17 MAG 2022 \| Build 19750154 Verificare la disponibilità di informazioni aggiuntive e aggiornamenti relativi a queste note di rilascio.

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

Verificare la disponibilità di informazioni aggiuntive e aggiornamenti relativi a queste note di rilascio.

Novità

Supporto per la distribuzione di nodi di lavoro OCP con più vNIC

La distribuzione di nodi di lavoro OCP con più vNIC è supportata, con il presupposto che la prima vNIC venga utilizzata per la rete del container.
Supporto per l'opzione "natfirewallmatch"

L'opzione "natfirewallmatch" specifica il comportamento del firewall del gateway NSX-T con le regole NAT create per uno spazio dei nomi Kubernetes. Questa opzione si applica solo agli spazi dei nomi Kubernetes appena creati e non agli spazi dei nomi esistenti.

Avviso di deprecazione

L'annotazione ncp/whitelist-source-range verrà deprecata in NCP 4.0. A partire da NCP 3.1.1, è possibile utilizzare invece l'annotazione "ncp/allowed-source-range".

La funzionalità che consente l'accesso tramite NAT ai pod del controller di ingresso utilizzando 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.

Requisiti di compatibilità

Prodotto	Versione
NCP/NSX-T Tile for Tanzu Application Service (TAS)	3.2.1
NSX-T	3.1.3, 3.2, 3.2.1 (vedere le note seguenti)
vSphere	6.7, 7.0
Kubernetes	1.21, 1.22, 1.23
OpenShift 4	4.7, 4.8, 4.9
OpenShift Host VM OS	RHCOS 4.7, 4.8
Kubernetes Host VM OS	Ubuntu 18.04, 20.04 CentOS 8.2 RHEL 8.4, 8.5 Vedere le note seguenti.
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

Note:

L'installazione del modulo kernel nsx-ovs in CentOS/RHEL richiede una versione del kernel specifica. Le versioni del kernel CentOS/RHEL supportate sono 193, 305 e 348, indipendentemente dalla versione di CentOS/RHEL. Si tenga presente che la versione del kernel predefinita è 193 per RHEL 8.2, 305 per RHEL 8.4 e 348 per RHEL 8.5. Se si esegue una versione del kernel diversa, è possibile (1) modificare la versione del kernel con una versione supportata. Quando si modifica la versione del kernel e quindi si riavvia la macchina virtuale, assicurarsi che l'IP e le route statiche vengano mantenute nell'interfaccia di uplink (specificata da ovs_uplink_port) per garantire che la connettività al server dell'API Kubernetes non venga persa. Oppure (2) ignorare l'installazione del modulo del kernel nsx-ovs impostando "use_nsx_ovs_kernel_module" su "False" nella sezione "nsx_node_agent" nella mappa di configurazione di nsx-node-agent.

Per eseguire il modulo del kernel nsx-ovs in RHEL/CentOS, è necessario disabilitare l'opzione "Avvio sicuro UEFI" in "Opzioni di avvio" nelle impostazioni della macchina virtuale in vCenter Server.

A partire da NCP 3.1.2, l'immagine di RHEL non viene distribuita. 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.

TKGI 1.14.0 fornito con NCP 3.2.1.0, che non supporta NSX-T 3.2.1.

TKGI 1.13.x e TKGI 1.14.x non sono compatibili con NSX-T 3.2.0.x.

Supporto per l'aggiornamento a questa versione:

Tutte le versioni 3.1.x
Tutte le versioni 3.2.x precedenti

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.

Problemi risolti

Problema 3042916: nsx-kube-proxy non riesce dopo l'avvio e viene visualizzato l'errore "porta non valida o sconosciuta per in_port"

In rari casi l'errore di nsx-kube-proxy si verifica poco dopo l'avvio perché in quel momento l'uplink OVS "ofport" è vuoto. Nel registro viene visualizzato il messaggio di errore "RuntimeError: Errore irreversibile durante l'esecuzione di xxx: (): porta non valida o sconosciuta per in_port.

Soluzione: riavviare nsx-kube-proxy.
Problema 2863155: Alcuni servizi IP del cluster non sono raggiungibili dai pod in un ambiente su larga scala

In un ambiente su larga scala, un registro di grandi dimensioni può causare problemi relativi a nsx-kube-proxy. Alcuni servizi IP del cluster non sono raggiungibili dai pod e nsx-kube-proxy non può segnalare il proprio stato in nsxcli.

Soluzione: riavviare nsx-kube-proxy.
Problema 2944368: Una regola di ingresso in cui è specificato "host" corrisponde sia all'host sia all'host con un suffisso

Ad esempio, una regola in cui l'host è specificato come "test.co" corrisponderà sia a "test.co" sia a "test.co.uk".

Soluzione: Nessuna
Problema 2882699: In un ambiente IPv6, l'impostazione di baseline_policy_type su allow_namespace_strict causa un errore di comunicazione

In un ambiente IPv6, con l'opzione baseline_policy_type impostata su allow_namespace_strict, i pod non possono accedere ai nodi Kubernetes.

Soluzione: aggiungere una regola del firewall distribuito con una priorità più alta rispetto alla regola della base di confronto per consentire il traffico dai pod ai nodi Kubernetes.
Problema 2867871: L'accesso al servizio clusterIP dai pod a cui il servizio fa riferimento non riesce se il nome del nodo Kubernetes dei pod è diverso dal nome host

NCP supporta attualmente l'accesso autonomo del pod al servizio clusterIP solo quando il nome del nodo Kubernetes è uguale al nome host. Questo perché nsx-kube-proxy aggiunge il flusso di accesso autonomo solo se il nome host è uguale al nome del nodo.

Soluzione: Nessuna
Problema 2555336: Il traffico del pod non funziona a causa di porte logiche duplicate create in modalità Manager

È più probabile che questo problema si verifichi quando sono presenti molti pod in diversi cluster. Quando si crea un pod, il traffico verso il pod non funziona. NSX-T include più porte logiche create per lo stesso container. Nel registro di NCP è presente solo l'ID di una delle porte logiche.

Soluzione: eliminare il pod e ricrearlo. Le porte obsolete in NSX-T verranno rimosse al riavvio di NCP.
Problema 2664457: Quando si utilizza DHCP in OpenShift, è possibile che la connettività venga temporaneamente persa quando nsx-node-agent viene avviato o riavviato

nsx-ovs crea e attiva 5 profili di connessione temporanei per configurare ovs_bridge, ma è possibile che l'attivazione di tali profili non riesca temporaneamente in NetworkManager. Di conseguenza, non è presente alcun IP (connettività) nella macchina virtuale in ovs_uplink_port e/o ovs_bridge.

Soluzione: riavviare la macchina virtuale oppure attendere che tutti i profili vengano attivati correttamente da NetworkManager.

Problemi noti

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 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.
Problema 2960121: Per i servizi di tipo LoadBalancer, la connettività ai pod nei nodi di lavoro Windows non riesce se non è configurata correttamente

Per i servizi di tipo LoadBalancer, la connettività ai pod nei nodi di lavoro Windows non riesce se NCP è configurato per l'utilizzo della subnet del segmento LB predefinita. La subnet predefinita 169.254.128.0/22 appartiene allo spazio link-local IPv4 e non viene inoltrata in un nodo Windows.

Soluzione: configurare NCP per l'utilizzo di una subnet del segmento LB non predefinita. A tale scopo, impostare il parametro lb_segment_subnet nella sezione nsx_v3. Si tenga presente che questa operazione avrà effetto solo sui bilanciamenti del carico NSX appena creati.
Problema 2972811: In un ambiente su larga scala, la connessione hyperbus ad alcuni nodi di lavoro è inattiva
In un ambiente su larga scala, la creazione di pod può bloccarsi per 10-15 minuti a causa del timeout del canale RPC. Possono verificarsi i problemi seguenti:
- In un cluster Kubernetes, alcuni pod avranno lo stato ContainerCreating per 10-15 minuti.
- In cfgAgent, il tunnel avrà lo stato COMMUNICATION_ERROR per 10-15 minuti.
- È possibile che nell'interfaccia utente di NSX venga generato un allarme che indica che la connessione hyperbus è inattiva.
Soluzione: non è necessaria. Questo problema viene risolto automaticamente dopo 10-15 minuti.
Problema 2966586: Dopo la migrazione degli oggetti di Manager nel criterio, la creazione dello spazio dei nomi non riesce

Se si crea un blocco di IP in modalità Manager, dopo la migrazione degli oggetti di Manager nel criterio, la creazione dello spazio dei nomi non riesce perché NCP non può allocare subnet da questo blocco di IP.

Soluzione: creare nuovi blocchi di IP in modalità Criterio e configurare NCP per l'utilizzo di questi nuovi blocchi di IP.
Problema 2961789: Dopo la migrazione degli oggetti di Manager nel criterio, non è possibile eliminare alcune delle risorse correlate al pod di controllo dell'integrità

Dopo la migrazione degli oggetti di Manager nel criterio, quando si elimina il pod di controllo dell'integrità, la porta del segmento correlato al pod e il gruppo di destinazione della regola del firewall distribuito non vengono eliminati.

Soluzione: eliminare manualmente tali risorse.
Problema 2923436: Il nome troppo lungo di una risorsa Kubernetes causa un errore
Se il nome di una risorsa Kubernetes è troppo lungo, non è possibile creare la risorsa NSX corrispondente perché il nome della risorsa NSX supererà i limiti per i nomi visualizzati in NSX. Il registro includerà un messaggio di errore come "Errori di convalida a livello del campo: {display_name ipp-k8scl-two-aaaaaa... ha superato la lunghezza massima valida di 255 caratteri}". NSX ha i limiti seguenti:
- Nome visualizzato segmento: 80 caratteri
- Nome gruppo + nome dominio: 245 caratteri
- Nome visualizzato delle altre risorse NSX: 255 caratteri
Soluzione: accorciare il nome della risorsa Kubernetes.
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 2936436: L'interfaccia utente di NSX Manager non include la versione di NCP nella pagina del cluster di container

Quando nell'interfaccia utente di NSX Manager sono visualizzati i cluster di container nella scheda dell'inventario, la versione di NCP non viene visualizzata.

Soluzione: è possibile visualizzare la versione di NCP chiamando l'API /policy/api/v1/fabric/container-clusters.
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 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 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 2868572: Prima di eseguire NCP, è necessario disabilitare Open vSwitch (OVS) nella macchina virtuale host
Per distribuire NCP in una macchina virtuale host, è innanzitutto necessario arrestare i processi relativi a OVS ed eliminare alcuni file nell'host utilizzando i comandi seguenti:
1. sudo systemctl disable openvswitch-switch.service
2. sudo systemctl stop openvswitch-switch.service
3. rm -rf /var/run/openvswitch
Se NCP è già stato distribuito in una macchina virtuale host e OVS non viene eseguito correttamente, eseguire i passaggi seguenti per il ripristino:
1. Eseguire i 3 passaggi precedenti.
2. Eliminare i pod nsx-node-agent nei nodi in cui si verifica il problema per riavviare i pod dell'agente del nodo con il comando "kubectl delete pod $agent-pod -n nsx-system".
Soluzione: vedere sopra.
Problema 2867361: Gli allarmi di nsx-node-agent e hyperbus non vengono rimossi dopo la pulizia di NCP

Se per qualche motivo (ad esempio l'arresto di tutti gli agenti del nodo NSX) vengono visualizzati gli allarmi di nsx-node-agent e hyperbus e si arresta NCP e si esegue lo script di pulizia, gli allarmi rimangono dopo la pulizia.

Soluzione: Nessuna
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 2841030: Con Kubernetes 1.22, lo stato di nsx-node-agent è sempre "AppArmor"

Con Kubernetes 1.22, quando i pod nsx-node-agent sono "Pronti", il loro stato non viene aggiornato da "AppArmor" a "In esecuzione". Ciò non influisce sulla funzionalità di NCP o nsx-node-agent.

Soluzione: riavviare i pod di nsx-node-agent.
Problema 2860091: Il traffico DNS non riesce se baseline_policy_type è impostato su allow_namespace

In un ambiente di OpenShift o Kubernetes, se baseline_policy_type è impostato su allow_namespace, impedirà ai pod (hostNetwork: False) negli altri spazi dei nomi di accedere al servizio DNS.

Soluzione: aggiungere un criterio di rete della regola per consentire il traffico dagli altri pod ai pod DNS.
Problema 2795482: Il pod in esecuzione rimane bloccato nello stato ContainerCreating dopo il riavvio del nodo/hypervisor o qualsiasi altra operazione

Se il flag wait_for_security_policy_sync è true, un pod può passare allo stato ContainerCreating dopo aver avuto lo stato "in esecuzione" per più di un'ora a causa di un riavvio forzato di un nodo di lavoro, un riavvio dell'hypervisor o un altro motivo. Il pod avrà lo stato di creazione per sempre.

Soluzione: eliminare e ricreare il pod.
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 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 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 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 2745904: La funzionalità "Usa set di IP per ASG in esecuzione predefinito" non supporta la rimozione o la sostituzione di un blocco di IP del container esistente

Se si abilita "Usa set di IP per ASG in esecuzione predefinito" in un riquadro di NCP, NCP creerà un elemento NSGroup dedicato per tutti i blocchi di IP del container configurati da "Blocchi di IP reti di container" nello stesso riquadro di NCP. Questo elemento NSGroup verrà utilizzato nelle regole del firewall create per gli ASG in esecuzione globali per consentire il traffico per tutti i container. Se in un secondo momento si rimuove o si sostituisce un blocco di IP del container esistente, verrà rimosso o sostituito in NSGroup. Tutti i container esistenti nel blocco di IP originale non saranno più associati agli ASG in esecuzione globali. È possibile che il loro traffico non funzioni più.

Soluzione: aggiungere nuovi blocchi di IP solo in "Blocchi di IP reti di container".
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 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 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.
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 2579968: Quando vengono apportate modifiche ai servizi Kubernetes di tipo LoadBalancer ad alta frequenza, alcuni server virtuali e pool di server non vengono eliminati come previsto

Quando vengono apportate modifiche ai servizi Kubernetes di tipo LoadBalancer ad alta frequenza, è possibile che alcuni server virtuali e pool di server rimangano nell'ambiente NSX-T anche se devono essere eliminati.

Soluzione: Riavviare NCP. In alternativa, rimuovere manualmente i server virtuali obsoleti e le risorse associate. Un server virtuale è obsoleto se nessun servizio Kubernetes di tipo LoadBalancer dispone dell'identificatore del server virtuale nel tag external_id.
Problema 2597423: Quando si importano oggetti di Manager nel criterio, un rollback causerà la perdita dei tag di alcune risorse
Quando si importano oggetti di Manager nel criterio, se è necessario un rollback, i tag degli oggetti seguenti non verranno ripristinati:
- Profili di spoofguard (parte delle risorse condivise e del cluster)
- BgpneighbourConfig (parte delle risorse condivise)
- BgpRoutingConfig (parte delle risorse condivise)
- StaticRoute BfdPeer (parte delle risorse condivise)
Soluzione: per le risorse che fanno parte delle risorse condivise, ripristinare manualmente i tag. Utilizzare la funzionalità di backup e ripristino per ripristinare le risorse che fanno parte delle risorse del cluster.
Problema 2552564: In un ambiente di OpenShift 4.3, il server di inoltro DNS potrebbe smettere di funzionare se viene trovato un indirizzo sovrapposto

In un ambiente di OpenShift 4.3, l'installazione del cluster richiede la configurazione di un server DNS. Se si utilizza NSX-T per configurare un server di inoltro DNS ed è presente una sovrapposizione dell'indirizzo IP con il servizio DNS, il server di inoltro DNS smetterà di funzionare e l'installazione del cluster non riuscirà.

Soluzione: configurare un servizio DNS esterno, eliminare il cluster la cui installazione non è riuscita e ricreare il cluster.
Problema 2537221: Dopo l'aggiornamento di NSX-T alla versione 3.0, lo stato della rete degli oggetti correlati al container nell'interfaccia utente di NSX Manager viene visualizzato come Sconosciuto

Nell'interfaccia utente di NSX Manager, la scheda Inventario > Container mostra gli oggetti correlati al container e il relativo stato. In un ambiente TKGI, dopo l'aggiornamento di NSX-T alla versione 3.0, lo stato della rete degli oggetti correlati al container viene visualizzato come Sconosciuto. Il problema è causato dal fatto che TKGI non rileva la modifica della versione di NSX-T. Questo problema non si verifica se NCP è in esecuzione come pod e il probe dell'attività è attivo.

Soluzione: dopo l'aggiornamento di NSX-T, riavviare gradualmente le istanze di NCP (non più di 10 contemporaneamente) per non sovraccaricare NSX Manager.
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.
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 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 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.
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 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.