Groupes d'ingress

Un groupe d’ingress est un ensemble de nœuds Ingress nginx, normalement un par site, qui servent les mêmes Routes et les mêmes domaines. Chaque membre génère lui-même chaque Route du groupe et conserve sa propre copie de chaque certificat utilisé par ces Routes ; un membre continue donc de servir pendant qu’Opfield ou un autre membre est en panne. Les Routes vers des charges de travail Docker, les sites Pages et la page de statut publique peuvent tous être servis depuis un groupe.

Un groupe décide quels nœuds servent un nom d’hôte. Il ne choisit pas quel membre un client atteint : cela relève du DNS ou d’un répartiteur de charge placé devant les membres ; voir DNS et Placer un répartiteur de charge devant.

Prérequis et permissions

Les membres sont des nœuds nginx dont le démon signale la capacité ingress_group_v1, ce que fait le démon nginx de la version 2.11. Un nœud peut appartenir à plusieurs groupes.
La création d’un groupe, et tout ce qui l’agrandit (ajout ou réordonnancement de membres, modification de ses paramètres, placement de Routes ou de domaines sur lui), nécessite Business ou Enterprise, comme Workload Availability. Les groupes existants continuent de servir sans ce plan, et le retrait de membres ou la suppression d’un groupe sont toujours autorisés.
Les groupes ont leurs propres permissions, accordées de façon large ou sur le dossier de nœuds du groupe. La consultation nécessite ingress:groups:view ; la création, la modification et la suppression des groupes et de leurs membres nécessitent ingress:groups:manage (qui inclut la consultation) sur ce dossier, et l’ajout d’un nœud nécessite aussi nodes:manage sur ce nœud. Les permissions sur les nœuds seules n’affichent pas les groupes.
Placer une Route ou un domaine sur un groupe nécessite ingress:groups:view sur le groupe et proxy:create ou domains:create couvrant chaque membre : de façon large, dans le dossier de destination, ou via un droit sur chaque nœud membre. Les listes de nœuds Ingress ne proposent que les groupes que vous pouvez consulter. Enregistrer une Route ou un domaine qui reste sur son groupe ne nécessite aucune permission de groupe ; le groupe d’opérateurs intégré dispose de ingress:groups:view.

Créer un groupe

Ouvrez Routes → Ingress Groups et sélectionnez New Group.
Saisissez un nom, une description et un dossier facultatifs, puis sélectionnez les nœuds membres par ordre de préférence de site.
Ouvrez le groupe pour suivre l’État (State), la santé de l’ingress (Ingress health) de chaque membre et la livraison des Routes du groupe.

Sur la page du groupe, vous pouvez ajouter, retirer et réordonner les membres, et voir pour chaque Route ce que chaque membre a appliqué : l’empreinte de la configuration, la version du certificat ou la raison de l’échec. La page affiche aussi les adresses que le DNS publie pour les domaines du groupe.

Les mêmes opérations sont disponibles via /api/ingress-groups et l’outil MCP manage_ingress_group.

Servir des Routes et des domaines depuis un groupe

Lorsque vous créez une Route ou un domaine, la liste des nœuds Ingress propose aussi Ingress groups (served by every member). Une Route créée pour un domaine placé sur un groupe va dans ce groupe. Via l’API et MCP, passez ingressGroupId au lieu de nodeId (nginxNodeId pour les domaines).

Pour déplacer une Route ou un domaine existant, utilisez ses détails dans la Console, ou convert_route et convert_domain. Le passage sur un groupe se fait sans interruption : chaque nouveau membre reçoit d’abord la configuration et les certificats, et le DNS change en dernier. Le retour sur un seul nœud (ingressGroupId: null plus le nœud membre) change d’abord le DNS et nettoie ensuite les autres membres. Un nom d’hôte doit être unique sur l’ensemble des nœuds et des membres de groupe sur lesquels il est servi.

Une Route d’un groupe liste les nœuds qui la servent (servingNodeIds), son groupe et la livraison sur chaque membre (ingressDelivery).

Membres

État	Signification
Joining	Le nœud reçoit chaque configuration de Route, chaque certificat et chaque source Secure Link du groupe. Il n’est pas encore publié dans le DNS. Un nœud hors ligne reste dans cet état jusqu’à sa reconnexion.
Active	Le nœud sert et est publié dans le DNS.
Draining	Le nœud sert encore mais a été retiré du DNS. Il est retiré une fois qu’aucun nom public du groupe ne se résout plus vers lui et que le TTL DNS est écoulé, au plus 24 heures.

Retirer un membre le retire d’abord du DNS et le laisse se vider. Pour un membre en cours de vidage, Remove now (force dans l’API) le retire immédiatement, alors que des réponses DNS en cache peuvent encore lui envoyer des clients. Le dernier membre actif d’un groupe qui sert encore des Routes ou des domaines ne peut pas être retiré, et seul un groupe sans Routes ni domaines peut être supprimé.

Livraison et membres hors ligne

Opfield livre chaque modification à chaque membre. La modification d’une Route d’un groupe fonctionne pendant qu’un membre est hors ligne : ce membre est enregistré comme en attente et rattrape son retard à sa reconnexion. Opfield répare chaque minute, et à chaque reconnexion d’un membre, les configurations et copies de certificats manquantes ou obsolètes. Si une mise à jour est refusée après que certains membres l’ont reçue, ces membres récupèrent la Route précédente.

Certificats

Chaque membre détient une copie de chaque certificat utilisé par ses Routes, et les renouvellements atteignent chaque membre. Les défis HTTP-01 sont placés sur chaque membre en ligne. Comme le DNS peut envoyer une requête de validation à n’importe quel membre, y compris un membre hors ligne, les certificats des noms d’un domaine de groupe géré par Cloudflare sont émis et renouvelés avec DNS-01 via le connecteur Cloudflare, qui ne dépend d’aucun nœud Ingress.

Santé et journaux

La santé d’une Route est vérifiée via chaque membre : une Route est degraded lorsqu’un membre échoue à la vérification et offline lorsqu’aucun membre ne la sert. Chaque membre écrit ses propres journaux nginx ; la vue des journaux et l’historique de la Route fusionnent les lignes de tous les membres par ordre chronologique.

Point de terminaison de santé de l’ingress

Chaque bloc server généré par Opfield, ainsi que le serveur par défaut, répond au chemin réservé /.well-known/opfield-ingress-health. La réponse vient du nœud lui-même ; elle continue donc de fonctionner lorsqu’Opfield est injoignable :

Code	Signification
`200` avec le JSON `"status": "serving"`	nginx exécute la configuration du dernier rechargement réussi du démon et, sur un nœud qui porte des Secure Links, au moins un transport Relay est utilisable
`503` avec le JSON `"status": "unavailable"` et `reasons`	nginx n’exécute pas la configuration actuelle, ou aucun transport Relay n’est connecté pour ses Secure Links
`502`	le démon nginx ne s’exécute pas

Pour les sondes qui s’adressent à un membre par son adresse IP, le nœud répond aussi au nom d’hôte réservé ingress-health.opfield.invalid sur les ports 80 et 443. Sur le port 443, il utilise un certificat autosigné. Les moniteurs configurés avec l’ancien chemin /.well-known/gateway-ingress-health ou l’ancien nom ingress-health.gateway.invalid continuent de fonctionner. Le point de terminaison est exempté du mode maintenance, des Access Lists et de l’authentification basique.

DNS

Le mode de basculement DNS du groupe est none : pour un domaine de groupe géré par Cloudflare, Opfield publie l’adresse de chaque membre actif, ce qui répartit les clients en tourniquet (round robin). Ces enregistrements ne font pas l’objet de vérifications de santé ; un membre injoignable continue donc de recevoir sa part de clients jusqu’à ce qu’il soit retiré du groupe. Les membres sans adresse d’ingress publique détectée ne sont pas publiés. Le DNS externe reste à votre charge ; Opfield vérifie seulement qu’il pointe vers des membres.

Placer un répartiteur de charge devant

Pour un basculement entre membres, placez devant eux un répartiteur de charge qui vérifie la santé. Avec Cloudflare Load Balancing :

Créez un pool dont les origines sont les adresses publiques des membres actifs du groupe.
Rattachez un moniteur de santé pour le chemin /.well-known/opfield-ingress-health qui attend 200. Utilisez HTTP sur le port 80 avec l’en-tête Host ingress-health.opfield.invalid ou un nom d’hôte servi par le groupe ; pour un moniteur HTTPS vers le nom d’hôte réservé, désactivez la vérification du certificat, car ce nom utilise un certificat autosigné.
Créez le répartiteur de charge pour le nom d’hôte que servent vos Routes, avec ce pool.

Le connecteur Cloudflare d’Opfield ne crée, ne modifie et ne supprime jamais de répartiteurs de charge, de pools ou de moniteurs Cloudflare. Lorsque vous ajoutez ou retirez des membres, mettez le pool à jour vous-même. Pour un domaine de groupe géré par Cloudflare, Opfield continue de maintenir les enregistrements DNS simples décrits ci-dessus.