Conversione dei criteri di rete Kubernetes in criteri del firewall distribuito di NSX

Adattatore NSX Antrea sincronizza i criteri di rete Kubernetes dei cluster Antrea Kubernetes registrati con l'inventario di NSX. Tuttavia, questi criteri di rete K8s non possono essere aggiornati o gestiti nell'ambiente NSX.

Se si desidera modificare i criteri di rete K8s in NSX, è possibile importarli nell'ambiente NSX. Questa funzionalità di importazione è disponibile a partire da NSX 4.2 ed è supportata solo con NSX API.

Panoramica dell'importazione dei criteri di rete K8s

L'operazione di importazione converte i criteri di rete K8s in criteri del firewall distribuito (DFW) di NSX con un comportamento del traffico equivalente. Dopo aver convertito i criteri di rete K8s in criteri DFW di NSX, NSX diventa l'origine di riferimento per la gestione dei criteri DFW convertiti. È quindi possibile modificare i criteri DFW utilizzando l'interfaccia utente di NSX Manager o NSX API.

Questa conversione è un'operazione unidirezionale. Non è possibile convertire i criteri DFW di NSX in criteri di rete K8s.

Importante: Se l'inventario di NSX contiene criteri di rete Kubernetes gestiti da NSX Container Plugin (NCP), la funzionalità di importazione non è supportata. I criteri di rete K8s che si desidera importare in NSX devono essere gestiti dalla CNI di Antrea.

Ogni criterio di rete K8s importato viene convertito in uno o due criteri DFW di NSX. Un criterio DFW conterrà tutte le regole di autorizzazione (se nel criterio di rete K8s sono presenti regole di ingresso o uscita) e l'altro criterio DFW conterrà la regola di eliminazione del traffico predefinita. Il criterio DFW con la regola di eliminazione predefinita viene sempre generato.

Il sistema imposta l'estensione (ambito) del criterio DFW di NSX sul cluster Antrea Kubernetes. Inoltre, l'estensione del criterio DFW è ulteriormente limitata al gruppo di Antrea che contiene i membri pod effettivi dello spazio dei nomi Kubernetes.

I criteri DFW convertiti vengono posizionati nel livello Applicazione di NSX. L'API di importazione aggiunge i criteri DFW convertiti dopo gli altri criteri di Antrea esistenti nel livello applicazione. I criteri importati vengono applicati dopo i criteri di Antrea esistenti in NSX ma prima che vengano applicati i criteri di rete del cluster Antrea (ACNP) e i criteri di rete di Antrea (ANP) definiti in modo nativo nel cluster Kubernetes. Il comportamento del traffico originale all'interno dello spazio dei nomi K8s viene mantenuto dopo la conversione nei criteri DFW di NSX.

La CNI di Antrea realizza i criteri DFW convertiti come criteri di rete del cluster Antrea nel cluster Kubernetes. Questi criteri di rete del cluster Antrea sono ora gestiti da NSX e possono essere modificati solo nell'ambiente NSX. Se si tenta di modificare la configurazione di ACNP utilizzando la riga di comando kubectl, Adattatore NSX Antrea sovrascriverà o ripristinerà le modifiche di ACNP alla definizione del criterio originale esistente in NSX.

Dopo aver importato correttamente i criteri di rete K8s in NSX, il sistema elimina automaticamente i criteri di rete Kubernetes originali dall'inventario di K8s. Il sistema contrassegna inoltre i criteri DFW convertiti con il nome del cluster K8s, il criterio di rete K8s originale e lo spazio dei nomi K8s. Questi tag consentono di cercare i criteri DFW convertiti nell'interfaccia utente di NSX Manager. In alternativa, è possibile eseguire il comando kubectl get acnp -o wide nella riga di comando kubectl per visualizzare i tag (ovvero le etichette in K8s) nell'ACNP realizzato corrispondente.

Prerequisiti per l'importazione di criteri di rete K8s

Il cluster Antrea Kubernetes deve essere registrato in NSX 4.2 o versioni successive.
La funzionalità di importazione richiede Antrea-NSX Interworking disponibile con VMware Container Networking™ with Antrea™ 1.9.0 e versioni successive.
Nella distribuzione di NSX applicare una licenza di sicurezza appropriata che autorizzi il sistema a configurare criteri di sicurezza del firewall distribuito.
Si verrà assegnati al ruolo Amministratore aziendale o Amministratore della sicurezza nello spazio predefinito dell'ambiente NSX.
Verificare che Adattatore NSX Antrea abbia segnalato correttamente i criteri di rete Kubernetes all'inventario di NSX.
Ad esempio, per eseguire la verifica nell'interfaccia utente di NSX Manager, eseguire i passaggi seguenti:
1. Passare a Inventario > Container > Spazi dei nomi.
2. Se necessario, filtrare l'elenco degli spazi dei nomi con Tipo di CNI impostato su Antrea.
3. Espandere uno spazio dei nomi e quindi fare clic sul numero di criteri di rete per verificare che i criteri di rete Kubernetes siano sincronizzati con l'inventario di NSX.
  Per verificare se NSX sta leggendo tutti i criteri di rete Kubernetes nello spazio dei nomi, è possibile confrontare il numero indicato nell'interfaccia utente con il numero di criteri recuperati dal comando kubectl seguente. Il numero deve essere uguale.
```
kubectl get networkpolicies -n <namespace>
```

Mappatura dei campi dei criteri di rete K8s ai campi dei criteri del firewall distribuito di NSX

Come indicato in precedenza, quando un criterio di rete Kubernetes viene importato in NSX, il sistema converte questo criterio di rete in uno o due criteri DFW. Un criterio DFW contiene tutte le regole di autorizzazione e l'altro criterio DFW contiene la regola di eliminazione del traffico predefinita. Il sistema crea gruppi di Antrea in base alla specifica del criterio di rete K8s. I gruppi di Antrea vengono utilizzati nei campi Origini, Destinazioni e Si applica a dei criteri DFW convertiti.

La tabella seguente illustra la mappatura dei campi nel criterio di rete Kubernetes ai campi del criterio del firewall distribuito di NSX.

Campo nel criterio di rete K8s	Risorsa di NSX	Descrizione
Criterio di rete K8s stesso	Uno o due criteri DFW	Tutte le regole di `spec.ingress` o `spec.egress` del criterio di rete K8s vengono aggiunte nel criterio "consenti" di DFW. Ciò significa che l'azione della regola per tutte le regole in questo criterio DFW è impostata su Consenti. Viene creato un criterio DFW con regola di eliminazione predefinita con una regola per eliminare il traffico in ingresso, il traffico in uscita o il traffico in ingresso e in uscita in base ai valori nell'elenco `spec.policyTypes` del criterio di rete K8s. Ad esempio, se l'elenco `spec.policyTypes` della specifica del criterio di rete K8s contiene solo `egress`, il criterio "elimina" di DFW avrà una regola di eliminazione predefinita per il traffico in uscita (direzione del traffico: Uscita). Se il criterio di rete Kubernetes non contiene alcuna regola in ingresso o in uscita, viene creato un criterio DFW che include solo la regola di eliminazione predefinita.
`spec.podSelector` e `metadata.namespace`	Gruppo di tipo Antrea	Per la conversione in un gruppo di Antrea vengono utilizzati `spec.podSelector` e `metadata.namespace`. Al gruppo di Antrea creato viene fatto riferimento nel campo Si applica a del criterio "consenti" di DFW e dei criteri "elimina" di DFW. Se `spec.podSelector` non è specificato, il gruppo di Antrea conterrà solo lo spazio dei nomi.
`spec.ingress[]` e `spec.egress[]`	Regole del firewall nel criterio "consenti" di DFW	Ogni regola nelle sezioni `spec.ingress` e `spec.egress` del criterio di rete K8s viene convertita in una regola DFW di NSX. Queste regole DFW vengono aggiunte nel criterio "consenti" di DFW.
`spec.ingress[*].from` `podSelector` `namespaceSelector` `ipBlock`	Gruppi di tipo Antrea	I selettori del pod e dello spazio dei nomi nella sezione `ingress` `from` vengono convertiti in gruppi di Antrea con criteri di appartenenza dinamici. Gli intervalli CIDR IP nel selettore `ipBlock` vengono convertiti in membri di indirizzi IP statici nel gruppo di Antrea. A questi gruppi di Antrea viene fatto riferimento nel campo Origini delle regole DFW.
`spec.egress[*].to` `podSelector` `namespaceSelector` `ipBlock`	Gruppi di tipo Antrea	I selettori del pod e dello spazio dei nomi nella sezione `egress` `to` vengono convertiti in gruppi di Antrea con criteri di appartenenza dinamici. Gli intervalli CIDR IP nel selettore `ipBlock` vengono convertiti in membri di indirizzi IP statici nel gruppo di Antrea. A questi gruppi di Antrea viene fatto riferimento nel campo Destinazioni delle regole DFW.
`spec.ingress[].ports` `protocol` `port` e `spec.egress[].ports` `protocol` `port`	Voci del servizio nella regola DFW	Il protocollo di livello 4 e la porta di destinazione (incluso l'intervallo di porte di destinazione) nella specifica della regola di ingresso e uscita del criterio di rete K8s vengono convertiti in voci Servizio nelle regole DFW. Le porte o l'intervallo di porte di destinazione nella specifica della regola K8s vengono sempre mappati alle porte di destinazione nella voce Servizio.

Esempi di mappature dei campi

Questa sezione include alcuni esempi che consentono di comprendere la mappatura dei campi del criterio di rete Kubernetes ai campi del criterio DFW quando un criterio di rete K8s viene importato in NSX.

Esempio 1

Specifica del criterio di rete K8s:

apiVersion: v1
kind: Namespace
metadata:
  name: my-ns1
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: knp1
  namespace: my-ns1
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 8.8.8.8/32
      ports:
        - protocol: UDP
          port: 53

Questo criterio di rete K8s seleziona tutti i pod nello spazio dei nomi my-ns1 e consente il traffico in uscita (connessioni in uscita) da qualsiasi pod in questo spazio dei nomi al CIDR 8.8.8.8/32 nella porta UDP 53. Tutto l'altro traffico in uscita dai pod in questo spazio dei nomi viene eliminato.

Quando questo criterio di rete K8s viene importato in NSX, vengono creati due criteri DFW. Un criterio DFW contiene una singola regola di autorizzazione e l'altro criterio DFW contiene una singola regola di eliminazione.

La sezione spec.podSelector viene convertita in un gruppo di Antrea con un criterio di appartenenza dinamico. Il criterio nel gruppo seleziona tutti i pod nello spazio dei nomi my-ns1. A questo gruppo di Antrea viene fatto riferimento nel campo Si applica a del criterio di autorizzazione di DFW e del criterio di eliminazione di DFW.

Il selettore ipBlock nella sezione spec.egress.to viene convertito in un gruppo di Antrea con un membro indirizzo IP statico 8.8.8.8/32. A questo gruppo di Antrea viene fatto riferimento nel campo Destinazioni della regola di autorizzazione DFW. Questo gruppo verrà denominato Group-1.

La sezione spec.egress.ports viene convertita in una voce Servizio con protocollo UDP e porta di destinazione 53.

La configurazione della regola di autorizzazione DFW in NSX è la seguente.

Origini	Destinazioni	Servizi	Profili di contesto	Regola applicata a	Azione regola	Direzione regola
N/D	Group-1	UDP Origine: qualsiasi, Destinazione: 53	N/D	Qualsiasi	Consenti	In uscita

Origini

Destinazioni

Servizi

Profili di contesto

Regola applicata a

Azione regola

Direzione regola

N/D

Group-1

UDP

Origine: qualsiasi, Destinazione: 53

N/D

Qualsiasi

Consenti

In uscita

La configurazione della regola di eliminazione DFW in NSX è la seguente.

Origini	Destinazioni	Servizi	Profili di contesto	Regola applicata a	Azione regola	Direzione regola
Qualsiasi	Qualsiasi	Qualsiasi	N/D	Qualsiasi	Elimina	In uscita

Esempio 2

Specifica del criterio di rete K8s:

apiVersion: v1
kind: Namespace
metadata:
  name: my-ns2
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: knp2
  namespace: my-ns2
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Questo criterio di rete Kubernetes seleziona tutti i pod nello spazio dei nomi my-ns2 ed elimina tutto il traffico in ingresso e in uscita da questi pod. Questo criterio crea in pratica una regola di eliminazione predefinita per tutto il traffico in ingresso e in uscita per lo spazio dei nomi.

Quando questo criterio di rete K8s viene importato in NSX, viene creato un solo criterio di eliminazione DFW. Il criterio DFW convertito contiene una singola regola del firewall con azione di eliminazione.

La sezione spec.podSelector viene convertita in un gruppo di Antrea con un criterio di appartenenza dinamico. Il criterio nel gruppo seleziona tutti i pod nello spazio dei nomi my-ns2. A questo gruppo di Antrea viene fatto riferimento nel campo Si applica a del criterio di eliminazione DFW.

La configurazione della regola di eliminazione DFW in NSX è la seguente.

Origini	Destinazioni	Servizi	Profili di contesto	Regola applicata a	Azione regola	Direzione regola
Qualsiasi	Qualsiasi	Qualsiasi	N/D	Qualsiasi	Elimina	Ingresso, Uscita

Convenzione di denominazione dei criteri DFW convertiti e dei gruppi di Antrea

Il sistema utilizza la convenzione di denominazione seguente per i criteri di autorizzazione ed eliminazione DFW convertiti:

Criterio di autorizzazione DFW: <cluster_name>-<namespace>-<K8s_networkpolicy_name>-<K8s_networkpolicy_uuid>-allow
Criterio di eliminazione DFW: <cluster_name>-<namespace>-<K8s_networkpolicy_name>-<K8s_networkpolicy_uuid>-drop

I valori di cluster_name, namespace e K8s_networkpolicy_name vengono troncati a 12 byte ciascuno.

Il sistema utilizza la convenzione di denominazione seguente per i gruppi di Antrea:

Gruppi a cui si fa riferimento nel campo Si applica a dei criteri di autorizzazione ed eliminazione DFW: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>
Gruppi a cui si fa riferimento nel campo Origini delle regole DFW: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>-rule[rule index]-from-<peer index>
Gruppi a cui si fa riferimento nel campo Destinazioni delle regole DFW: <cluster_name>-<namespace>-<K8s_networkpolicy_uuid>-rule[rule index]-to-<peer index>

I valori di cluster_name e namespace vengono troncati a 12 byte ciascuno.

Per comprendere in che modo il sistema assegna valori all'indice della regola e all'indice peer nel nome del gruppo di Antrea, si consideri l'esempio seguente di un criterio di rete K8s che contiene tre regole di ingresso.

Esempio

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: knp3
  namespace: my-ns3
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns1"]
        - podSelector:
            matchExpressions:
            - key: app
              operator: In
              values: ["nginx"]
      ports:
        - protocol: TCP
          port: 80
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: [""]
      ports:
        - protocol: TCP
          port: 443
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns4"]
      ports:
        - protocol: TCP
          port: 8080
          endPort: 8090

Si consideri il frammento della prima regola ingress.from, come segue:

ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns1"]
        - podSelector:
            matchExpressions:
            - key: app
              operator: In
              values: ["nginx"]
      ports:
        - protocol: TCP
          port: 80

La sezione from in questa regola di ingresso contiene due elementi. Un elemento seleziona i pod utilizzando il selettore dello spazio dei nomi, mentre l'altro elemento seleziona i pod utilizzando il selettore di pod. Questi due elementi vengono chiamati peer.

Il sistema crea un gruppo di Antrea per ogni peer nella regola. La regola DFW convertita ha l'indice della regola 0 e questa regola contiene due gruppi di Antrea nel campo Origini della regola. Il nome di un gruppo di Antrea ha l'indice del peer 0, mentre il nome dell'altro gruppo ha l'indice del peer 1, come indicato di seguito:

<cluster_name>-my-ns3-knp3-rule[0]-from-0

<cluster_name>-my-ns3-knp3-rule[0]-from-1

Ora si consideri il frammento della seconda e della terza regola ingress.from, come indicato di seguito:

ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: [""]
      ports:
        - protocol: TCP
          port: 443
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: namespace
              operator: In
              values: ["test-ns4"]
      ports:
        - protocol: TCP
          port: 8080
          endPort: 8090

La sezione from in ciascuna di queste due regole di ingresso contiene un solo elemento che seleziona i pod utilizzando il selettore dello spazio dei nomi. Le regole DFW convertite hanno gli indici della regola 1 e 2 rispettivamente e ogni regola contiene un singolo gruppo di Antrea nel campo Origini della regola. In questo caso, l'indice del peer non viene aggiunto ai nomi dei gruppi di Antrea. I nomi dei gruppi sono i seguenti:

<cluster_name>-my-ns3-knp3-rule[1]-from

<cluster_name>-my-ns3-knp3-rule[2]-from

Informazioni generali sul workflow di importazione tramite API

Assicurarsi che siano soddisfatti i prerequisiti per l'importazione dei criteri di rete Kubernetes, elencati in precedenza in questa documentazione.
Eseguire il comando kubectl seguente per visualizzare l'elenco dei criteri di rete Kubernetes in un determinato spazio dei nomi:
```
kubectl get networkpolicies -n <namespace>
```
Ad esempio:
```
kubectl get networkpolicies -n test-ns5

NAME     POD-SELECTOR   AGE
k-np10   app=demo       82m
k-np11   app=myapp      82m
k-np12   app=demo       82m
k-np9    app=myapp      82m
```
In questo esempio, lo spazio dei nomi test-ns5 contiene quattro criteri di rete Kuberentes. In questa procedura, i criteri "k-np9" e "k-np11" verranno importati in NSX.
Eseguire il comando kubectl seguente per recuperare l'ID di ogni criterio di rete Kubernetes che si desidera importare.
```
kubectl get networkpolicies <policy-name> -n <namespace> -o yaml
```
Ad esempio, per recuperare gli ID dei criteri di rete "k-np9" e "k-np11", eseguire i comandi seguenti:
```
kubectl get networkpolicies k-np9 -n test-ns5 -o yaml
kubectl get networkpolicies k-np11 -n test-ns5 -o yaml
```
Nell'output di entrambi i comandi kubectl, prendere nota dell'ID visualizzato nel campo metadata.uid. Nel cluster K8s, gli ID dei criteri sono i seguenti:
- Per k-np9: e5a59ae6-cc0e-42a5-80bd-f6fa13b5b70d
- Per k-np11: 84b850fb-69ad-4e95-a563-a95ce6b70557
Questi ID dei criteri sono solo a scopo esemplificativo. È possibile che nel cluster K8s in uso siano diversi. Questi ID dei criteri saranno necessari per eseguire l'API di importazione, come illustrato nel passaggio successivo.

Eseguire la seguente NSX API per importare i criteri di rete Kubernetes:

Ad esempio:

POST https://<nsx-mgr>/policy/api/v1/infra/import-k8s-np-to-dfw?on_error=ABORT  -k
{
    "network_policy_ids" : ["e5a59ae6-cc0e-42a5-80bd-f6fa13b5b70d", "84b850fb-69ad-4e95-a563-a95ce6b70557"],
    "sequence_number_upper" : 1000,
    "sequence_number_lower" : 2000
}

Il parametro network_policy_ids è obbligatorio, mentre i parametri sequence_number_upper e sequence_number_lower sono facoltativi.

In questo esempio, gli ID dei criteri di rete K8s (k-np9 e k-np11) vengono specificati per l'importazione in NSX.

Per informazioni dettagliate su questi parametri di richiesta, sulla richiesta di esempio dell'API e sulla risposta di esempio dell'API, vedere Guida di NSX API.

Il parametro della query on_error determina l'azione che l'API deve eseguire quando si verifica un errore. La tabella seguente illustra i valori validi di questo parametro di query.

Valore	Descrizione
TERMINA	Questo è il valore predefinito. Se si verifica un errore durante l'importazione dei criteri di rete K8s, il sistema impedirà il commit di tutti i criteri DFW e dei gruppi di Antrea convertiti. L'operazione di importazione verrà terminata prematuramente e nessuno dei criteri di rete K8s verrà convertito. La risposta dell'API restituirà il messaggio di errore per ogni criterio di rete K8s che ha causato un errore. Esempio: Si supponga di aver specificato gli UUID per due criteri di rete K8s, ad esempio knp1 e knp2, nel corpo della richiesta API. Il criterio knp1 contiene il protocollo SCTP non supportato nella specifica di una regola di uscita. Quando si esegue l'API di importazione, la conversione del criterio di rete knp1 genera un errore e l'operazione di importazione viene terminata prematuramente. Il sistema non converte il criterio di rete K8s successivo (knp2), anche se questo criterio di rete è valido.
CONTINUA	Se si verifica un errore durante l'importazione del criterio di rete K8s corrente, il sistema ignora questo criterio e continua importando il criterio di rete K8s successivo. La risposta dell'API restituisce il messaggio di errore per ogni criterio di rete K8s che è stato ignorato durante l'operazione di importazione. Attenzione: È possibile che si verifichi una modifica del comportamento del traffico se i criteri di rete K8s importati e i criteri di rete K8s ignorati sono applicati allo stesso pod. Esempio: Continuando con lo stesso esempio, indicato nella riga precedente, quando l'importazione del criterio di rete knp1 genera un errore, il sistema continua a importare il criterio di rete knp2 e lo converte correttamente. La risposta dell'API restituisce lo stesso messaggio di errore per il criterio di rete knp1, che non è riuscito durante la conversione.

Valore

Descrizione

TERMINA

Questo è il valore predefinito.

Se si verifica un errore durante l'importazione dei criteri di rete K8s, il sistema impedirà il commit di tutti i criteri DFW e dei gruppi di Antrea convertiti. L'operazione di importazione verrà terminata prematuramente e nessuno dei criteri di rete K8s verrà convertito. La risposta dell'API restituirà il messaggio di errore per ogni criterio di rete K8s che ha causato un errore.

Esempio:

Si supponga di aver specificato gli UUID per due criteri di rete K8s, ad esempio knp1 e knp2, nel corpo della richiesta API. Il criterio knp1 contiene il protocollo SCTP non supportato nella specifica di una regola di uscita. Quando si esegue l'API di importazione, la conversione del criterio di rete knp1 genera un errore e l'operazione di importazione viene terminata prematuramente. Il sistema non converte il criterio di rete K8s successivo (knp2), anche se questo criterio di rete è valido.

CONTINUA

Se si verifica un errore durante l'importazione del criterio di rete K8s corrente, il sistema ignora questo criterio e continua importando il criterio di rete K8s successivo. La risposta dell'API restituisce il messaggio di errore per ogni criterio di rete K8s che è stato ignorato durante l'operazione di importazione.

Attenzione: È possibile che si verifichi una modifica del comportamento del traffico se i criteri di rete K8s importati e i criteri di rete K8s ignorati sono applicati allo stesso pod.

Esempio:

Continuando con lo stesso esempio, indicato nella riga precedente, quando l'importazione del criterio di rete knp1 genera un errore, il sistema continua a importare il criterio di rete knp2 e lo converte correttamente. La risposta dell'API restituisce lo stesso messaggio di errore per il criterio di rete knp1, che non è riuscito durante la conversione.

I criteri di rete K8s importati in una singola richiesta API possono appartenere a diversi cluster Antrea Kubernetes registrati. Oppure possono appartenere a più spazi dei nomi all'interno di un singolo cluster Antrea Kubernetes.

Se uno spazio dei nomi include più criteri di rete K8s, è consigliabile importarli in una singola richiesta API. Il motivo consiste nel fatto che i criteri di rete K8s all'interno di uno spazio dei nomi possono essere correlati tra loro. Questa procedura consente di assicurarsi che il comportamento del traffico non cambi dopo l'importazione dei criteri di rete in NSX.

Una volta completata l'importazione, passare all'interfaccia utente di NSX Manager e visualizzare la configurazione dei gruppi di Antrea e dei criteri DFW.
Facoltativo: visualizzare i criteri di rete del cluster Antrea realizzati, quindi controllare le specifiche ACNP e le specifiche ClusterGroup eseguendo i comandi kubectl seguenti:
```
kubectl get acnp
```
```
kubectl get acnp <acnp-id> -o yaml
```
```
kubectl get cg <cg-id> -o yaml
```
Facoltativo: verificare che i criteri di rete K8s importati correttamente in NSX non siano presenti nel cluster K8s eseguendo il comando kubectl seguente:
```
kubectl get networkpolicies -n <namespace>
```
Per l'esempio illustrato qui, il comando è il seguente:
```
kubectl get networkpolicies -n test-ns5

NAME     POD-SELECTOR   AGE
k-np10   app=demo       84m
k-np12   app=demo       84m
```
Si tenga presente che i criteri di rete Kubernetes importati (k-np9 e k-np11) non sono più presenti nel cluster K8s.

Funzionalità dei criteri di rete Kubernetes non supportate

Alcune funzionalità dei criteri di rete Kubernetes non sono attualmente supportate per la conversione in criteri DFW di NSX e in gruppi di Antrea. La risposta dell'API include un messaggio di errore appropriato quando la conversione non riesce a causa di una delle seguenti funzionalità non supportate.

I criteri di rete K8s che utilizzano nomi di porta di livello 4 per i pod non vengono convertiti. I criteri DFW supportano solo numeri di porta.
I criteri di rete K8s che contengono il protocollo SCTP non vengono convertiti. I criteri DFW di NSX non supportano il traffico SCTP.
I criteri di rete K8s possono avere un numero notevole di matchLabels o matchExpressions nella sezione podSelector o NetworkPolicyPeer. Tuttavia, il criterio di appartenenza dinamico in un gruppo di Antrea può supportare al massimo 15 condizioni con tipi di membri misti e 5 condizioni con lo stesso tipo di membro. Quando questo limite massimo viene superato in un criterio di appartenenza al gruppo, la conversione non riesce.
I criteri di rete Kubernetes che contengono matchExpressions con l'operatore DoesNotExist non vengono convertiti in gruppi di Antrea. L'operatore DoesNotExist in Kubernetes viene mappato al valore NotEquals per l'operatore dell'ambito in NSX. Tuttavia, l'operatore dell'ambito in una definizione di gruppo di Antrea attualmente non supporta questo valore.
I criteri di rete Kubernetes che contengono matchExpressions con l'operatore In devono contenere solo un singolo valore affinché la conversione riesca. Più valori nell'operatore In non sono attualmente supportati per la conversione in gruppi di Antrea.

Comportamento con versioni di Adattatore NSX Antrea diverse

È possibile aggiornare Adattatore NSX Antrea e NSX separatamente e in qualsiasi ordine. Le nuove modifiche apportate in Adattatore NSX Antrea sono compatibili con le versioni di NSX precedenti alla 4.2.

Si consideri il seguente scenario:

La versione dell'ambiente NSX è 4.2 e include più cluster Antrea Kubernetes registrati. Alcuni cluster Kubernetes dispongono della nuova versione di Adattatore NSX Antrea (ad esempio v0.15), mentre alcuni cluster hanno una versione precedente di Adattatore NSX Antrea (ad esempio v0.11). In questo caso, la versione precedente di Adattatore NSX Antrea non eliminerà automaticamente i criteri di rete Kubernetes originali dal cluster Kubernetes dopo la conversione. L'amministratore o l'amministratore dello spazio dei nomi di Kubernetes deve eliminare manualmente i criteri di rete Kubernetes originali. Si tenga presente che la conversione in criteri DFW viene comunque eseguita. I criteri di autorizzazione DFW convertiti e i criteri di eliminazione predefiniti vengono realizzati come criteri di rete del cluster Antrea nel cluster Kubernetes e vengono valutati dalla CNI di Antrea prima dei criteri di rete Kubernetes originali. Se i criteri Kubernetes originali non vengono eliminati dal cluster Kubernetes, il comportamento del traffico definito nei criteri DFW convertiti potrebbe essere in conflitto con i criteri di rete Kubernetes originali.