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.
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.
- 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.
- Espacio de nombres
- Servicio
- Pod
Descripción general de los criterios de pertenencia
- 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)
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
- 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
| 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.
- 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.
- 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.
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.
