Während die standardmäßige Kubernetes-Ingress-Ressource sich hervorragend für die Bereitstellung und Konfiguration eines grundlegenden Ingress-Lastausgleichs eignet, enthält sie nicht die Art von Anpassungsfunktionen, die erforderlich sind, um Kubernetes produktionsreif zu machen. Stattdessen müssen Nicht-NGINX-Benutzer Anmerkungen, ConfigMaps und benutzerdefinierte Vorlagen verwenden, die fehleranfällig, schwierig zu verwenden und nicht sicher sind und denen eine feinkörnige Bereichsabgrenzung fehlt. NGINX-Ingress-Ressourcen sind unsere Antwort auf dieses Problem.
NGINX Ingress-Ressourcen stehen sowohl für die NGINX Open Source- als auch für die NGINX Plus-basierten Versionen des NGINX Ingress Controllers zur Verfügung. Sie bieten einen nativen, typsicheren und klar strukturierten Konfigurationsstil, der Ihnen die Umsetzung von Ingress-Lastausgleich deutlich erleichtert. In diesem Blog stellen wir zwei Funktionen vor, die mit NGINX Ingress Controller 1.11.0 eingeführt wurden und Ihnen die Konfiguration von WAF- und Lastausgleichsrichtlinien vereinfachen:
NGINX Ingress Controller 1.11.0 erweitert die TransportServer (TS)-Ressource in den folgenden Punkten:
Hinweis: Die Ergänzungen der TransportServer-Ressource in Version 1.11.0 befinden sich als Technologievorschau in aktiver Entwicklung. Wir werden sie in einer zukünftigen Version auf einen stabilen und produktionsreifen Qualitätsstandard bringen.
Im NGINX Ingress Controller haben wir Konfigurationsausschnitte für die Ressourcen VirtualServer und VirtualServerRoute (VS und VSR) eingeführt, mit denen Sie NGINX Ingress-Konfigurationen für HTTP-basierte Clients flexibel erweitern können. Mit Version 1.11.0 erweitern wir dieses Angebot um Snippets für TS-Ressourcen, sodass Sie die umfassenden Funktionen von NGINX und NGINX Plus nutzen, um TCP/UDP-basierte Dienste effizient bereitzustellen. Sie können beispielsweise Snippets einsetzen, um über IP-Adressen und Bereiche zu definieren, welche Clients über deny
- und allow
-Anweisungen Zugriff auf einen Dienst erhalten
API-Version: k8s.nginx.org/v1alpha1kind: TransportServer
Metadaten:
Name: Café
Spezifikation:
Host: Café.Beispiel.com
Server-Snippets: |
192.168.1.1 verweigern;
192.168.1.0/24 zulassen;
Upstreams:
- Name: Tea
Dienst: Tea-SVC
Port: 80
Um die Integrität eines Kubernetes-Clusters zu überwachen, berücksichtigt der NGINX Ingress Controller nicht nur Kubernetes-Sonden , die sich lokal in Anwendungs-Pods befinden, sondern überwacht auch den Status des Netzwerks zwischen TCP/UDP-basierten Upstream-Diensten, mit passiven Integritätsprüfungen zur Bewertung der Integrität laufender Transaktionen und aktiven Integritätsprüfungen (exklusiv für NGINX Plus), um Endpunkte regelmäßig mit synthetischen Verbindungsanforderungen zu prüfen.
Integritätsprüfungen sind sehr nützlich, um Stromkreise zu unterbrechen und Anwendungsausfälle zu steuern. Sie können die Integritätsprüfung über Parameter im healthCheck
-Feld der TS-Ressource anpassen, die das Prüfintervall, das Zeitlimit, Verzögerungen zwischen den Prüfungen und weitere Einstellungen festlegen.
Darüber hinaus können Sie den Upstream-Dienst und das Portziel von Integritätsprüfungen vom NGINX Ingress Controller festlegen. Dies ist in Situationen nützlich, in denen der Zustand der Upstream-Anwendung durch einen anderen Prozess oder ein anderes Subsystem, das mehrere Downstream-Komponenten der Anwendung überwacht, auf einem anderen Listener angezeigt wird.
ingressClassName
unterstützenWenn Sie eine TS-Ressource aktualisieren und anwenden, sollten Sie prüfen, ob die Konfiguration gültig ist und erfolgreich bei der jeweiligen Ingress Controller-Bereitstellung aktiviert wurde. Release 1.11.0 führt das ingressClassName
-Feld sowie eine Statusberichterstattung für die TS-Ressource ein. Das ingressClassName
-Feld sorgt dafür, dass die TS-Ressource in Umgebungen mit mehreren Bereitstellungen von einer spezifischen Ingress Controller-Bereitstellung verarbeitet wird.
Um den Status einer oder aller TS-Ressourcen anzuzeigen, führen Sie den Befehl kubectl
get
transportserver
aus. Die Ausgabe zeigt den Zustand (Valid
oder Invalid
), den Grund für die letzte Aktualisierung und bei einem einzelnen TS eine individuelle Nachricht.
$ kubectl get transportserver NAME STATUS GRUND ALTER dns-tcp Gültig HinzugefügtOderAktualisiert 47m $ kubectl describe transportserver dns-tcp . . .
Status:
Nachricht: Konfiguration für Standard/DNS-TCP wurde hinzugefügt oder aktualisiert. Grund: Hinzugefügter oder aktualisierter Status: Gültig
Wenn mehrere TS-Ressourcen um denselben Host oder Listener konkurrieren, wählt der NGINX Ingress Controller die TS-Ressource mit dem ältesten Zeitstempel aus und stellt so ein verlässliches Ergebnis sicher.
NGINX Ingress-Ressourcen erleichtern die Konfiguration und machen sie flexibler. Sie ermöglichen es Ihnen außerdem, die Verkehrssteuerung an verschiedene Teams zu delegieren und strengere privilegierte Einschränkungen für Benutzer durchzusetzen, die Anwendungsubrouten besitzen, wie in VirtualServerRoute (VSR)-Ressourcen definiert. Indem Sie den passenden Teams Zugriff auf die entsprechenden Kubernetes-Ressourcen geben, schaffen Sie mit NGINX Ingress-Ressourcen eine granulare Kontrolle über Netzwerkressourcen und begrenzen potenzielle Schäden an Anwendungen, wenn Benutzer kompromittiert oder gehackt werden.
Version 1.11.0 führt ein natives Web Application Firewall (WAF) Policy
-Objekt ein, mit dem Sie die Vorteile der Konfiguration von NGINX App Protect in Ihren Kubernetes-Bereitstellungen erweitern. Die Policy nutzt die APLogConf- und APPolicy-Objekte, die in Version 1.8.0 eingeführt wurden, und Sie können sie sowohl VirtualServer- (VS) als auch VSR-Ressourcen zuweisen. So können Sie als Sicherheitsadministrator die vollständige Kontrolle über die Ingress-Konfiguration mit VS-Ressourcen behalten und gleichzeitig Sicherheitsaufgaben durch Verweise auf VSR-Ressourcen anderen Teams übertragen.
Im folgenden Beispiel wenden wir die waf-prod
-Richtlinie auf Benutzer an, die zum Upstream webapp-prod
weitergeleitet werden. Um die Sicherheitsverantwortung für die /v2
-Route über Namespaces, die von verschiedenen Teams verwaltet werden, zu übertragen, verweist die hervorgehobene Route
-Anweisung auf eine VSR-Ressource.
API-Version: k8s.nginx.org/v1kind: VirtualServer-Metadaten: Name: Webapp-Spezifikation: Host: webapp.example.com Richtlinien: - Name: waf-prod TLS: Geheimnis: App-Geheimnis Upstreams: - Name: webapp-prod Dienst: webapp-svc Port: 80 Routen: - Pfad: /v2 Route: Test/Test - Pfad: /v1 Aktion: Pass: Webapp-Prod
Die Teams, die den test
-Namespace verwalten, können mit VSR-Ressourcen in diesem Namespace ihre eigenen Parameter und WAF-Richtlinien bestimmen.
API-Version: k8s.nginx.org/v1kind: VirtualServerRoute
Metadaten:
Name: Test
Namespace: Test
Spezifikation:
Host: webapp.example.com
Upstreams:
-Name: Webapp
Dienst: webapp-test-svc
Port: 80
Unterrouten:
- Pfad: /v2
Richtlinien:
- Name: waf-test
Aktion:
Pass: Webapp
Dieses Beispiel trennt Mandanten nach Namespace und wendet eine andere WAF-Richtlinie für den Dienst webapp-test-svc
im Namespace test
an. Es zeigt, wie Sie durch die Zuordnung von Ressourcen an verschiedene Teams und deren Kapselung in Objekten neue Funktionen testen können, ohne produktive Anwendungen zu stören.
Mit NGINX Ingress Controller 1.11.0 setzen wir unser Engagement fort, einen produktionstauglichen Ingress-Controller bereitzustellen, der flexibel, leistungsstark und benutzerfreundlich ist. Zusätzlich zu den WAF- und TS-Verbesserungen enthält Version 1.11.0 die folgenden Erweiterungen:
Richtlinienobjekten
an, bevor sie auf die Ingress-Konfiguration angewendet werdenAufbauend auf den Verbesserungen der Annotation-Validierung, die in Version 1.10.0 eingeführt wurden, validieren wir jetzt die folgenden zusätzlichen Annotationen :
Anmerkung | Validierung |
---|---|
nginx.org/client-max-body-size |
Muss ein gültiger Offset sein |
nginx.org/fail-timeout |
Muss eine gültige Zeit sein |
nginx.org/max-conns |
Muss eine gültige, nicht negative Ganzzahl sein |
nginx.org/max-fails |
Muss eine gültige, nicht negative Ganzzahl sein |
nginx.org/proxy-buffer-size |
Muss eine gültige Größe haben |
nginx.org/proxy-buffers |
Muss eine gültige Proxy-Pufferspezifikation sein |
nginx.org/proxy-connect-timeout |
Muss eine gültige Zeit sein |
nginx.org/proxy-max-temp-file-size |
Muss eine gültige Größe haben |
nginx.org/proxy-read-timeout |
Muss eine gültige Zeit sein |
nginx.org/proxy-send-timeout |
Muss eine gültige Zeit sein |
nginx.org/Upstream-Zonengröße |
Muss eine gültige Größe haben |
Ist der Wert der Annotation ungültig, wenn Sie die Ingress-Ressource anwenden, lehnt der Ingress-Controller die Ressource ab und entfernt die dazugehörige Konfiguration aus NGINX.
Der Befehl „kubectl
get
policy“
meldet jetzt den Status der Richtlinie ( Gültig
oder Ungültig
) und (für einen einzelnen TS) eine benutzerdefinierte Nachricht und den Grund für die letzte Aktualisierung.
$ kubectl get policy NAME STATE AGE webapp-policy Gültig 30 s $ kubectl describe policy webapp-policy . . .
Status:
Nachricht: Konfiguration für Standard-/Webanwendungsrichtlinie wurde hinzugefügt oder aktualisiert. Grund: Hinzugefügter oder aktualisierter Status: Gültig
NGINX Ingress Controller kann jetzt als Ingress-Controller für Apps verwendet werden, die innerhalb eines Istio-Service-Mesh ausgeführt werden. Dadurch können Benutzer die erweiterten Funktionen des NGINX Ingress Controllers in Istio-basierten Umgebungen weiterhin nutzen, ohne auf Workarounds zurückgreifen zu müssen. Diese Integration bringt zwei Anforderungen mit sich:
Um die erste Anforderung zu erfüllen, fügen Sie die folgenden Elemente in das Anmerkungsfeld
Ihrer NGINX Ingress-Bereitstellungsdatei ein.
Anmerkungen: traffic.sidecar.istio.io/includeInboundPorts: ""
traffic.sidecar.istio.io/excludeInboundPorts: „80.443“ Traffic.sidecar.istio.io/excludeOutboundIPRanges: "10.90.0.0/16,10.45.0.0/16" sidecar.istio.io/inject: "wahr"
Die zweite Anforderung wird durch eine Änderung des Verhaltens des Felds requestHeaders
erreicht. In früheren Versionen wurden mit der folgenden Konfiguration zwei Host-
Header an das Backend gesendet: $host
und der angegebene Wert bar.example.com
.
API-Version: k8s.nginx.org/v1kind: VirtualServer-Metadaten: Name: foo Spezifikation: Host: foo.example.com Upstreams: - Name: foo Port: 8080 Dienst: Backend-SVC Use-Cluster-IP: True Routen: - Pfad: "/" Aktion: Proxy: Upstream: foo RequestHeaders: Set: - Name: Hostwert: bar.example.com
Ab Version 1.11.0 wird nur der angegebene Wert gesendet. Um $host
zu senden, lassen Sie das Feld „requestHeaders“
vollständig weg.
Die Upstream-Endpunkte in der NGINX Ingress Controller-Konfiguration können jetzt mit Service-/Cluster-IP-Adressen statt mit den einzelnen IP-Adressen von Pod-Endpunkten gefüllt werden. Um NGINX Ingress Controller zu aktivieren, den Datenverkehr an Cluster‑IP‑Dienste weiterzuleiten, fügen Sie das Feld use-cluster-ip:
true
in den Upstreams-
Abschnitt Ihrer VS‑ oder VSR‑Konfiguration ein:
Upstreams: - Name: TEA-Dienst: TEA-SVC-Port: 80 use-cluster-ip: true - Name: Kaffeedienst: Kaffee-SVC-Port: 80 use-cluster-ip: wahr
Das vollständige Änderungsprotokoll für Version 1.11.0 finden Sie in den Versionshinweisen .
Um NGINX Ingress Controller für Kubernetes mit NGINX Plus und NGINX App Protect auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .
Um NGINX Ingress Controller mit NGINX Open Source auszuprobieren, können Sie den Quellcode der Version erhalten oder einen vorgefertigten Container von DockerHub herunterladen.
Eine Erörterung der Unterschiede zwischen Ingress-Controllern finden Sie in unserem Blog unter „Moment, welchen NGINX-Ingress-Controller für Kubernetes verwende ich?“ .
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."