Grupos de ingress

Un grupo de ingress es un conjunto de nodos Ingress nginx, normalmente uno por ubicación, que sirven las mismas Routes y dominios. Cada miembro genera por sí mismo cada Route del grupo y conserva su propia copia de cada certificado que usan esas Routes, de modo que un miembro sigue sirviendo mientras Opfield u otro miembro están caídos. Las Routes hacia cargas de trabajo Docker, los sitios de Pages y la página de estado pública se pueden servir desde un grupo.

Un grupo decide qué nodos sirven un nombre de host. No elige a qué miembro llega un cliente: eso depende del DNS o de un balanceador de carga delante de los miembros; consulta DNS y Pon un balanceador de carga delante.

Requisitos y permisos

• Los miembros son nodos nginx cuyo daemon informa de la capacidad ingress_group_v1, como hace el daemon de nginx de la 2.11. Un nodo puede pertenecer a varios grupos.
• Crear un grupo, y todo lo que lo amplía (añadir o reordenar miembros, cambiar sus ajustes, colocar Routes o dominios en él), requiere Business o Enterprise, como Workload Availability. Los grupos existentes siguen sirviendo sin ese plan, y eliminar miembros o borrar un grupo siempre está permitido.
• Los grupos tienen sus propios permisos, concedidos de forma amplia o sobre la carpeta de nodos del grupo. Verlos requiere ingress:groups:view; crear, cambiar y eliminar grupos y sus miembros requiere ingress:groups:manage (que incluye la visualización) en esa carpeta, y añadir un nodo requiere además nodes:manage en ese nodo. Los permisos sobre nodos por sí solos no muestran los grupos.
• Colocar una Route o un dominio en un grupo requiere ingress:groups:view en el grupo y proxy:create o domains:create que cubran a todos los miembros: de forma amplia, en la carpeta de destino o mediante una concesión en cada nodo miembro. Las listas de nodos Ingress solo ofrecen los grupos que puedes ver. Guardar una Route o un dominio que se queda en su grupo no requiere ningún permiso sobre el grupo; el grupo de operadores integrado tiene ingress:groups:view.

Crea un grupo

1. Abre Routes → Ingress Groups y selecciona New Group.
2. Introduce un nombre, una descripción y una carpeta opcionales, y selecciona los nodos miembros por orden de preferencia de ubicación.
3. Abre el grupo para seguir el State de cada miembro, su Ingress health y la entrega de las Routes del grupo.

En la página del grupo puedes añadir, eliminar y reordenar miembros, y ver para cada Route lo que aplicó cada miembro: el hash de la configuración, la versión del certificado o el motivo del fallo. La página también muestra las direcciones que publica el DNS para los dominios del grupo.

Las mismas operaciones están disponibles a través de /api/ingress-groups y de la herramienta MCP manage_ingress_group.

Sirve Routes y dominios desde un grupo

Cuando creas una Route o un dominio, la lista de nodos Ingress también ofrece Ingress groups (served by every member). Una Route creada para un dominio que está en un grupo va a ese grupo. A través de la API y de MCP, pasa ingressGroupId en lugar de nodeId (nginxNodeId para los dominios).

Para mover una Route o un dominio existentes, usa sus detalles en la consola, o convert_route y convert_domain. Pasar a un grupo se hace sin tiempo de inactividad: cada nuevo miembro recibe primero la configuración y los certificados, y el DNS cambia al final. Volver a un solo nodo (ingressGroupId: null más el nodo miembro) cambia primero el DNS y limpia después los demás miembros. Un nombre de host debe ser único en todos los nodos y miembros de grupo en los que se sirve.

Una Route de un grupo enumera los nodos que la sirven (servingNodeIds), su grupo y la entrega en cada miembro (ingressDelivery).

Miembros

Estado	Significado
Joining	El nodo recibe todas las configuraciones de Routes, los certificados y los orígenes de Secure Links del grupo. Todavía no se publica en el DNS. Un nodo desconectado sigue en joining hasta que se vuelve a conectar.
Active	El nodo sirve y está publicado en el DNS.
Draining	El nodo sigue sirviendo, pero se ha retirado del DNS. Se elimina cuando ningún nombre público del grupo se resuelve a él y ha pasado el TTL del DNS, como máximo 24 horas.

Eliminar un miembro lo retira primero del DNS y lo deja vaciarse. Para un miembro en draining, Remove now (force en la API) lo elimina de inmediato, aunque las respuestas DNS en caché todavía puedan enviarle clientes. El último miembro activo de un grupo que todavía sirve Routes o dominios no se puede eliminar, y solo se puede borrar un grupo sin Routes ni dominios.

Entrega y miembros desconectados

Opfield entrega cada cambio a cada miembro. Editar una Route de un grupo funciona aunque un miembro esté desconectado: ese miembro queda registrado como pendiente y se pone al día cuando se vuelve a conectar. Opfield repara las configuraciones y copias de certificados que faltan o están desactualizadas cada minuto y siempre que un miembro se vuelve a conectar. Si una actualización se rechaza después de que algunos miembros la hayan aplicado, esos miembros recuperan la Route anterior.

Certificados

Cada miembro guarda una copia de cada certificado que usan sus Routes, y las renovaciones llegan a todos los miembros. Los desafíos HTTP-01 se colocan en todos los miembros en línea. Como el DNS puede enviar una petición de validación a cualquier miembro, incluido uno desconectado, los certificados para nombres de un dominio de grupo gestionado por Cloudflare se emiten y renuevan con DNS-01 a través del conector de Cloudflare, que no depende de ningún nodo Ingress.

Estado y logs

El estado de una Route se comprueba a través de cada miembro: una Route está degraded cuando algún miembro falla la comprobación y offline cuando ningún miembro la sirve. Cada miembro escribe sus propios logs de nginx; la vista de logs y el historial de la Route combinan por hora las líneas de todos los miembros.

Endpoint de estado del ingress

Cada bloque server generado por Opfield, y el servidor predeterminado, responden en la ruta reservada /.well-known/opfield-ingress-health. La respuesta procede del propio nodo, así que sigue funcionando mientras Opfield no es accesible:

Código	Significado
200 con el JSON "status": "serving"	nginx ejecuta la configuración de la última recarga correcta del daemon y, en un nodo que transporta Secure Links, al menos un transporte de Relay es utilizable
503 con el JSON "status": "unavailable" y reasons	nginx no ejecuta la configuración actual, o no hay ningún transporte de Relay conectado para sus Secure Links
502	el daemon de nginx no se está ejecutando

Para las sondas que se dirigen a un miembro por su dirección IP, el nodo también responde al nombre de host reservado ingress-health.opfield.invalid en los puertos 80 y 443. En el puerto 443 usa un certificado autofirmado. Los monitores configurados con la ruta anterior /.well-known/gateway-ingress-health o el nombre ingress-health.gateway.invalid siguen funcionando. El endpoint está exento del modo de mantenimiento, de las Access Lists y de la autenticación básica.

DNS

El modo de conmutación por error DNS del grupo es none: para un dominio de grupo gestionado por Cloudflare, Opfield publica la dirección de cada miembro activo, de modo que los clientes se reparten en round robin. Estos registros no tienen comprobación de estado, así que un miembro inaccesible sigue recibiendo su parte de clientes hasta que se elimina del grupo. Los miembros sin una dirección de ingress pública detectada no se publican. El DNS externo sigue siendo responsabilidad tuya; Opfield solo comprueba que apunte a los miembros.

Pon un balanceador de carga delante

Para la conmutación por error entre miembros, pon delante de ellos un balanceador de carga que compruebe el estado. Con Cloudflare Load Balancing:

1. Crea un pool cuyos orígenes sean las direcciones públicas de los miembros activos del grupo.
2. Asocia un monitor de estado para la ruta /.well-known/opfield-ingress-health que espere 200. Usa HTTP en el puerto 80 con la cabecera Host ingress-health.opfield.invalid o un nombre de host que sirva el grupo; para un monitor HTTPS hacia el nombre de host reservado, desactiva la verificación del certificado, porque ese nombre usa un certificado autofirmado.
3. Crea el balanceador de carga para el nombre de host que sirven tus Routes, con ese pool.

El conector de Cloudflare de Opfield nunca crea, cambia ni elimina balanceadores de carga, pools ni monitores de Cloudflare. Cuando añadas o elimines miembros, actualiza tú mismo el pool. Para un dominio de grupo gestionado por Cloudflare, Opfield sigue manteniendo los registros DNS simples descritos más arriba.