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.
- Ambos criterios utilizan el mismo tipo de miembro.
- Ambos criterios utilizan una sola condición.
- 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.
- 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 |
|
|
Segmento | Compatible Las condiciones basadas en Segmento pueden combinarse con condiciones basadas en Puerto de segmento |
|
|
Puerto de segmento | Compatible Las condiciones basadas en Puerto de segmento pueden combinarse con condiciones basadas en Segmento de NSX |
|
|
Grupos de puertos distribuidos | Compatible Las condiciones basadas en Grupo de puertos distribuidos pueden combinarse con condiciones basadas en Puerto distribuido |
|
|
Puertos distribuidos | Compatible Las condiciones basadas en Puerto distribuido pueden combinarse con condiciones basadas en Grupos de puertos distribuidos |
|
|
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 |
|
|
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.
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:
|
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:
|
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:
|
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 |
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