Puede definir criterios de pertenencia para agregar miembros dinámicamente a un grupo de NSX en función de uno o varios criterios.

Un criterio puede tener una o varias condiciones. Las condiciones pueden utilizar el mismo tipo de miembro o una combinación de diferentes tipos de miembros.

Algunas restricciones se aplican a la adición de varias condiciones con tipos de miembros de NSX mixtos o tipos de miembros de Kubernetes mixtos en un criterio de pertenencia. Consulte las secciones Restricciones para criterios con tipos de miembros mixtos de NSX y Restricciones para criterios con tipos de miembros de Kubernetes mixtos más adelante en esta documentación.

De forma predeterminada, NSX utiliza el operador AND lógico después de cada condición en un criterio de pertenencia. No se admiten otros operadores lógicos para unir las condiciones en un criterio de pertenencia.

Para unir criterios, están disponibles los operadores OR y AND. De forma predeterminada, el sistema selecciona el operador OR para unir dos criterios. El operador AND se admite entre dos criterios solo cuando:
  • Ambos criterios utilizan el mismo tipo de miembro.
  • Ambos criterios utilizan una sola condición.
Las siguientes restricciones se aplican a la adición de varias condiciones:
  • Se admite un máximo de cinco condiciones con el mismo tipo de miembro en un mismo criterio de pertenencia. Por ejemplo, en un criterio, puede agregar un máximo de cinco condiciones con el tipo de miembro Máquina virtual.
  • Se admite un máximo de 15 condiciones con tipos de miembros mixtos en un mismo criterio de pertenencia. Por ejemplo, en un mismo criterio, puede agregar un máximo de 15 condiciones con una combinación de los tipos de miembros Segmento y Puerto de segmento.
  • Se admite un máximo de 35 condiciones con tipos de miembros mixtos en un grupo genérico.
Un grupo puede tener un máximo de cinco criterios de pertenencia. Sin embargo, el número total de criterios que se puede agregar a un grupo se determina en función del número de condiciones de cada criterio. Consulte los siguientes ejemplos.
Ejemplo 1
Un grupo con tres criterios de pertenencia y un total de 35 condiciones:
  • El criterio 1 tiene 15 condiciones con tipos de miembros mixtos.
  • El criterio 2 tiene 15 condiciones con tipos de miembros mixtos.
  • El criterio 3 tiene 5 condiciones con el mismo tipo de miembro.
Ejemplo 2
Un grupo con cuatro criterios de pertenencia y un total de 35 condiciones:
  • El criterio 1 tiene 15 condiciones con tipos de miembros mixtos.
  • El criterio 2 tiene 14 condiciones con tipos de miembros mixtos.
  • El criterio 3 tiene cuatro condiciones con el mismo tipo de miembro.
  • El criterio 4 tiene dos condiciones con el mismo tipo de miembro.
Ejemplo 3
Un grupo con cinco criterios de pertenencia y un total de 22 condiciones:
  • El criterio 1 tiene 10 condiciones con tipos de miembros mixtos.
  • El criterio 2 tiene tres condiciones con el mismo tipo de miembro.
  • El criterio 3 tiene cuatro condiciones con el mismo tipo de miembro.
  • El criterio 4 tiene tres condiciones con el mismo tipo de miembro.
  • El criterio 5 tiene dos condiciones con tipos de miembros mixtos.
Debido a que este grupo ha alcanzado el límite de cinco criterios, no se pueden agregar más criterios de pertenencia. Sin embargo, si fuera necesario, puede agregar más condiciones en cualquiera de los cinco criterios mientras no supere los siguientes límites superiores mencionados anteriormente:
  • Un máximo de cinco condiciones con el mismo tipo de miembro en un mismo criterio.
  • Un máximo de 15 condiciones con tipos de miembros mixtos en un mismo criterio.
  • Un total de 35 condiciones en el grupo genérico.

Restricciones para criterios con tipos de miembros de NSX

Tipo de miembro Criterio con tipos de miembros mixtos Operador de etiqueta Operador de ámbito
Máquina virtual

No compatible
  • Es igual a: se puede seleccionar una etiqueta.
  • Contiene
  • Empieza por
  • Termina con
  • Es igual a
Segmento

Compatible

Las condiciones basadas en Segmento pueden combinarse con condiciones basadas en Puerto de segmento
  • Es igual a: se puede seleccionar una etiqueta.
  • No es igual a: se puede seleccionar una etiqueta.
  • Es igual a
  • No es igual a: si se selecciona, se elimina el operador de etiqueta.
Puerto de segmento

Compatible

Las condiciones basadas en Puerto de segmento pueden combinarse con condiciones basadas en Segmento de NSX
  • Es igual a: se puede seleccionar una etiqueta.
  • No es igual a: se puede seleccionar una etiqueta.
  • No en: se puede seleccionar un máximo de cinco etiquetas.
  • Es igual a
  • No es igual a: si se selecciona, se elimina el operador de etiqueta.
Grupos de puertos distribuidos

Compatible

Las condiciones basadas en Grupo de puertos distribuidos pueden combinarse con condiciones basadas en Puerto distribuido

  • Es igual a: se puede seleccionar una etiqueta.
  • No es igual a: se puede seleccionar una etiqueta.
  • Es igual a
  • No es igual a: si se selecciona, se elimina el operador de etiqueta.
Puertos distribuidos

Compatible

Las condiciones basadas en Puerto distribuido pueden combinarse con condiciones basadas en Grupos de puertos distribuidos
  • Es igual a: se puede seleccionar una etiqueta.
  • No es igual a: se puede seleccionar una etiqueta.
  • No en: se puede seleccionar un máximo de cinco etiquetas.
  • Es igual a
  • No es igual a: si se selecciona, se elimina el operador de etiqueta.
Conjunto de direcciones IP: este tipo de miembro quedará obsoleto en el futuro. Actualmente, está disponible para lograr la compatibilidad con versiones anteriores de grupos NSGroup o Grupos preexistentes basados en el criterio basado en etiquetas del conjunto de direcciones IP. Le recomendamos que utilice Grupo como el tipo de miembro y que agregue grupos basados en etiquetas del tipo 'Solo direcciones IP' en un criterio de pertenencia.

No compatible
  • Es igual a: se puede seleccionar una etiqueta.
  • Es igual a
Grupo: utilice este tipo de miembro para agregar grupos basados en etiquetas del tipo 'Solo direcciones IP' en un criterio de pertenencia.

No compatible

 Es igual a: se puede seleccionar una etiqueta. Es igual a

Descripción general de los criterios de pertenencia con tipos de miembros de Kubernetes

A partir de NSX 4.1, puede crear grupos genéricos con tipos de miembros de Kubernetes en criterios dinámicos de pertenencia para que coincidan con el tráfico entrante y saliente de los clústeres de Antrea Kubernetes.

A continuación, podrá utilizar estos grupos genéricos en reglas de firewall distribuido o reglas de firewall de puerta de enlace para proteger el tráfico entre las máquinas virtuales en el entorno de NSX y los pods de clústeres de Antrea Kubernetes.

Esta función requiere una versión de interoperabilidad de Antrea-NSX que esté disponible con VMware Container Networking™ with Antrea™ 1.6.0 o versiones posteriores. Consulte las notas de la versión 1.6.0.

En un grupo genérico, los tipos de miembros de Kubernetes están disponibles en la página Criterios de pertenencia solo cuando al menos un clúster de Antrea Kubernetes está registrado en el entorno de NSX.

Nota: En un entorno de NSX de varios tenants, los recursos del clúster de Kubernetes no se exponen al inventario del proyecto. Por lo tanto, dentro de un proyecto, no se pueden crear grupos genéricos con tipos de miembros de Kubernetes en criterios dinámicos de pertenencia.

En la siguiente tabla se especifican los tipos de miembros de Kubernetes que están disponibles en la vista Predeterminado de NSX 4.1 y versiones posteriores para agregar criterios dinámicos de pertenencia en un grupo genérico. Cada tipo de miembro de Kubernetes pertenece al ámbito de clúster o al ámbito de espacio de nombres.

Tipo de miembro Ámbito

Clúster de Kubernetes

Clúster

Espacio de nombres de Kubernetes

Espacio de nombres

Nodo de Kubernetes

Clúster

Servicio de Kubernetes

Espacio de nombres

Entrada de Kubernetes

Espacio de nombres

Puerta de enlace de Kubernetes

Espacio de nombres

Salida de Antrea

Clúster

Grupo de direcciones IP de Antrea

Clúster

Convenciones de nomenclatura utilizadas para condiciones con tipos de miembros de Kubernetes

En la siguiente tabla se explican las convenciones de nomenclatura que se utilizan en esta documentación para representar las diferentes condiciones que se pueden agregar en los criterios dinámicos de pertenencia, que se basan en los tipos de miembros de Kubernetes.

Convención de nomenclatura para la condición Significado

Condición del clúster de Kubernetes

Las condiciones de los criterios dinámicos de pertenencia se basan en el tipo de miembro del clúster de Kubernetes.

Condición de espacio de nombres de Kubernetes

Las condiciones de los criterios dinámicos de pertenencia se basan en el tipo de miembro del espacio de nombres de Kubernetes.

Condición de recurso
Las condiciones del criterio dinámico de pertenencia se basan en cualquiera de estos tipos de miembros de Kubernetes:
  • Servicio de Kubernetes
  • Entrada de Kubernetes
  • Puerta de enlace de Kubernetes
  • Salida de Antrea
  • Grupo de direcciones IP de Antrea
  • Nodo de Kubernetes

Condición de recursos con ámbito de clúster
Las condiciones de los criterios dinámicos de pertenencia se basan en cualquiera de estos tipos de miembros de Kubernetes:
  • Salida de Antrea
  • Grupo de direcciones IP de Antrea
  • Nodo de Kubernetes

Condición de recurso con ámbito de espacio de nombres
Las condiciones de los criterios dinámicos de pertenencia se basan en cualquiera de estos tipos de miembros de Kubernetes:
  • Servicio de Kubernetes
  • Entrada de Kubernetes
  • Puerta de enlace de Kubernetes

Restricciones para criterios con tipos de miembros de Kubernetes

En la siguiente tabla, se proporciona un resumen de alto nivel de las restricciones o las validaciones que se aplican al uso de tipos de miembros de Kubernetes en un único criterio de pertenencia. Para ver ejemplos de validaciones, consulte la sección Validaciones de grupos dinámicos con tipos de miembros de Kubernetes más adelante en esta documentación.

Tipo de miembro Restricciones para usar el tipo de miembro en un criterio Atributos compatibles Operador de etiqueta Operador de ámbito

Clúster de Kubernetes

No se puede utilizar solo en un criterio.

Solo se permite una condición de clúster en un criterio.

Debe combinarse con al menos una condición de recurso de Kubernetes.

De forma opcional, se puede combinar con condiciones de espacio de nombres de Kubernetes y condiciones de recursos de Kubernetes.

Nombre

No compatible

No compatible

Espacio de nombres de Kubernetes

No se puede utilizar solo en un criterio.

No se puede combinar con condiciones de recursos del ámbito del clúster.

Debe combinarse con condiciones de recursos del ámbito del espacio de nombres.

De forma opcional, se puede combinar con una condición de clúster de Kubernetes.

Nombre

Etiqueta

Es igual a: se puede seleccionar una etiqueta

Es igual a

Salida de Antrea

Puede utilizarse solo en un criterio.

De forma opcional, se puede combinar con una condición de clúster de Kubernetes.

Nombre

Etiqueta

Es igual a: se puede seleccionar una etiqueta

Es igual a

Grupo de direcciones IP de Antrea

Puede utilizarse solo en un criterio.

De forma opcional, se puede combinar con una condición de clúster de Kubernetes.

Nombre

Etiqueta

Es igual a: se puede seleccionar una etiqueta

Es igual a

Entrada de Kubernetes

Puede utilizarse solo en un criterio.

De forma opcional, se puede combinar solo con condiciones de espacio de nombres de Kubernetes, solo con la condición de clúster de Kubernetes, o con ambas.

Nombre

Etiqueta

Es igual a: se puede seleccionar una etiqueta

Es igual a

Puerta de enlace de Kubernetes

Puede utilizarse solo en un criterio.

De forma opcional, se puede combinar solo con condiciones de espacio de nombres de Kubernetes, solo con la condición de clúster de Kubernetes, o con ambas.

Nombre

Etiqueta

Es igual a: se puede seleccionar una etiqueta

Es igual a

Servicio de Kubernetes

Puede utilizarse solo en un criterio.

De forma opcional, se puede combinar solo con condiciones de espacio de nombres de Kubernetes, solo con la condición de clúster de Kubernetes, o con ambas.

Nombre

Etiqueta

Es igual a: se puede seleccionar una etiqueta

Es igual a

Nodo de Kubernetes

Puede utilizarse solo en un criterio.

Solo se permite una condición de nodo único.

De forma opcional, se puede combinar con una condición de clúster de Kubernetes.

No se puede combinar con condiciones de espacio de nombres de Kubernetes ni con condiciones de recursos de Kubernetes.

Dirección IP

CIDR de pod

No compatible

Consulte nota que se muestra después de esta tabla.

No compatible
Nota: Cuando se crea un grupo genérico con el tipo de miembro de nodo de Kubernetes mediante la API, solo se permite el operador Coincide con. Este operador solo puede tomar el valor *. El carácter comodín * coincidirá con todos los nodos del clúster de K8s (si la condición del nodo de Kubernetes se combina con una condición de clúster de Kubernetes), o coincidirá con los nodos de todos los clústeres (si la condición del nodo de Kubernetes se utiliza de forma independiente).

Validaciones de grupos dinámicos con tipos de miembros de Kubernetes

Validación 1
Un criterio de pertenencia puede tener un máximo de una condición de clúster de Kubernetes. Para hacer coincidir un único clúster de Kubernetes por nombre, utilice el operador Es igual a e introduzca el nombre del clúster.
Nota: El nombre del clúster de Kubernetes debe ser único.
Si desea hacer coincidir varios clústeres en una condición de clúster de Kubernetes único, puede utilizar uno de estos operadores:
  • Entrada
  • Empieza por
  • Termina con

Ejemplo:

Coincide con un clúster de K8s único Coincide con varios clústeres de K8s
Criterio:

El nombre del clúster de Kubernetes es igual a ClusterA

 Criterio:

Nombre del clúster de Kubernetes en ClusterA,ClusterB,ClusterC

Se permite un máximo de cinco valores separados por comas. Los valores no deben estar separados por espacios.
Validación 2

Un criterio de pertenencia con una condición de clúster de Kubernetes se puede combinar con cualquiera de las condiciones de recursos de Kubernetes. Si también agrega condiciones de espacio de nombres de Kubernetes en el mismo criterio, las condiciones de recursos deben limitarse únicamente a las condiciones de recursos con ámbito de espacio de nombres.

Ejemplos:
  • Un criterio de pertenencia con una condición de clúster de Kubernetes y tres condiciones de entrada de Kubernetes es válido.
  • Un criterio de pertenencia con una condición de clúster de Kubernetes y dos condiciones de salida de Antrea es válido.
  • Un criterio de pertenencia con una condición de clúster de Kubernetes y tres condiciones de grupo de direcciones IP de Antrea es válido.
  • Un criterio de pertenencia con una condición de clúster de Kubernetes, una condición de espacio de nombres de Kubernetes y tres condiciones de puerta de enlace de Kubernetes es válido.
Validación 3
Un criterio de pertenencia debe incluir al menos una condición de recurso de Kubernetes. Un criterio de pertenencia no es válido si contiene:
  • Solo condición de clúster de Kubernetes
  • Solo condición de espacio de nombres de Kubernetes
  • Solo condición de clúster de Kubernetes y condición de espacio de nombres de Kubernetes
Ejemplos:
  • Un criterio de pertenencia con una condición de clúster de Kubernetes, una condición de espacio de nombres de Kubernetes y una condición de entrada de Kubernetes es válido.
  • Un criterio de pertenencia con una condición de clúster de Kubernetes, dos condiciones de espacio de nombres de Kubernetes y tres condiciones de entrada de Kubernetes es válido.
Validación 4

Un criterio de pertenencia solo puede tener una condición de nodo de Kubernetes. De forma opcional, una condición de nodo de Kubernetes se puede combinar solo con una condición de clúster de Kubernetes.

Una condición de nodo de Kubernetes no se puede combinar con condiciones de espacio de nombres de Kubernetes ni con condiciones de recursos de Kubernetes.

Un criterio de pertenencia con solo una condición de nodo de Kubernetes puede ser independiente. Sin embargo, un grupo con solo una condición de nodo de Kubernetes coincidirá con los nodos de todos los clústeres de Antrea Kubernetes registrados en NSX.

El operador de etiqueta y el operador de ámbito no se admiten actualmente para la condición de nodo de Kubernetes.

La condición del nodo de Kubernetes admite las dos propiedades siguientes.

Propiedad Descripción

Dirección IP

Coincide con la dirección IP interna de todos los nodos de los clústeres de Antrea Kubernetes especificados.

CIDR de pod

Coincide con el CIDR de pod de todos los nodos de clústeres de Antrea Kubernetes especificados.
Validación 5
Si un criterio de pertenencia incluye la condición de clúster de Kubernetes y las condiciones de espacio de nombres de Kubernetes, deberá incluir al menos una condición de recurso de Kubernetes con ámbito de espacio de nombres. No se puede combinar ninguna de las siguientes condiciones de recursos de Kubernetes con ámbito de clúster en el mismo criterio:
  • Egress de Antrea
  • Grupo de direcciones IP de Antrea
  • Nodo de Kubernetes
Ejemplos:
  • Un criterio de pertenencia con una condición de clúster de Kubernetes, dos condiciones de espacio de nombres de Kubernetes y condiciones de puerta de enlace de Kubernetes es válido.
  • Un criterio de pertenencia con una condición de clúster de Kubernetes, cuatro condiciones de espacio de nombres de Kubernetes y tres condiciones de servicio de Kubernetes es válido.
  • Un criterio de pertenencia con una condición de clúster de Kubernetes, una condición de espacio de nombres de Kubernetes y una condición de salida de Antrea no es válido porque la salida de Antrea es un recurso con ámbito de clúster.
Validación 6
Un criterio de pertenencia debe incluir al menos una condición de recurso de Kubernetes. Una condición de recurso puede ser independiente en un criterio. Sin embargo, si agrega varias condiciones de recursos en un criterio, todas las condiciones de recursos deberán ser del mismo tipo de miembro.
Nota: Las condiciones del clúster de Kubernetes y del espacio de nombres de Kubernetes se utilizan para definir el ámbito de un criterio. No son condiciones de recursos de Kubernetes y, por lo tanto, no están limitadas por esta regla de validación.
Ejemplos:
  • Un criterio de pertenencia con cinco condiciones de servicio de Kubernetes es válido.
  • Un criterio de pertenencia con una condición de clúster de Kubernetes, tres condiciones de espacio de nombres de Kubernetes y cuatro condiciones de servicio de Kubernetes es válido.
  • Un criterio de pertenencia con una condición de clúster de Kubernetes, tres condiciones de espacio de nombres de Kubernetes, cuatro condiciones de servicio de Kubernetes y tres condiciones de entrada de Kubernetes no es válido. El motivo es que se combinaron condiciones de recursos de dos tipos de miembros diferentes (servicio de Kubernetes y entrada de Kubernetes) en el mismo criterio.

    Sin embargo, puede crear criterios independientes con una condición de recurso basada en un solo tipo de miembro y, a continuación, unir ambos criterios con un operador OR, como se muestra a continuación:

    Criterio 1:

    Una condición de clúster de Kubernetes + tres condiciones de espacio de nombres de Kubernetes + cuatro condiciones de servicio de Kubernetes

    O

    Criterio 2:

    Una condición de clúster de Kubernetes + tres condiciones de espacio de nombres de Kubernetes + tres condiciones de entrada de Kubernetes

Validación 7

En un único criterio de pertenencia, las condiciones basadas en tipos de miembros de NSX no se pueden combinar con condiciones basadas en tipos de miembros de Kubernetes. Sin embargo, puede tener un grupo con un criterio basado solo en tipos de miembro de NSX y otro basado solo en tipos de miembro de Kubernetes y, después, unir ambos criterios con un operador OR.

Ejemplo:

Válido No válido

Criterio 1:

Condiciones de la máquina virtual

O

Criterio 2:

Condición del clúster de Kubernetes + condiciones de puerta de enlace de Kubernetes

Criterio:

Condición del segmento de NSX + condición del puerto de segmento

Y

Condición del clúster de Kubernetes + condiciones de puerta de enlace de Kubernetes