Ingress-Gruppen
Eine Ingress-Gruppe ist eine Menge von nginx-Ingress-Nodes, normalerweise einer pro Standort, die dieselben Routen und Domains ausliefern. Jedes Mitglied rendert jede Route der Gruppe selbst und hält eine eigene Kopie jedes Zertifikats, das diese Routen verwenden, sodass ein Mitglied weiter ausliefert, während Opfield oder ein anderes Mitglied ausgefallen ist. Routen zu Docker-Workloads, Pages-Websites und die öffentliche Statusseite können alle von einer Gruppe ausgeliefert werden.
Eine Gruppe legt fest, welche Nodes einen Hostnamen ausliefern. Sie wählt nicht aus, welches Mitglied ein Client erreicht: Das hängt von DNS oder einem Load Balancer vor den Mitgliedern ab; siehe DNS und Einen Load Balancer davorschalten.
Voraussetzungen und Berechtigungen
Abschnitt betitelt „Voraussetzungen und Berechtigungen“- Mitglieder sind nginx-Nodes, deren Daemon die Fähigkeit
ingress_group_v1meldet, was der nginx-Daemon von 2.11 tut. Ein Node kann mehreren Gruppen angehören. - Das Erstellen einer Gruppe und alles, was sie vergrößert (Mitglieder hinzufügen oder neu ordnen, ihre Einstellungen ändern, Routen oder Domains darauf platzieren), erfordert Business oder Enterprise, wie Workload Availability. Bestehende Gruppen liefern auch ohne diesen Tarif weiter aus, und das Entfernen von Mitgliedern oder das Löschen einer Gruppe ist immer erlaubt.
- Gruppen haben eigene Berechtigungen, die breit oder auf dem Node-Ordner der Gruppe vergeben werden. Das Ansehen erfordert
ingress:groups:view; das Erstellen, Ändern und Löschen von Gruppen und ihren Mitgliedern erfordertingress:groups:manage(das Ansehen einschließt) auf diesem Ordner, und das Hinzufügen eines Nodes erfordert zusätzlichnodes:manageauf diesem Node. Node-Berechtigungen allein zeigen keine Gruppen an. - Das Platzieren einer Route oder Domain auf einer Gruppe erfordert
ingress:groups:viewauf der Gruppe undproxy:createbzw.domains:create, das jedes Mitglied abdeckt: breit, im Zielordner oder über eine Berechtigung auf jeden Mitglieds-Node. Die Listen der Ingress Nodes bieten nur Gruppen an, die Sie ansehen dürfen. Das Speichern einer Route oder Domain, die auf ihrer Gruppe bleibt, erfordert keine Gruppenberechtigung; die integrierte Operator-Gruppe hatingress:groups:view.
Eine Gruppe erstellen
Abschnitt betitelt „Eine Gruppe erstellen“- Öffnen Sie Routes → Ingress Groups und wählen Sie New Group.
- Geben Sie einen Namen, optional eine Beschreibung und einen Ordner ein und wählen Sie die Mitglieds-Nodes in der Reihenfolge der Standortpräferenz.
- Öffnen Sie die Gruppe, um für jedes Mitglied State, Ingress health und die Auslieferung der Routen der Gruppe zu verfolgen.
Auf der Gruppenseite können Sie Mitglieder hinzufügen, entfernen und neu ordnen und für jede Route sehen, was jedes Mitglied angewendet hat: den Konfigurations-Hash, die Zertifikatsversion oder den Grund des Fehlschlags. Die Seite zeigt außerdem die Adressen, die DNS für die Domains der Gruppe veröffentlicht.
Dieselben Operationen sind über /api/ingress-groups und das MCP-Werkzeug manage_ingress_group verfügbar.
Routen und Domains von einer Gruppe ausliefern
Abschnitt betitelt „Routen und Domains von einer Gruppe ausliefern“Wenn Sie eine Route oder Domain erstellen, bietet die Liste der Ingress Nodes auch Ingress groups (served by every member) an. Eine Route, die für eine Domain auf einer Gruppe erstellt wird, landet in dieser Gruppe. Übergeben Sie über die API und MCP ingressGroupId statt nodeId (nginxNodeId bei Domains).
Um eine bestehende Route oder Domain zu verschieben, verwenden Sie ihre Details in der Konsole oder convert_route und convert_domain. Das Verschieben auf eine Gruppe erfolgt ohne Ausfallzeit: Jedes neue Mitglied erhält zuerst die Konfiguration und die Zertifikate, und DNS ändert sich zuletzt. Das Zurückverschieben auf einen Node (ingressGroupId: null plus den Mitglieds-Node) ändert zuerst DNS und bereinigt danach die anderen Mitglieder. Ein Hostname muss über jeden Node und jedes Gruppenmitglied, auf dem er ausgeliefert wird, eindeutig sein.
Eine Route einer Gruppe listet die Nodes auf, die sie ausliefern (servingNodeIds), ihre Gruppe und die Auslieferung auf jedem Mitglied (ingressDelivery).
Mitglieder
Abschnitt betitelt „Mitglieder“| Zustand | Bedeutung |
|---|---|
| Joining | Der Node erhält jede Routenkonfiguration, jedes Zertifikat und jede Secure-Link-Quelle der Gruppe. Er ist noch nicht in DNS veröffentlicht. Ein Node, der offline ist, bleibt im Zustand Joining, bis er sich erneut verbindet. |
| Active | Der Node liefert aus und ist in DNS veröffentlicht. |
| Draining | Der Node liefert noch aus, wurde aber aus DNS zurückgezogen. Er wird entfernt, sobald kein öffentlicher Name der Gruppe mehr auf ihn aufgelöst wird und die DNS-TTL abgelaufen ist, höchstens nach 24 Stunden. |
Das Entfernen eines Mitglieds zieht es zuerst aus DNS zurück und lässt es auslaufen. Bei einem auslaufenden Mitglied entfernt Remove now (force in der API) es sofort, während zwischengespeicherte DNS-Antworten Clients noch dorthin schicken können. Das letzte aktive Mitglied einer Gruppe, die noch Routen oder Domains ausliefert, kann nicht entfernt werden, und nur eine Gruppe ohne Routen und Domains kann gelöscht werden.
Auslieferung und Mitglieder, die offline sind
Abschnitt betitelt „Auslieferung und Mitglieder, die offline sind“Opfield liefert jede Änderung an jedes Mitglied aus. Das Bearbeiten einer Route einer Gruppe funktioniert auch, wenn ein Mitglied offline ist: Dieses Mitglied wird als ausstehend erfasst und holt nach, sobald es sich erneut verbindet. Opfield repariert fehlende oder veraltete Konfigurationen und Zertifikatskopien jede Minute und immer dann, wenn sich ein Mitglied erneut verbindet. Wird ein Update abgelehnt, nachdem einige Mitglieder es bereits übernommen haben, erhalten diese Mitglieder die vorherige Route zurück.
Zertifikate
Abschnitt betitelt „Zertifikate“Jedes Mitglied hält eine Kopie jedes Zertifikats, das seine Routen verwenden, und Verlängerungen erreichen jedes Mitglied. HTTP-01-Challenges werden auf jedem Mitglied platziert, das online ist. Da DNS eine Validierungsanfrage an jedes Mitglied schicken kann, auch an eines, das offline ist, werden Zertifikate für Namen auf einer von Cloudflare verwalteten Gruppen-Domain mit DNS-01 über den Cloudflare-Connector ausgestellt und verlängert, was von keinem Ingress Node abhängt.
Zustand und Logs
Abschnitt betitelt „Zustand und Logs“Der Health-Zustand einer Route wird über jedes Mitglied geprüft: Eine Route ist degraded, wenn ein Mitglied die Prüfung nicht besteht, und offline, wenn kein Mitglied sie ausliefert. Jedes Mitglied schreibt seine eigenen nginx-Logs; die Log-Ansicht und der Verlauf der Route führen die Zeilen aller Mitglieder nach Zeit zusammen.
Health-Endpunkt des Ingress
Abschnitt betitelt „Health-Endpunkt des Ingress“Jeder von Opfield gerenderte Serverblock und der Standardserver beantworten den reservierten Pfad /.well-known/opfield-ingress-health. Die Antwort kommt vom Node selbst und funktioniert daher weiter, während Opfield nicht erreichbar ist:
| Status | Bedeutung |
|---|---|
200 mit JSON "status": "serving" |
nginx führt die Konfiguration des letzten erfolgreichen Reloads des Daemons aus, und auf einem Node, der Secure Links transportiert, ist mindestens ein Relay-Transport nutzbar |
503 mit JSON "status": "unavailable" und reasons |
nginx führt nicht die aktuelle Konfiguration aus, oder für seine Secure Links ist kein Relay-Transport verbunden |
502 |
der nginx-Daemon läuft nicht |
Für Prüfungen, die ein Mitglied über die IP-Adresse ansprechen, beantwortet der Node außerdem den reservierten Hostnamen ingress-health.opfield.invalid auf den Ports 80 und 443. Auf Port 443 verwendet er ein selbstsigniertes Zertifikat. Monitore, die mit dem früheren Pfad /.well-known/gateway-ingress-health oder dem Namen ingress-health.gateway.invalid eingerichtet wurden, funktionieren weiterhin. Der Endpunkt ist von Wartungsmodus, Access Lists und Basic Auth ausgenommen.
Der DNS-Failover-Modus der Gruppe ist none: Für eine von Cloudflare verwaltete Gruppen-Domain veröffentlicht Opfield die Adresse jedes aktiven Mitglieds, sodass Clients im Round-Robin-Verfahren verteilt werden. Diese Einträge werden nicht auf ihren Zustand geprüft, daher erhält ein nicht erreichbares Mitglied weiterhin seinen Anteil an Clients, bis es aus der Gruppe entfernt wird. Mitglieder ohne erkannte öffentliche Ingress-Adresse werden nicht veröffentlicht. Externes DNS verwalten weiterhin Sie selbst; Opfield prüft nur, dass es auf Mitglieder zeigt.
Einen Load Balancer davorschalten
Abschnitt betitelt „Einen Load Balancer davorschalten“Schalten Sie für ein Failover zwischen Mitgliedern einen Load Balancer mit Health Checks davor. Mit Cloudflare Load Balancing:
- Erstellen Sie einen Pool, dessen Origins die öffentlichen Adressen der aktiven Mitglieder der Gruppe sind.
- Hängen Sie einen Health-Monitor für den Pfad
/.well-known/opfield-ingress-healthan, der200erwartet. Verwenden Sie HTTP auf Port 80 mit dem Host-Headeringress-health.opfield.invalidoder einem Hostnamen, den die Gruppe ausliefert; schalten Sie bei einem HTTPS-Monitor auf den reservierten Hostnamen die Zertifikatsprüfung aus, da dieser Name ein selbstsigniertes Zertifikat verwendet. - Erstellen Sie den Load Balancer für den Hostnamen, den Ihre Routen ausliefern, mit diesem Pool.
Der Cloudflare-Connector von Opfield erstellt, ändert oder löscht niemals Cloudflare-Load-Balancer, -Pools oder -Monitore. Wenn Sie Mitglieder hinzufügen oder entfernen, aktualisieren Sie den Pool selbst. Für eine von Cloudflare verwaltete Gruppen-Domain pflegt Opfield weiterhin die oben beschriebenen einfachen DNS-Einträge.