Grupos genéricos con tipos de miembros de Kubernetes en criterios dinámicos de pertenencia

Puede crear grupos con tipos de miembros de Kubernetes (recursos) en criterios dinámicos de pertenencia para que coincidan con el tráfico entrante o 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 esta documentación se utiliza la frase "Tipos de miembros de Kubernetes" para hacer referencia a los recursos de Kubernetes que se pueden utilizar para configurar criterios dinámicos de pertenencia.

Actualmente, los grupos genéricos con tipos de miembros de Kubernetes solo admiten criterios dinámicos de pertenencia. No se pueden agregar tipos de miembros de Kubernetes de forma estática en una definición de grupo genérica.

Nota: Para evaluar los miembros efectivos de un grupo genérico que contiene criterios dinámicos de pertenencia definidos mediante tipos de miembros de Kubernetes, NSX tiene en cuenta el inventario de recursos del que informan los clústeres de Kubernetes con CNI de Antrea. El inventario de recursos del que informan los clústeres de Kubernetes con CNI de NCP se ignora para evaluar los miembros efectivos del grupo.

Tipos de miembros de Kubernetes en los criterios de pertenencia

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

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

Un criterio puede tener una o varias condiciones. Las condiciones pueden utilizar el mismo tipo de miembro de Kubernetes o una combinación de diferentes tipos de miembros de Kubernetes. Sin embargo, algunas restricciones se aplican a la adición de varias condiciones con tipos de miembros mixtos en un criterio de pertenencia. Consulte la sección Restricciones para usar tipos de miembros de Kubernetes en un criterio 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, NSX selecciona el operador OR para unir dos criterios. El operador AND se admite entre dos criterios solo cuando:

• Estos criterios utilizan el mismo tipo de miembro de Kubernetes.
• 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 de Kubernetes en un mismo criterio de pertenencia. Por ejemplo, en un criterio, puede agregar un máximo de cinco condiciones de servicio de Kubernetes.
• Se admite un máximo de 15 condiciones con tipos de miembros de Kubernetes 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 condiciones de espacio de nombres de Kubernetes y condiciones de entrada de Kubernetes.
• 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 genérico se determina en función del número de condiciones de cada criterio. Consulte los siguientes ejemplos.

Ejemplo 1

Un grupo genérico 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 genérico 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 genérico 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 usar tipos de miembros de Kubernetes en un criterio

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

Miembros efectivos para condiciones con tipos de miembros de Kubernetes

Desde un punto de vista de NSX, los miembros efectivos de los grupos con tipos de miembros de Kubernetes son direcciones IP discretas, rangos de IP o una lista de puertos y direcciones IP.

En la siguiente tabla se proporcionan algunos ejemplos.

Ejemplo de definición de grupo	Caso práctico	Descripción	Miembros efectivos
Condición del clúster de Kubernetes Y Condición del nodo de Kubernetes (basada en la dirección IP)	Tráfico del clúster de Antrea Kubernetes a NSX	Coincide con todas las direcciones IP de los nodos en los clústeres especificados	Direcciones IP
Condición del clúster de Kubernetes Y Condición del nodo de Kubernetes (basada en el CIDR de pod)	Tráfico del clúster de Antrea Kubernetes a NSX	Coincide con los CIDR de pod de todos los nodos de los clústeres especificados	CIDR del pod
Condición del clúster de Kubernetes Y Condición de salida de Antrea (basada en el nombre)	Tráfico del clúster de Antrea Kubernetes a NSX	Coincide con la salida por nombre en los clústeres especificados	Direcciones IP de salida
Condición del clúster de Kubernetes Y Condición de salida de Antrea (basada en la etiqueta) Y Más condiciones de salida de Antrea (basadas en la etiqueta)	Tráfico del clúster de Antrea Kubernetes a NSX	Coincide con la salida por etiquetas en los clústeres especificados	Direcciones IP de salida
Condición del clúster de Kubernetes Y Condición de grupo de direcciones IP de Antrea (basada en el nombre)	Tráfico del clúster de Antrea Kubernetes a NSX Tráfico de NSX al clúster de Antrea Kubernetes	Coincide con el grupo de direcciones IP por nombre en los clústeres especificados	Rangos de IP
Condición del clúster de Kubernetes Y Condición de grupo de direcciones IP de Antrea (basada en la etiqueta) Y Más condiciones de grupo de direcciones IP de Antrea (basadas en etiquetas)	Tráfico del clúster de Antrea Kubernetes a NSX Tráfico de NSX al clúster de Antrea Kubernetes	Coincide con los grupos de direcciones IP por etiquetas en los clústeres especificados	Rangos de IP
Condición del clúster de Kubernetes Y Condición de espacio de nombres de Kubernetes Y Condición de entrada de Kubernetes (basada en el nombre)	Tráfico de NSX al clúster de Antrea Kubernetes	Coincide con la entrada por nombre en los clústeres y el espacio de nombres especificados	Direcciones IP de entrada
Condición del clúster de Kubernetes Y Condición de espacio de nombres de Kubernetes Y Condición de puerta de enlace de Kubernetes (basada en el nombre)	Tráfico de NSX al clúster de Antrea Kubernetes	Coincide con la puerta de enlace por nombre en los clústeres y el espacio de nombres especificados	Direcciones IP de puerta de enlace
Condición del clúster de Kubernetes Y Condición de espacio de nombres de Kubernetes Y Condición de entrada de Kubernetes (basada en la etiqueta) Y Más condiciones de entrada de Kubernetes (basadas en etiquetas)	Tráfico de NSX al clúster de Antrea Kubernetes	Coincide con la entrada por etiquetas en los clústeres y el espacio de nombres especificados	Direcciones IP de entrada
Condición del clúster de Kubernetes Y Condición de espacio de nombres de Kubernetes Y Condición de puerta de enlace de Kubernetes (basada en la etiqueta) Y Más condiciones de puerta de enlace de Kubernetes (basadas en etiquetas)	Tráfico de NSX al clúster de Antrea Kubernetes	Coincide con la puerta de enlace por etiquetas en los clústeres y el espacio de nombres especificados	Direcciones IP de puerta de enlace
Condición del clúster de Kubernetes Y Condición de espacio de nombres de Kubernetes Y Condición del servicio de Kubernetes (basada en la etiqueta y type=LoadBalancer) Y Más condiciones de servicio de Kubernetes (basadas en etiquetas y type=LoadBalancer)	Tráfico de NSX al clúster de Antrea Kubernetes	Coincide con el servicio (LoadBalancer) por etiquetas en los clústeres y el espacio de nombres especificados	Direcciones IP de entrada de LoadBalancer
Condición del clúster de Kubernetes Y Condición de espacio de nombres de Kubernetes Y Condición del servicio de Kubernetes (basada en el nombre, funciones type=ClusterIP y NodePortLocal habilitadas)	Tráfico de NSX al clúster de Antrea Kubernetes	Coincide con el servicio (ClusterIP con NodePortLocal habilitado) por nombre en los clústeres y el espacio de nombres especificados.	Direcciones IP de nodo, rango de NodePortLocal