Puede crear grupos de Antrea y utilizarlos como orígenes o destinos en las directivas de firewall distribuido para proteger el tráfico entre los pods dentro de un clúster de Antrea Kubernetes.

Nota: En un entorno de NSX de varios tenants, actualmente no se admiten grupos de Antrea en proyectos. Solo puede agregar grupos de Antrea en la vista Predeterminado (espacio predeterminado) del entorno de NSX.

La función de grupos de Antrea solo se admite cuando el entorno de NSX tiene registrados uno o varios clústeres de Antrea Kubernetes. Si se detectan clústeres de Antrea Kubernetes registrados, NSX Manager mostrará un tipo de grupo independiente llamado Antrea en la página Agregar grupo de la interfaz de usuario. Debe seleccionar este tipo de grupo para agregar grupos de Antrea.

Si su objetivo es proteger el tráfico entre clústeres de Antrea Kubernetes y las máquinas virtuales en la red de superposición de NSX, debe crear grupos de tipo Genérico con tipos de miembros de Kubernetes en criterios dinámicos de pertenencia y utilizar esos grupos en las reglas de firewall. Para obtener más información, consulte Grupos genéricos con tipos de miembros de Kubernetes en criterios dinámicos de pertenencia.

Un grupo de Antrea puede incluir direcciones IP estáticas, criterios de pertenencia o ambos. Las direcciones IP pueden ser direcciones IP de pod o IP de servicio.

Cuando un grupo de Antrea contiene criterios de pertenencia, los miembros efectivos calculados por esos criterios de pertenencia solo pueden ser pods.

Nota:
  • Los miembros efectivos se calculan para grupos de Antrea solo cuando los grupos de Antrea se utilizan en reglas de firewall distribuido.

    Si agregan grupos de Antrea con criterios de pertenencia, pero no se utilizan en ninguna de las reglas de firewall distribuido, los miembros efectivos de estos grupos de Antrea no se calculan ni se evalúan en NSX. En otras palabras, la página Miembros efectivos de estos grupos de Antrea está vacía.

  • Cuando se agregan direcciones IP estáticas a grupos de Antrea, los miembros efectivos actualmente no se muestran en la interfaz de usuario, independientemente de si los grupos se utilizan en reglas de firewall distribuido.
Para agregar criterios de pertenencia a un grupo de Antrea, actualmente se admiten los siguientes tipos de miembros:
  • Espacio de nombres
  • Servicio
  • Pod

Descripción general de los criterios de pertenencia

Puede agregar grupos de Antrea con uno o varios criterios de pertenencia. Un criterio de pertenencia consta de una o varias condiciones. Una condición en un criterio de pertenencia consta de las siguientes propiedades:
  • Tipo de miembro
  • Nombre del tipo de miembro o una etiqueta asociada al tipo de miembro
  • Valor y operador de etiqueta (solo cuando se utiliza la etiqueta)
  • Valor y operador de ámbito (solo cuando se utiliza la etiqueta)
Las condiciones en un criterio de pertenencia pueden utilizar el mismo tipo de miembro o una combinación de diferentes tipos de miembros. Por ejemplo, si un criterio de pertenencia consta de tres condiciones, las dos primeras pueden estar basadas en Pod, mientras que la tercera puede estar basada en Espacio de nombres. Sin embargo, existen algunas restricciones para agregar varias condiciones en un criterio de pertenencia. Consulte la sección ''Funciones compatibles y no compatibles'' más adelante en este tema.

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 condiciones en un criterio de pertenencia.

Ejemplos:
Criterios de pertenencia Descripción

Criterio 1:

Etiqueta Pod es igual a Ámbito de aplicación es igual a Servidores

El criterio de pertenencia consta de solo una condición que se basa en el pod. No se utilizan varias condiciones. Los miembros efectivos de este grupo de Antrea incluyen todos los pods con la etiqueta App.

Criterio 2:

Etiqueta Pod es igual a Ámbito de aplicación es igual a Servidores

Etiqueta Pod es igual a Ámbito de base de datos es igual a Servidores

Etiqueta Pod es igual a Ámbito web y es igual a Servidores

El criterio de pertenencia consta de tres condiciones. Todas las condiciones del criterio se basan en el pod. Los miembros efectivos de este grupo de Antrea incluyen todos los pods con las etiquetas App, DB y Web.

Criterio 3:

Nombre de espacio de nombres es igual a Producción

Nombre de servicio es igual a Caché

El criterio de pertenencia consta de dos condiciones con una combinación de espacios de nombres y servicios. Los miembros efectivos de este grupo de Antrea incluyen todos los pods que están asociados con el servicio Caché en el espacio de nombres de producción.

Unirse a los criterios de pertenencia con los operadores OR y AND

Un grupo de Antrea admite varios criterios de pertenencia. Para unir los criterios, están disponibles los operadores OR y AND. De forma predeterminada, NSX selecciona el operador OR para unir varios 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.
Ejemplos:
  • El criterio 1, el criterio 2 y el criterio 3 se basan en el pod y no contienen varias condiciones. En este caso, el criterio 1 y el criterio 2 se pueden unir con el operador OR o AND. De forma similar, el criterio 2 y el criterio 3 también se pueden unir con el operador OR o AND.
  • El criterio 1 se basa en el objeto Pod, mientras que el criterio 2 utiliza dos condiciones: una basada en Servicio y la otra basada en Espacio de nombres. En este caso, solo se admite el operador OR para unir los criterios 1 y 2. No se permite el operador AND.
  • El criterio 1 y el criterio 2 se basan en Pod, mientras que el criterio 3 utiliza dos condiciones: una basada en Servicio y la otra basada en Espacio de nombres. En este caso, el criterio 1 y el criterio 2 se pueden unir con el operador AND u OR. Sin embargo, el criterio 2 y el criterio 3 solo se pueden unir con el operador OR. No se permite el operador AND.

Funciones compatibles y no compatibles

En la siguiente tabla se especifican los tipos de miembro, el operador de etiqueta y el operador de ámbito que se admiten para agregar criterios de pertenencia a grupos de Antrea.
Tipo de miembro Atributo de objeto Operador de etiqueta Operador de ámbito Criterios de ejemplo

Espacio de nombres

Nombre

Es igual a

No aplicable

Nombre de espacio de nombres es igual a Producción

Espacio de nombres

Etiqueta

Es igual a

No es igual a

Es igual a

Etiqueta Espacio de nombres es igual a Ámbito de base de datos es igual a Servidores

Servicio

Nombre

No compatible

No compatible

Nombre de servicio es igual a Caché

Pod

Etiqueta

Es igual a

No es igual a

Es igual a

Etiqueta Pod es igual a Ámbito de aplicación es igual a Servidores

  • Los siguientes operadores de etiqueta no son compatibles actualmente con los tipos de miembro Espacio de nombres y Pod:
    • Contiene
    • Empieza por
    • Termina con
  • En un criterio de pertenencia, una condición basada en Servicio debe combinarse con una condición basada en el atributo Nombre de un espacio de nombres. En otras palabras, no se permite un criterio con solo el tipo de miembro Servicio.
    Ejemplo:
    Compatible No compatible

    Criterio:

    Nombre de servicio es igual a My-Service

    Nombre de espacio de nombres es igual a Provisional

    Criterio:

    Nombre de servicio es igual a My-Service

  • En un criterio de pertenencia, una condición basada en Servicio no se puede combinar con una condición basada en Pod. Sin embargo, puede agregar condiciones basadas en Servicio y Pod en dos criterios de pertenencia independientes y unirlos con un operador OR.
    Ejemplo:
    Compatible No compatible

    Criterio 1: Nombre de servicio es igual a My-Service

    O

    Criterio 2: Etiqueta Pod es igual a Ámbito de base de datos es igual a Servidores

    Criterio:

    Nombre de servicio es igual a My-Service

    Etiqueta Pod es igual a Ámbito de base de datos es igual a Servidores

  • Para agregar miembros estáticamente en un grupo de Antrea, solo se admiten direcciones IP. Espacio de nombres, Pod y Servicio no se pueden agregar de forma estática como miembros de un grupo de Antrea.
  • Al agregar un grupo de Antrea, NSX muestra un mensaje de información si intenta cambiar el tipo de grupo de Antrea a Genérico o de Antrea a Solo direcciones IP. Al confirmar el cambio, se perderán todos los criterios de pertenencia del grupo. Solo las direcciones IP se conservan en el grupo.

    Después de que se haya realizado (guardado) un grupo de Antrea en NSX, no podrá cambiar el tipo de grupo. Los tipos de grupo Genérico y Solo direcciones IP aparecen atenuados.

Solución alternativa para Kubernetes 1.20 y versiones anteriores

El criterio de grupo de Antrea "Nombre de espacio de nombres es igual a Valor" funciona con Kubernetes 1.21 y versiones anteriores.

En Kubernetes 1.21 y versiones posteriores se agrega automáticamente una etiqueta especial a todos los espacios de nombres y el criterio Nombre de espacio de nombres utiliza internamente esta etiqueta especial. Sin embargo, para Kubernetes 1.20 y versiones posteriores, se requiere una solución alternativa. Debe registrar el webhook de Controlador Antrea en el espacio de nombres para crear eventos. Cuando se llama al webhook de Controlador Antrea, Controlador Antrea agrega una etiqueta especial al nuevo espacio de nombres, por lo que el criterio "Nombre de espacio de nombres es igual a Valor" puede utilizar esta etiqueta. Para obtener más información sobre cómo registrar el webhook de Controlador Antrea, consulte el paso 3 de Enviar los archivos YAML al servidor de API de Kubernetes.

Nota: El webhook de Controlador Antrea solo es efectivo para los nuevos espacios de nombres que cree después de registrar el webhook. En otras palabras, los espacios de nombres existentes, como kube-system y default, no obtienen la etiqueta especial, y el criterio "Nombre de espacio de nombres es igual a Valor" no funciona con estos espacios de nombres.