kubernetes ingress
v3.7.1
Dieses Repo bietet eine Implementierung eines Ingress Controllers für NGINX und NGINX Plus von den Leuten hinter NGINX.
Wir schätzen den Input der Community und würden uns freuen, Sie beim nächsten Community-Call zu sehen. Bei diesen Anrufen besprechen wir PRs von Community-Mitgliedern sowie Probleme, Diskussionen und Feature-Anfragen.
Link zu Microsoft Teams : KIC – Triage von GitHub-Problemen
Meeting-ID: 298 140 979 789
Passcode: jpx5TM
Slack : Treten Sie unserem Kanal #nginx-ingress-controller im NGINX Community Slack bei, um Updates und Diskussionen zu erhalten.
Wann : 15:00 GMT / Umrechnung in Ihre Zeitzone, jeden zweiten Montag.
| Termine für Community-Anrufe |
|---|
| 07.10.2024 |
| 21.10.2024 |
| 05.11.2024 |
| 18.11.2024 |
| 02.12.2024 |
| 16.12.2024 |
Der NGINX Ingress Controller funktioniert sowohl mit NGINX als auch mit NGINX Plus und unterstützt die Standard-Ingress-Funktionen – inhaltsbasiertes Routing und TLS/SSL-Terminierung.
Darüber hinaus sind mehrere NGINX- und NGINX Plus-Funktionen als Erweiterungen der Ingress-Ressource über Annotationen und der ConfigMap-Ressource verfügbar. Zusätzlich zu HTTP unterstützt der NGINX Ingress Controller den Lastausgleich für Websocket-, gRPC-, TCP- und UDP-Anwendungen. Weitere Informationen zu den unterstützten Funktionen und Anpassungsoptionen finden Sie in den Dokumenten zu ConfigMap und Annotations.
Als Alternative zum Ingress unterstützt der NGINX Ingress Controller die Ressourcen VirtualServer und VirtualServerRoute. Sie ermöglichen Anwendungsfälle, die von der Ingress-Ressource nicht unterstützt werden, wie z. B. Verkehrsaufteilung und erweitertes inhaltsbasiertes Routing. Siehe Dokumentation zu VirtualServer- und VirtualServerRoute-Ressourcen.
TCP-, UDP- und TLS-Passthrough-Lastausgleich wird ebenfalls unterstützt. Weitere Informationen finden Sie im TransportServer-Ressourcendokument.
Lesen Sie dieses Dokument, um mehr über den NGINX Ingress Controller mit NGINX Plus zu erfahren.
Notiz
Dieses Projekt unterscheidet sich vom NGINX Ingress Controller im kubernetes/ingress-nginx-Repository. In diesem Dokument erfahren Sie mehr über die wichtigsten Unterschiede.
Der Ingress ist eine Kubernetes-Ressource, mit der Sie einen HTTP-Load-Balancer für Anwendungen konfigurieren können, die auf Kubernetes ausgeführt werden und durch einen oder mehrere Dienste dargestellt werden. Ein solcher Load Balancer ist erforderlich, um diese Anwendungen an Clients außerhalb des Kubernetes-Clusters bereitzustellen.
Die Ingress-Ressource unterstützt die folgenden Funktionen:
Inhaltsbasiertes Routing :
Hostbasiertes Routing . Leiten Sie beispielsweise Anfragen mit dem Host-Header foo.example.com an eine Gruppe von Diensten und dem Host-Header bar.example.com an eine andere Gruppe weiter.
Pfadbasiertes Routing . Beispielsweise werden Anforderungen mit dem URI, der mit /serviceA beginnt, an Dienst A und Anforderungen mit dem URI, der mit /serviceB beginnt, an Dienst B weitergeleitet.
TLS/SSL-Terminierung für jeden Hostnamen, z. B. foo.example.com .
Weitere Informationen zur Ingress-Ressource finden Sie im Ingress-Benutzerhandbuch.
Der Ingress Controller ist eine Anwendung, die in einem Cluster ausgeführt wird und einen HTTP-Load-Balancer entsprechend den Ingress-Ressourcen konfiguriert. Der Load Balancer kann ein Software-Load Balancer sein, der im Cluster ausgeführt wird, oder ein Hardware- oder Cloud-Load Balancer, der extern ausgeführt wird. Unterschiedliche Load Balancer erfordern unterschiedliche Ingress Controller-Implementierungen.
Im Fall von NGINX wird der Ingress Controller zusammen mit dem Load Balancer in einem Pod bereitgestellt.
Notiz
Die gesamte Dokumentation sollte nur mit der neuesten stabilen Version verwendet werden, die auf der Release-Seite des GitHub-Repositorys angegeben ist.
Installieren Sie den NGINX Ingress Controller mithilfe des Helm-Charts oder der Kubernetes-Manifeste.
Konfigurieren Sie den Lastausgleich für eine einfache Webanwendung:
Verwenden Sie die Ingress-Ressource. Sehen Sie sich das Café-Beispiel an.
Oder die VirtualServer-Ressource. Siehe das Beispiel für die Grundkonfiguration.
Weitere Konfigurationsbeispiele finden Sie hier.
Erfahren Sie mehr über alle verfügbaren Konfigurationen und Anpassungen in den Dokumenten.
Wir veröffentlichen NGINX Ingress Controller-Releases auf GitHub. Sehen Sie sich unsere Veröffentlichungsseite an.
Die neueste stabile Version ist 3.7.2. Für den Produktionseinsatz empfehlen wir Ihnen, die neueste stabile Version zu wählen.
Die Edge-Version eignet sich zum Experimentieren mit neuen Funktionen, die noch nicht in einer stabilen Version veröffentlicht sind. Um es zu verwenden, wählen Sie die Edge -Version aus, die aus dem neuesten Commit aus dem Hauptzweig erstellt wurde.
Um den NGINX Ingress Controller verwenden zu können, benötigen Sie Zugriff auf:
Ein NGINX-Ingress-Controller-Image.
Installationsmanifeste oder ein Helm-Diagramm.
Dokumentation und Beispiele.
Es ist wichtig, dass die Versionen der oben genannten Dinge übereinstimmen.
Die folgende Tabelle fasst die Optionen in Bezug auf Bilder, Helm-Diagramm, Manifeste, Dokumentation und Beispiele zusammen und enthält Ihre Links zu den richtigen Versionen:
| Version | Beschreibung | Bild für NGINX | Bild für NGINX Plus | Installationsmanifeste und Helmdiagramm | Dokumentation und Beispiele |
|---|---|---|---|---|---|
| Neueste stabile Version | Für den Produktionseinsatz | Verwenden Sie die 3.7.2-Images von DockerHub, GitHub Container, Amazon ECR Public Gallery oder Quay.io oder erstellen Sie Ihr eigenes Image. | Verwenden Sie die 3.7.2-Images aus der F5 Container Registry oder erstellen Sie Ihr eigenes Image. | Manifestiert. Helmkarte. | Dokumentation. Beispiele. |
| Rand/Nächtlich | Zum Ausprobieren und Experimentieren | Nutzen Sie die Edge- oder Nightly-Images von DockerHub, GitHub Container, Amazon ECR Public Gallery oder Quay.io oder erstellen Sie Ihr eigenes Image. | Bauen Sie Ihr eigenes Image auf. | Manifestiert. Helmkarte. | Dokumentation. Beispiele. |
Wir generieren SBOMs für die Binärdateien und die Docker-Images.
Die SBOMs für die Binärdateien sind auf der Release-Seite verfügbar. Die SBOMs werden mit syft generiert und sind im SPDX-Format verfügbar.
Die SBOMs für die Docker-Images sind in den Repositorys DockerHub, GitHub Container, Amazon ECR Public Gallery oder Quay.io verfügbar. Die SBOMs werden mit syft generiert und als Bescheinigung im Image-Manifest gespeichert.
Um beispielsweise das SBOM für linux/amd64 vom Docker Hub abzurufen und es mit Grype zu analysieren, können Sie den folgenden Befehl ausführen:
docker buildx imagetools inspect nginx/nginx-ingress:edge --format '{{ json (index .SBOM "linux/amd64").SPDX }}' | grypeWir freuen uns über Ihr Feedback! Wenn Sie Vorschläge haben oder Probleme mit unserem Ingress Controller haben, erstellen Sie bitte ein Issue oder senden Sie eine Pull-Anfrage auf GitHub. Sie können uns direkt über NGINX Community Slack kontaktieren.
Wenn Sie zum Projekt beitragen möchten, lesen Sie bitte unseren Beitragsleitfaden.
Für NGINX Plus-Kunden ist der NGINX Ingress Controller (bei Verwendung mit NGINX Plus) durch den Supportvertrag abgedeckt.
