Convertir directivas de red de Kubernetes en directivas de firewall distribuido de NSX

Adaptador de NSX Antrea sincroniza las directivas de red de Kubernetes de los clústeres de Antrea Kubernetes registrados con el inventario de NSX. Sin embargo, estas directivas de red de K8s no se pueden actualizar ni administrar en el entorno de NSX.

Si desea editar las directivas de red de K8s en NSX, puede importarlas al entorno de NSX. Esta funcionalidad de importación está disponible a partir de NSX 4.2 y solo se admite con la API de NSX.

Descripción general de la importación de directivas de red de K8s

La operación de importación convierte las directivas de red de K8s a directivas de firewall distribuido (DFW) de NSX con un comportamiento de tráfico equivalente. Una vez que las directivas de red de K8s se convierten en directivas de DFW de NSX, NSX se convierte en la fuente de la verdad para administrar las directivas de DFW convertidas. A continuación, puede editar las directivas de DFW mediante la interfaz de usuario de NSX Manager o la API de NSX.

Esta conversión es una operación unidireccional. No se pueden volver a convertir las directivas de DFW de NSX en directivas de red de K8s.

Importante: Si el inventario de NSX contiene directivas de red de Kubernetes administradas por NSX Container Plugin (NCP), no se admitirá la funcionalidad de importación. Las directivas de red de K8s que se importen a NSX deben estar administradas por la CNI de Antrea.

Cada directiva de red de K8s importada se convertirá en una o dos directivas de DFW de NSX. Una directiva de DFW contendrá todas las reglas de permiso (si existen reglas de entrada o salida en la directiva de red de K8s), y la otra directiva de DFW contendrá la regla de descarte de tráfico predeterminada. Siempre se genera la directiva de DFW con la regla de descarte predeterminada.

El sistema establece el alcance (ámbito) de la directiva de DFW de NSX en el clúster de Antrea Kubernetes. Además, la extensión de la directiva de DFW se limita aún más al grupo de Antrea que contiene los miembros efectivos del pod del espacio de nombres de Kubernetes.

Las directivas de DFW convertidas se colocan en el nivel aplicación de NSX. La API de importación anexa las directivas de DFW convertidas después de otras directivas de Antrea existentes en el nivel de aplicación. Las directivas importadas se aplican después de que se apliquen las directivas de Antrea existentes en NSX, pero antes de que se apliquen las directivas de red de clúster de Antrea (ACNP) y las directivas de red de Antrea (ANP), que se definen de forma nativa en el clúster de Kubernetes. El comportamiento del tráfico original dentro del espacio de nombres de K8s se conserva después de la conversión a directivas de DFW de NSX.

La CNI de Antrea realiza las directivas de DFW convertidas como directivas de red del clúster de Antrea en el clúster de Kubernetes. Estas directivas de red del clúster de Antrea ahora las administra NSX, y solo se pueden editar en el entorno de NSX. Si intenta editar la configuración de ACNP mediante la línea de comandos de kubectl, Adaptador de NSX Antrea sobrescribirá o revertirá los cambios de ACNP a la definición de directiva original tal como existe en NSX.

Una vez que las directivas de red de K8s se importen correctamente a NSX, el sistema eliminará automáticamente las directivas de red de Kubernetes originales del inventario de K8s. El sistema también etiquetará las directivas de DFW convertidas con el nombre del clúster de K8s, la directiva de red de K8s original y el espacio de nombres de K8s. Estas etiquetas le permitirán buscar las directivas de DFW convertidas en la interfaz de usuario de NSX Manager. Como alternativa, puede ejecutar el comando kubectl get acnp -o wide en la línea de comandos de kubectl para ver las etiquetas (es decir, etiquetas en K8s) en el ACNP realizado correspondiente.

Requisitos previos para importar directivas de red de K8s

El clúster de Antrea Kubernetes debe estar registrado en NSX 4.2 o una versión posterior.
La funcionalidad de importación requiere una versión de interoperabilidad de Antrea-NSX que esté disponible con VMware Container Networking™ with Antrea™ 1.9.0 o versiones posteriores.
Aplique una licencia de seguridad adecuada en su implementación de NSX que autorice al sistema a configurar directivas de seguridad de firewall distribuido.
Se le asignará la función de administrador empresarial o de administrador de seguridad en el espacio predeterminado de su entorno de NSX.
Compruebe que Adaptador de NSX Antrea notificó correctamente las directivas de red de Kubernetes al inventario de NSX.
Por ejemplo, para comprobarlo en la interfaz de usuario de NSX Manager, siga estos pasos:
1. Desplácese hasta Inventario > Contenedores > Espacios de nombres.
2. Si es necesario, filtre la lista de espacios de nombres con Tipo de CNI como Antrea.
3. Expanda un espacio de nombres y, a continuación, haga clic en el recuento de directivas de red para comprobar si las directivas de red de Kubernetes están sincronizadas con el inventario de NSX.
  Para comprobar si NSX está leyendo todas las directivas de red de Kubernetes en el espacio de nombres, puede comparar el recuento en la interfaz de usuario con el número de directivas que recupera el siguiente comando de kubectl. El recuento debe ser el mismo.
```
kubectl get networkpolicies -n <namespace>
```

Asignación de campos de directiva de red de K8s a campos de directiva de firewall distribuido de NSX

Como se explicó anteriormente, cuando se importa una directiva de red de Kubernetes a NSX, el sistema convierte esta directiva de red en una o dos directivas de DFW. Una directiva de DFW contiene todas las reglas de permiso, y la otra directiva de DFW contiene la regla de tráfico de descartes predeterminada. El sistema crea grupos de Antrea según la especificación de la directiva de red de K8s. Los grupos de Antrea se utilizan en los campos Orígenes, Destinos y Se aplica a de las directivas de DFW convertidas.

En la siguiente tabla se explica la asignación de los campos de la directiva de red de Kubernetes a los campos de la directiva de firewall distribuido de NSX.

Campo en la directiva de red de K8s	Recurso de NSX	Descripción
Directiva de red de K8s en sí	Una o dos directivas de DFW	Todas las reglas de `spec.ingress` o `spec.egress` de la directiva de red de K8s se agregan a la directiva "permitir" de DFW. Es decir, la acción de la regla para todas las reglas de esta directiva de DFW se establece en permitir. Se crea una directiva de DFW con una regla de descarte predeterminada con una regla para descartar el tráfico de entrada, el tráfico de salida o el tráfico de entrada y salida, según los valores de la lista `spec.policyTypes` de la directiva de red de K8s. Por ejemplo, si la lista `spec.policyTypes` de la especificación de la directiva de red de K8s contiene solo `egress`, la directiva "descartar" de DFW tendrá una regla de descarte predeterminada para el tráfico de salida (dirección de tráfico: saliente). Si la directiva de red de Kubernetes no contiene ninguna regla de entrada y salida, se creará una directiva de DFW con solo la regla de descarte predeterminada.
`spec.podSelector` y `metadata.namespace`	Grupo de tipo Antrea	Tanto `spec.podSelector` como `metadata.namespace` se utilizan para convertir en un grupo de Antrea. Se hace referencia al grupo de Antrea en Se aplica a de la directiva "permitir" de DFW y "descartar" de DFW. Si no se especifica `spec.podSelector`, el grupo de Antrea solo contendrá el espacio de nombres.
`spec.ingress[]` y `spec.egress[]`	Reglas de firewall en la directiva "permitir" de DFW	Cada regla de las secciones `spec.ingress` y `spec.egress` de la directiva de red de K8s se convierte en una regla de DFW de NSX. Estas reglas de DFW se agregan a la directiva "permitir" de DFW.
`spec.ingress[*].from` `podSelector` `namespaceSelector` `ipBlock`	Grupos de tipo Antrea	Los selectores de espacio de nombres y pod de la sección `ingress` `from` se convierten en grupos de Antrea con criterios de pertenencia dinámica. Los rangos de CIDR de IP del selector `ipBlock` se convierten en miembros de direcciones IP estáticas en el grupo de Antrea. Se hace referencia a este grupo de Antrea en el campo Orígenes de las reglas de DFW.
`spec.egress[*].to` `podSelector` `namespaceSelector` `ipBlock`	Grupos de tipo Antrea	Los selectores de espacio de nombres y pod de la sección `egress` `to` se convierten en grupos de Antrea con criterios de pertenencia dinámica. Los rangos de CIDR de IP del selector `ipBlock` se convierten en miembros de direcciones IP estáticas en el grupo de Antrea. Se hace referencia a este grupo de Antrea en el campo Destinos de las reglas de DFW.
`spec.ingress[].ports` `protocol` `port` y `spec.egress[].ports` `protocol` `port`	Entradas de servicio en la regla de DFW	El protocolo de capa 4 y el puerto de destino (incluido el rango de puertos de destino) en la especificación de reglas de entrada y salida de la directiva de red de K8s se convierten en entradas de Servicio en las reglas de DFW. Los puertos de destino o el rango de puertos en la especificación de regla de K8s siempre se asignan a los puertos de destino en la entrada Servicio.

Ejemplos de asignaciones de campos

Esta sección incluye algunos ejemplos para ayudarle a comprender la asignación de campos en la directiva de red de Kubernetes con los campos de la directiva de DFW cuando se importa una directiva de red de K8s a NSX.

Ejemplo 1

Especificación de directiva de red de 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

Esta directiva de red de K8s selecciona todos los pods del espacio de nombres my-ns1 y permite el tráfico de salida (conexiones salientes) desde cualquier pod de este espacio de nombres hasta CIDR 8.8.8.8/32 en el puerto UDP 53. Se descarta el resto del tráfico de salida de los pods de este espacio de nombres.

Cuando esta directiva de red de K8s se importa a NSX, se crean dos directivas de DFW. Una directiva de DFW contiene una sola regla de permiso, y la otra directiva de DFW contiene una sola regla de descarte.

La sección spec.podSelector se convierte en un grupo de Antrea con un criterio de pertenencia dinámica. El criterio del grupo selecciona todos los pods del espacio de nombres my-ns1. Se hace referencia a este grupo de Antrea en el campo Se aplica a de la directiva de permiso de DFW y la directiva de descarte de DFW.

El selector ipBlock de la sección spec.egress.to se convierte en un grupo de Antrea con un miembro de dirección IP estática 8.8.8.8/32. Se hace referencia a este grupo de Antrea en el campo Destinos de la regla de permiso de DFW. Vamos a referirnos a este grupo como Grupo-1.

La sección spec.egress.ports se convierte en una entrada de Servicio con el protocolo UDP y el puerto de destino 53.

La configuración de la regla de permiso de DFW en NSX es la siguiente.

Orígenes	Destinos	Servicios	Perfiles de contexto	Aplicación de regla	Acción de regla	Dirección de regla
N/C	Grupo-1	UDP Origen: Cualquiera \| Destino: 53	N/C	Cualquiera	Permitir	Salida

Orígenes

Destinos

Servicios

Perfiles de contexto

Aplicación de regla

Acción de regla

Dirección de regla

N/C

Grupo-1

UDP

Origen: Cualquiera | Destino: 53

N/C

Cualquiera

Permitir

Salida

La configuración de la regla de descarte de DFW en NSX es la siguiente.

Orígenes	Destinos	Servicios	Perfiles de contexto	Aplicación de regla	Acción de regla	Dirección de regla
Cualquiera	Cualquiera	Cualquiera	N/C	Cualquiera	Descartar	Salida

Ejemplo 2

Especificación de directiva de red de 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

Esta directiva de red de Kubernetes selecciona todos los pods del espacio de nombres my-ns2 y descarta todo el tráfico de entrada y de salida de estos pods. Básicamente, esta directiva crea un tráfico de descarte predeterminado de todo el tráfico de entrada y salida para el espacio de nombres.

Cuando esta directiva de red de K8s se importa a NSX, solo se crea una directiva de descarte de DFW. La directiva de DFW convertida contiene una sola regla de firewall con acción de descarte.

La sección spec.podSelector se convierte en un grupo de Antrea con un criterio de pertenencia dinámica. El criterio del grupo selecciona todos los pods del espacio de nombres my-ns2. Se hace referencia a este grupo de Antrea en el campo Se aplica a de la directiva de descarte de DFW.

La configuración de la regla de descarte de DFW en NSX es la siguiente.

Orígenes	Destinos	Servicios	Perfiles de contexto	Aplicación de regla	Acción de regla	Dirección de regla
Cualquiera	Cualquiera	Cualquiera	N/C	Cualquiera	Descartar	In_Out

Convención de nomenclatura de los grupos de Antrea y las directivas de DFW convertidas

El sistema utiliza la siguiente convención de nomenclatura para las directivas de permiso y descarte de DFW convertidas:

Directiva de permiso de DFW: <nombre_clúster>-<espacio de nombres>-<nombre_directiva de red_K8s>-<uuid_directiva de red_K8s>-allow
Directiva de descarte de DFW: <nombre_clúster>-<espacio de nombres>-<nombre_directiva de red_K8s>-<uuid_directiva de red_K8s>-drop

Los valores de nombre_clúster, espacio de nombres y nombre_directiva de red_K8s se truncan a los 12 bytes cada uno.

El sistema utiliza la siguiente convención de nomenclatura para los grupos de Antrea:

Grupos a los que se hace referencia en el campo Se aplica a de las directivas de permiso y descarte de DFW: <nombre_clúster>-<espacio de nombres>-<uuid_directiva de red_K8s>
Grupos a los que se hace referencia en el campo Orígenes de las reglas de DFW: <nombre_clúster>-<espacio de nombres>-<uuid_directiva de red_K8s>-rule[rule index]-from-<índice del mismo nivel>
Grupos a los que se hace referencia en el campo Destinos de las reglas de DFW: <nombre_clúster>-<espacio de nombres>-<uuid_directiva de red_K8s>-rule[rule index]-to-<índice del mismo nivel>

Los valores de nombre_clúster y espacio de nombres se truncan a los 12 bytes cada uno.

Para comprender cómo el sistema asigna valores al índice de reglas y al índice del mismo nivel en el nombre de grupo de Antrea, tenga en cuenta el siguiente ejemplo de una directiva de red de K8s que contiene tres reglas de entrada.

Ejemplo

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

Consideremos el fragmento de la primera regla ingress.from de la siguiente manera:

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 sección from de esta regla de entrada contiene dos elementos. Un elemento selecciona pods mediante el selector de espacio de nombres y el otro selecciona los pods mediante el selector de pods. Nos referimos a estos dos elementos como elementos del mismo nivel.

El sistema crea un grupo de Antrea para cada elemento del mismo nivel en la regla. La regla de DFW convertida tiene el índice de regla 0, y esta regla contiene dos grupos de Antrea en el campo Orígenes de la regla. Un nombre de grupo de Antrea tiene un índice del mismo nivel 0 y el otro tiene un índice del mismo nivel 1, como se indica a continuación:

<nombre_clúster>-my-ns3-knp3-rule[0]-from-0

<nombre_clúster>-my-ns3-knp3-rule[0]-from-1

Ahora, tenga en cuenta el fragmento de las reglas del segundo y tercer ingress.from, como se indica a continuación:

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 sección from de cada una de estas dos reglas de entrada contiene solo un elemento que selecciona los pods mediante el selector de espacio de nombres. Las reglas de DFW convertidas tienen los índices de regla 1 y 2 respectivamente, y cada regla contiene un único grupo de Antrea en el campo Orígenes de la regla. En este caso, el índice del mismo nivel no se anexa a los nombres de los grupos de Antrea. Las funciones disponibles son las siguientes:

<nombre_clúster>-my-ns3-knp3-rule[1]-from

<nombre_clúster>-my-ns3-knp3-rule[2]-from

Flujo de trabajo de importación de alto nivel mediante la API

Asegúrese de cumplir los requisitos previos para importar las directivas de red de Kubernetes, como se explicó anteriormente en esta documentación.
Ejecute el siguiente comando de kubectl para ver la lista de directivas de red de Kubernetes en un espacio de nombres determinado:
```
kubectl get networkpolicies -n <namespace>
```
Por ejemplo:
```
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
```
En este ejemplo, el espacio de nombres test-ns5 contiene cuatro directivas de red de Kubernetes. En este procedimiento, importaremos las políticas "k-np9" y "k-np11" a NSX.
Ejecute el siguiente comando de kubectl para recuperar el identificador de cada directiva de red de Kubernetes que desee importar.
```
kubectl get networkpolicies <policy-name> -n <namespace> -o yaml
```
Por ejemplo, para recuperar los identificadores de las directivas de red "k-np9" y "k-np11", ejecute estos comandos:
```
kubectl get networkpolicies k-np9 -n test-ns5 -o yaml
kubectl get networkpolicies k-np11 -n test-ns5 -o yaml
```
En el resultado de ambos comandos de kubectl, observe el identificador que ve en el campo metadata.uid. En nuestro clúster de K8s, los identificadores de directiva son los siguientes:
- Para k-np9: e5a59ae6-cc0e-42a5-80bd-f6fa13b5b70d
- Para k-np11: 84b850fb-69ad-4e95-a563-a95ce6b70557
Estos identificadores de directivas son solo ejemplos. Pueden ser diferentes en su clúster de K8s. Necesitará estos identificadores de directiva para ejecutar la API de importación, que se explica en el siguiente paso.

Ejecute la siguiente API de NSX para importar las directivas de red de Kubernetes:

Por ejemplo:

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
}

El parámetro network_policy_ids es obligatorio, mientras que los parámetros sequence_number_upper y sequence_number_lower son opcionales.

En este ejemplo, se especifican los identificadores de las directivas de red de K8s (k-np9 y k-np11) para importarlos a NSX.

Para obtener información detallada sobre estos parámetros de solicitud, la solicitud de ejemplo de API y la respuesta de ejemplo de API, consulte la Guía de NSX API.

El parámetro de consulta on_error determina la acción que debe realizar la API cuando se produce un error. En la siguiente tabla, se explican los valores válidos de este parámetro de consulta.

Valor	Descripción
ANULAR	Este valor es el predeterminado. Si se produce un error al importar las directivas de red de K8s, el sistema evitará que se asignen todos los grupos de Antrea y las directivas de DFW convertidas. La operación de importación finaliza antes de tiempo y no se convierte ninguna de las directivas de red de K8s. La respuesta de la API devuelve el mensaje de error para cada directiva de red de K8s que generó un error. Ejemplo: Supongamos que especifica los UUID de dos directivas de red de K8s (por ejemplo, knp1 y knp2) en el cuerpo de la solicitud de API. La directiva knp1 contiene el protocolo SCTP no admitido en una especificación de regla de salida. Cuando se ejecuta la API de importación, la conversión de la directiva de red knp1 genera un error y la operación de importación finaliza antes de tiempo. El sistema no convierte la siguiente directiva de red de K8s (knp2), aunque sea válida.
CONTINUAR	Si se produce un error al importar la directiva de red de K8s actual, el sistema omitirá esta directiva y continuará importando la siguiente directiva de red de K8s. La respuesta de la API devuelve el mensaje de error para cada directiva de red de K8s que se omitió durante la operación de importación. Precaución: Se puede esperar un cambio en el comportamiento del tráfico si las directivas de red de K8s importadas y las directivas de red de K8s omitidas se aplican al mismo pod. Ejemplo: Continuando con el mismo ejemplo, como se mencionó en la fila anterior. Cuando se produce un error en la importación de la directiva de red knp1, el sistema continúa importando la directiva de red knp2 y convierte esta directiva de red correctamente. La respuesta de la API devuelve el mismo mensaje de error para la directiva de red de knp1, que falló durante la conversión.

Valor

Descripción

ANULAR

Este valor es el predeterminado.

Si se produce un error al importar las directivas de red de K8s, el sistema evitará que se asignen todos los grupos de Antrea y las directivas de DFW convertidas. La operación de importación finaliza antes de tiempo y no se convierte ninguna de las directivas de red de K8s. La respuesta de la API devuelve el mensaje de error para cada directiva de red de K8s que generó un error.

Ejemplo:

Supongamos que especifica los UUID de dos directivas de red de K8s (por ejemplo, knp1 y knp2) en el cuerpo de la solicitud de API. La directiva knp1 contiene el protocolo SCTP no admitido en una especificación de regla de salida. Cuando se ejecuta la API de importación, la conversión de la directiva de red knp1 genera un error y la operación de importación finaliza antes de tiempo. El sistema no convierte la siguiente directiva de red de K8s (knp2), aunque sea válida.

CONTINUAR

Si se produce un error al importar la directiva de red de K8s actual, el sistema omitirá esta directiva y continuará importando la siguiente directiva de red de K8s. La respuesta de la API devuelve el mensaje de error para cada directiva de red de K8s que se omitió durante la operación de importación.

Precaución: Se puede esperar un cambio en el comportamiento del tráfico si las directivas de red de K8s importadas y las directivas de red de K8s omitidas se aplican al mismo pod.

Ejemplo:

Continuando con el mismo ejemplo, como se mencionó en la fila anterior. Cuando se produce un error en la importación de la directiva de red knp1, el sistema continúa importando la directiva de red knp2 y convierte esta directiva de red correctamente. La respuesta de la API devuelve el mismo mensaje de error para la directiva de red de knp1, que falló durante la conversión.

Las directivas de red de K8s que se importan en una sola solicitud de API pueden pertenecer a diferentes clústeres de Antrea Kubernetes registrados. O bien, pueden pertenecer a varios espacios de nombres en un solo clúster de Antrea Kubernetes.

Si un espacio de nombres incluye varias directivas de red de K8s, le recomendamos que las importe en una sola solicitud de API. La razón es que las directivas de red de K8s dentro de un espacio de nombres pueden estar relacionadas entre sí. Esta práctica ayuda a garantizar que el comportamiento del tráfico no cambie después de importar las directivas de red a NSX.

Una vez que la importación se complete correctamente, vaya a la interfaz de usuario de NSX Manager y consulte la configuración de los grupos de Antrea y las directivas de DFW.
Opcional: Consulte las directivas de red del clúster de Antrea realizadas, compruebe las especificaciones de ACNP y clusterGroup ejecutando estos comandos de kubectl:
```
kubectl get acnp
```
```
kubectl get acnp <acnp-id> -o yaml
```
```
kubectl get cg <cg-id> -o yaml
```
Opcional: Compruebe que las directivas de red de K8s que se importaron correctamente a NSX no se muestren en el clúster de K8s ejecutando el siguiente comando de kubectl:
```
kubectl get networkpolicies -n <namespace>
```
Para nuestro ejemplo, el comando es el siguiente:
```
kubectl get networkpolicies -n test-ns5

NAME     POD-SELECTOR   AGE
k-np10   app=demo       84m
k-np12   app=demo       84m
```
Observe que las directivas de red de Kubernetes importadas (k-np9 y k-np11) ya no aparecen en el clúster de K8s.

Funciones de directiva de red de Kubernetes no compatibles

Actualmente, algunas funciones de las directivas de red de Kubernetes no se admiten para la conversión a directivas de DFW de NSX y grupos de Antrea. La respuesta de la API muestra un mensaje de error adecuado cuando se produce un error en la conversión debido a alguna de las siguientes funciones no compatibles.

Las directivas de red de K8s que utilizan nombres de puertos de capa 4 para pods no se convierten. Las directivas de DFW solo admiten números de puerto.
Las directivas de red de K8s que contienen el protocolo SCTP no se convierten. Las directivas de DFW de NSX no admiten el tráfico de SCTP.
Las directivas de red de K8s pueden tener un gran número de matchLabels o matchExpressions en la sección podSelector o NetworkPolicyPeer. Sin embargo, el criterio de pertenencia dinámica en un grupo de Antrea puede admitir un máximo de 15 condiciones con tipos de miembros mixtos y 5 condiciones con el mismo tipo de miembro. Cuando se supera este límite máximo en un criterio de pertenencia a grupo, se produce un error en la conversión.
Las directivas de red de Kubernetes que contienen matchExpressions con el operador DoesNotExist no se convierten a grupos de Antrea. El operador de DoesNotExist de Kubernetes se asigna al valor de NotEquals para el operador de ámbito en NSX. Sin embargo, el operador de ámbito en una definición de grupo de Antrea no admite actualmente este valor.
Las directivas de red de Kubernetes que contienen matchExpressions con el operador In deben contener un solo valor para que la conversión se realice correctamente. Actualmente, no se admiten varios valores en el operador In para la conversión a grupos de Antrea.

Comportamiento con diferentes versiones de Adaptador de NSX Antrea

Puede actualizar Adaptador de NSX Antrea y NSX por separado y en cualquier orden. Los nuevos cambios en Adaptador de NSX Antrea son compatibles con las versiones de NSX anteriores a la 4.2.

Supongamos el siguiente escenario:

Su entorno de NSX tiene la versión 4.2 y tiene varios clústeres de Antrea Kubernetes registrados. Algunos clústeres de Kubernetes tienen la nueva versión de Adaptador de NSX Antrea (por ejemplo, la 0.15), mientras que otros tienen una versión antigua de Adaptador de NSX Antrea (por ejemplo, la 0.11). En este caso, la versión anterior de Adaptador de NSX Antrea no eliminará automáticamente las directivas de red originales de Kubernetes del clúster de Kubernetes después de la conversión. El administrador de Kubernetes o el administrador de espacio de nombres debe eliminar manualmente las directivas de red de Kubernetes originales. Tenga en cuenta que se sigue realizando la conversión a directivas de DFW. Las directivas de permiso de DFW convertidas y las directivas de descarte predeterminadas se realizan como directivas de red del clúster de Antrea en el clúster de Kubernetes, y la CNI de Antrea las evalúa antes que las directivas de red de Kubernetes originales. Si las directivas originales de Kubernetes no se eliminan del clúster de Kubernetes, el comportamiento del tráfico definido en las directivas de DFW convertidas puede entrar en conflicto con las directivas de red de Kubernetes originales.