Migration vom Community Ingress Controller zum F5 NGINX Ingress Controller

Herausgeber – Dieser Beitrag ist ein Auszug aus unserem umfassenden E-Book „ Verwaltung des Kubernetes-Verkehrs mit F5 NGINX“: Ein praktischer Leitfaden . Laden Sie es noch heute kostenlos herunter .

Viele Organisationen, die Kubernetes zum ersten Mal einrichten, beginnen mit dem NGINX Ingress-Controller, der von der Kubernetes-Community entwickelt und gepflegt wird ( kubernetes/ingress-nginx ). Mit zunehmender Weiterentwicklung der Kubernetes-Bereitstellungen stellen manche Organisationen jedoch fest, dass sie erweiterte Funktionen benötigen oder kommerziellen Support wünschen, während sie NGINX als Datenebene beibehalten möchten.

Eine Möglichkeit besteht darin, zum NGINX Ingress Controller zu migrieren, der von F5 NGINX entwickelt und gepflegt wird ( nginxinc/kubernetes-ingress ). Hier stellen wir vollständige Anweisungen bereit, damit Sie einige Komplikationen vermeiden können, die sich aus den Unterschieden zwischen den beiden Projekten ergeben.

Sie sind sich nicht sicher, worin sich diese Optionen unterscheiden? Lesen Sie „Leitfaden zur Auswahl eines Ingress-Controllers, Teil 4“: NGINX-Ingress-Controller-Optionen auf unserem Blog.

Um im weiteren Verlauf dieses Beitrags zwischen den beiden Projekten zu unterscheiden, bezeichnen wir den von der Kubernetes-Community verwalteten NGINX Ingress Controller ( kubernetes/ingress-nginx ) als „Community Ingress Controller“ und den von F5 NGINX verwalteten ( nginxinc/kubernetes-ingress ) als „NGINX Ingress Controller“.

Es gibt zwei Möglichkeiten, vom Community-Ingress-Controller zum NGINX-Ingress-Controller zu migrieren:

• Option 1: Migrieren mithilfe von NGINX Ingress-Ressourcen
  Dies ist die optimale Lösung, da NGINX-Ingress-Ressourcen den breiteren Satz an Ingress-Netzwerkfunktionen unterstützen, die in Kubernetes-Umgebungen auf Produktionsniveau erforderlich sind. Weitere Informationen zu NGINX Ingress-Ressourcen finden Sie in unserem Webinar „Erweiterte Kubernetes-Bereitstellungen mit NGINX Ingress-Controller “.
• Option 2: Migrieren mithilfe der Kubernetes Ingress-Ressource
  Diese Option wird empfohlen, wenn Sie zum Definieren von Ingress-Lastausgleichsregeln die standardmäßige Kubernetes-Ingress-Ressource verwenden möchten.

Option 1: Migrieren mithilfe von NGINX Ingress-Ressourcen

Mit dieser Migrationsoption verwenden Sie die standardmäßige Kubernetes-Ingress-Ressource, um Root-Funktionen festzulegen, und NGINX-Ingress-Ressourcen, um Ihre Konfiguration mit erweiterten Funktionen und Benutzerfreundlichkeit zu verbessern.

Die benutzerdefinierten Ressourcendefinitionen (CRDs) für NGINX-Ingress-Ressourcen – VirtualServer, VirtualServerRoute , TransportServer , GlobalConfiguration und Policy – ermöglichen Ihnen die einfache Delegierung der Kontrolle über verschiedene Teile der Konfiguration an unterschiedliche Teams (wie etwa AppDev- und Sicherheitsteams) und bieten außerdem mehr Konfigurationssicherheit und -validierung.

Konfigurieren der SSL-Terminierung und des HTTP-Pfad-basierten Routings

Die Tabelle ordnet die Konfiguration der SSL-Terminierung und des pfadbasierten Layer-7-Routings im Spezifikationsfeld der Standard-Kubernetes-Ingress-Ressource dem Spezifikationsfeld in der NGINX- VirtualServer -Ressource zu. Syntax und Einrückung unterscheiden sich bei den beiden Ressourcen leicht, sie erfüllen jedoch dieselben grundlegenden Ingress-Funktionen.

API-Version: networking.k8s.io/v1kind: Ingress
Metadaten:
Name: nginx-test
Spezifikation:
TLS:
- Hosts:
- foo.bar.com
Geheimname: TLS-Geheimnis
Regeln:
- Host: foo.bar.com
http:
Pfade:
- Pfad: /login
Backend: 
Servicename: login-svc
Serviceport: 80
- Pfad: /Abrechnung
Servicename: Abrechnung-Dienst
Serviceport: 80

API-Version: networking.k8s.io/v1kind: VirtualServer
Metadaten:
Name: nginx-test
Spezifikation:
Host: foo.bar.com
TLS:
Geheimnis: TLS-Geheimnis
Upstreams:
-Name: Login
Dienst: Login-SVC
Port: 80
- Name: Abrechnung 
Dienst: Abrechnungsdienst
Port: 80
Routen: 
- Pfad: /login
Aktion:
Passwort: login 
- Pfad: /billing 
Aktion: 
Passwort: billing

Konfigurieren von TCP/UDP-Lastausgleich und TLS-Passthrough

Mit dem Community-Ingress-Controller ist ein Kubernetes ConfigMap API-Objekt die einzige Möglichkeit, TCP- und UDP-Dienste verfügbar zu machen .

Mit NGINX Ingress Controller definieren TransportServer- Ressourcen eine breite Palette an Optionen für TCP/UDP- und TLS-Passthrough-Lastausgleich. TransportServer-Ressourcen werden in Verbindung mit GlobalConfiguration -Ressourcen verwendet, um eingehende und ausgehende Verbindungen zu steuern.

Weitere Informationen finden Sie unter „Support für TCP-, UDP- und TLS-Passthrough-Dienste in NGINX-Ingress-Ressourcen“ in unserem Blog.

Konvertieren Sie Community Ingress Controller-Anmerkungen in NGINX Ingress-Ressourcen

Bei produktionsreifen Kubernetes-Bereitstellungen müssen häufig grundlegende Ingress-Regeln erweitert werden, um erweiterte Anwendungsfälle zu implementieren, darunter Canary- und Blue-Green-Bereitstellungen, Verkehrsdrosselung, Manipulation des Ingress-Egress-Verkehrs und mehr.

Der Community-Ingress-Controller implementiert viele dieser Anwendungsfälle mit Kubernetes -Annotationen . Viele dieser Anmerkungen werden jedoch mit benutzerdefinierten Lua-Erweiterungen erstellt, die sich auf sehr spezifische NGINX-Ingress-Ressourcendefinitionen beziehen und daher nicht für die Implementierung erweiterter Funktionen in einer stabilen und unterstützten Produktionsumgebung geeignet sind.

In den folgenden Abschnitten zeigen wir, wie Community-Ingress-Controller-Annotationen in NGINX-Ingress-Controller-Ressourcen konvertiert werden.

• Canary-Bereitstellungen
• Verkehrssteuerung
• Header-Manipulation
• Proxying und Lastenausgleich
• mTLS-Authentifizierung
• Sitzungspersistenz (Exklusiv für NGINX Plus)

Canary-Bereitstellungen

Auch wenn Sie häufige Codeänderungen an den Workloads Ihrer Produktionscontainer vornehmen, müssen Sie die Dienste Ihrer vorhandenen Benutzer weiterhin in Anspruch nehmen. Dies ist mit Canary- und Blue-Green-Bereitstellungen möglich und Sie können sie auf der Datenebene des NGINX Ingress Controllers ausführen, um stabile und vorhersehbare Updates in Kubernetes-Umgebungen auf Produktionsniveau zu erreichen.

Die Tabelle zeigt die Felder in den NGINX VirtualServer- und VirtualServerRoute- Ressourcen, die den Community-Ingress-Controller-Anmerkungen für Canary-Bereitstellungen entsprechen.

Der Community-Ingress-Controller wertet Canary-Annotationen in dieser Rangfolge aus:

1. nginx.ingress.kubernetes.io/canary-by-header
2. nginx.ingress.kubernetes.io/canary-by-cookie
3. nginx.ingress.kubernetes.io/canary-by-weight

Damit der NGINX Ingress Controller sie auf die gleiche Weise auswerten kann, müssen sie in dieser Reihenfolge im Manifest des NGINX VirtualServer oder VirtualServerRoute erscheinen.

nginx.ingress.kubernetes.io/canary: „true“nginx.ingress.kubernetes.io/canary-by-header: „httpHeader“

Übereinstimmungen : - Bedingungen: - Header: httpHeader-Wert: nie Aktion: Pass: Echo - Header: httpHeader-Wert: immer Aktion: Pass: Echo-Canary Aktion: Pass: Echo

nginx.ingress.kubernetes.io/canary: „true“nginx.ingress.kubernetes.io/canary-by-header: „httpHeader“ nginx.ingress.kubernetes.io/canary-by-header-value: „ mein-Wert “

Übereinstimmungen: - Bedingungen: - Header: httpHeader-Wert: mein-Wert -Aktion: Pass: Echo-Canary-Aktion: Pass: Echo

nginx.ingress.kubernetes.io/canary: „true“nginx.ingress.kubernetes.io/canary-by-cookie: „Cookiename“

Übereinstimmungen: - Bedingungen:
- Cookie: Cookiename
Wert: nie
Aktion:
Pass: Echo 
- Cookie: Cookiename
Wert: immer
Aktion:
Pass: Echo-Canary
Aktion:
Pass: Echo

nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-Gewicht: "10"

Spaltmaße : - Gewicht: 90 Aktion: Pass: Echo - Gewicht: 10 Aktion: Pass: Echo-Canary

Verkehrssteuerung

In Microservices-Umgebungen, in denen Anwendungen von Natur aus flüchtig sind und daher eher Fehlermeldungen zurückgeben, machen DevOps-Teams in großem Umfang Gebrauch von Richtlinien zur Verkehrssteuerung – wie z. B. Unterbrechung der Stromkreise oder Begrenzung der Geschwindigkeit und Verbindung –, um Fehlerzustände zu verhindern, wenn Anwendungen nicht in einwandfreiem Zustand sind oder nicht wie erwartet funktionieren.

Die Tabelle zeigt die Felder in den NGINX VirtualServer- und VirtualServerRoute- Ressourcen, die den Ingress-Controller-Anmerkungen der Community für Ratenbegrenzung , benutzerdefinierte HTTP-Fehler , ein benutzerdefiniertes Standard-Backend und URI-Umschreiben entsprechen.

nginx.ingress.kubernetes.io/custom-http-errors: " Code " nginx.ingress.kubernetes.io/default-backend: "default-svc"

Fehlerseiten : - Codes: [ Code ] Weiterleitung: Code: 301-URL: Standard-SVC

nginx.ingress.kubernetes.io/limit-connections: " Zahl "

http-Snippets : | limit_conn_zone $binary_remote_addr zone= Zonenname : Größe ; Routen: – Pfad: / Pfad Standort-Snippets : | limit_conn Zonenname Nummer ;

nginx.ingress.kubernetes.io/limit-rate: " Zahl " nginx.ingress.kubernetes.io/limit-rate-after: " Zahl "

Standortausschnitte: | Limit_Rate -Zahl ; Limit_Rate_nach -Zahl ;

nginx.ingress.kubernetes.io/limit-rpm: " Zahl " nginx.ingress.kubernetes.io/limit-burst-multiplier: " Multiplikator "

rateLimit : Rate: Zahl r/m Burst: Zahl * Multiplikatorschlüssel : ${binary_remote_addr} zoneSize: Größe

nginx.ingress.kubernetes.io/limit-rps: " Zahl " nginx.ingress.kubernetes.io/limit-burst-multiplier: " Multiplikator "

rateLimit: Rate: Zahl r/s Burst: Zahl * Multiplikatorschlüssel : ${binary_remote_addr} zoneSize: Größe

nginx.ingress.kubernetes.io/limit-whitelist: " CIDR "

http-Snippets: | Server-Snippets : |

nginx.ingress.kubernetes.io/rewrite-target: " URI "

Pfad umschreiben : " URI "

Wie in der Tabelle angegeben, enthalten die NGINX-Ingress-Ressourcen zum Zeitpunkt des Schreibens dieses Artikels keine Felder, die die folgenden vier Community-Ingress-Controller-Anmerkungen direkt übersetzen, und Sie müssen Snippets verwenden. Für zukünftige Versionen von NGINX Ingress Controller ist eine direkte Unterstützung der vier Anmerkungen mithilfe von Policy- Ressourcen geplant.

• nginx.ingress.kubernetes.io/limit-connections
• nginx.ingress.kubernetes.io/limit-rate
• nginx.ingress.kubernetes.io/limit-rate-after
• nginx.ingress.kubernetes.io/limit-whitelist

Header-Manipulation

Die Manipulation von HTTP-Headern ist in vielen Anwendungsfällen nützlich, da sie zusätzliche Informationen enthalten, die für die an einer HTTP-Transaktion beteiligten Systeme wichtig und relevant sind. Beispielsweise unterstützt der Community-Ingress-Controller das Aktivieren und Festlegen von CORS-Headern ( Cross-Origin Resource Sharing ), die mit AJAX-Anwendungen verwendet werden, bei denen Front-End-JavaScript-Code aus einem Browser eine Verbindung zu einer Back-End-App oder einem Webserver herstellt.

Die Tabelle zeigt die Felder in den NGINX VirtualServer- und VirtualServerRoute- Ressourcen, die den Community-Ingress-Controller-Annotationen zur Header-Manipulation entsprechen.

nginx.ingress.kubernetes.io/enable-cors: „true“nginx.ingress.kubernetes.io/cors-allow-credentials: „true“ nginx.ingress.kubernetes.io/cors-allow-headers: „X-Forwarded-For“ nginx.ingress.kubernetes.io/cors-allow-methods: „PUT, GET, POST, OPTIONS“ nginx.ingress.kubernetes.io/cors-allow-origin: „*“ nginx.ingress.kubernetes.io/cors-max-age: „ Sekunden “

responseHeaders : hinzufügen: - Name: Access-Control-Allow-Credentials-Wert: „true“ – Name: Access-Control-Allow-Headers-Wert: "X-Forwarded-For" - Name: Access-Control-Allow-Methods-Wert: "PUT, GET, POST, OPTIONEN" - Name: Access-Control-Allow-Origin-Wert: "*" - Name: Access-Control-Max-Age-Wert: " Sekunden "

Proxying und Lastenausgleich

Je nach konkretem Anwendungsfall möchten Sie möglicherweise weitere Proxy- und Lastausgleichsfunktionen im NGINX Ingress Controller konfigurieren. Zu diesen Funktionen gehören das Festlegen des Lastausgleichsalgorithmus sowie Timeout- und Puffereinstellungen für Proxyverbindungen.

Die Tabelle zeigt die Anweisungen im Upstream- Feld der NGINX VirtualServer- und VirtualServerRoute-Ressourcen, die den Community-Ingress-Controller-Annotationen für benutzerdefinierten NGINX-Lastausgleich , Proxy-Timeouts , Proxy-Pufferung und Routing-Verbindungen zur Cluster-IP-Adresse und zum Port eines Dienstes entsprechen .

nginx.ingress.kubernetes.io/load-balance

lb-Methode

nginx.ingress.kubernetes.io/proxy-buffering

Pufferung

nginx.ingress.kubernetes.io/proxy-buffers-numbernginx.ingress.kubernetes.io/proxy-buffer-size

Puffer

nginx.ingress.kubernetes.io/proxy-connect-timeout

Verbindungs-Timeout

nginx.ingress.kubernetes.io/proxy-next-upstream

Weiter-Upstream

nginx.ingress.kubernetes.io/proxy-next-upstream-timeout

nächstes Upstream-Timeout

nginx.ingress.kubernetes.io/proxy-read-timeout

Lesezeitlimit

nginx.ingress.kubernetes.io/proxy-send-timeout

Sende-Timeout

nginx.ingress.kubernetes.io/service-upstream

Cluster-IP verwenden

mTLS-Authentifizierung

Ein Service Mesh ist besonders in einer strikten Zero-Trust-Umgebung nützlich, in der verteilte Anwendungen innerhalb eines Clusters durch gegenseitige Authentifizierung sicher kommunizieren. Was wäre, wenn wir für den ein- und ausgehenden Datenverkehr des Clusters (Nord-Süd-Verkehr) dasselbe Sicherheitsniveau einführen müssten?

Wir können die mTLS-Authentifizierung auf der Ingress Controller-Ebene so konfigurieren, dass sich die Endsysteme externer Verbindungen gegenseitig durch Vorlage eines gültigen Zertifikats authentifizieren.

Die Tabelle zeigt die Felder in den NGINX- Richtlinienressourcen , die den Community-Ingress-Controller-Annotationen für die Client-Zertifikatauthentifizierung und die Back-End-Zertifikatauthentifizierung entsprechen.

nginx.ingress.kubernetes.io/auth-tls-secret: secretName
nginx.ingress.kubernetes.io/auth-tls-verify-client: „ein“
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"

ingressMTLS : clientCertSecret: geheimer Name verifyClient: „ein“ verifyDepth: 1

nginx.ingress.kubernetes.io/proxy-ssl-secret: „Geheimnisname“
nginx.ingress.kubernetes.io/proxy-ssl-verify: „an|aus“
nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: „1“ nginx.ingress.kubernetes.io/proxy-ssl-protocols: „TLSv1.2“
nginx.ingress.kubernetes.io/proxy-ssl-ciphers: „STANDARD“
nginx.ingress.kubernetes.io/proxy-ssl-name: „Servername“
nginx.ingress.kubernetes.io/proxy-ssl-server-name: „an|aus“

egressMTLS : tlsSecret: geheimer Name verifyServer: true|false verifyDepth: 1 Protokolle: TLSv1.2-Chiffren: STANDARD sslName: Servername ServerName: true|false

Sitzungspersistenz (Exklusiv für NGINX Plus)

Die Tabelle zeigt die Felder in den NGINX- Richtlinienressourcen , die exklusiv für den auf NGINX Plus basierenden NGINX-Ingress-Controller gelten und den Community-Ingress-Controller-Anmerkungen für die Sitzungspersistenz (Affinität) entsprechen.

nginx.ingress.kubernetes.io/affinity: „Cookie“ nginx.ingress.kubernetes.io/session-cookie-name: „Cookiename“ nginx.ingress.kubernetes.io/session-cookie-expires: „ x “ nginx.ingress.kubernetes.io/session-cookie-path: „/Route“ nginx.ingress.kubernetes.io/session-cookie-secure: „true“

sessionCookie : aktivieren: true Name: cookieName läuft ab: x h Pfad: /route secure: true

Option 2: Migrieren mithilfe der Kubernetes Ingress-Ressource

Die zweite Möglichkeit zur Migration vom Community-Ingress-Controller zum NGINX-Ingress-Controller besteht darin, nur Anmerkungen und ConfigMaps in der Standard-Kubernetes-Ingress-Ressource zu verwenden und sich möglicherweise auf die Verarbeitung im „Master/Minion “-Stil zu verlassen. Dadurch bleibt die gesamte Konfiguration im Ingress-Objekt erhalten.

Notiz: Ändern Sie mit dieser Methode nicht das Spezifikationsfeld der Ingress-Ressource.

Erweiterte Konfiguration mit Anmerkungen

In der folgenden Tabelle sind die Ingress-Controller-Annotationen der Community aufgeführt, die direkt den vom NGINX Ingress Controller unterstützten Annotationen entsprechen.

nginx.ingress.kubernetes.io/configuration-snippet : |

nginx.org/location-snippets : |

nginx.ingress.kubernetes.io/load-balance1

nginx.org/lb-Methode

zufällig zwei least_conn

nginx.ingress.kubernetes.io/proxy-buffering : „an|aus“

nginx.org/proxy-buffering : "Richtig|Falsch"

Proxy-Pufferung

nginx.ingress.kubernetes.io/proxy-buffers-number : " Zahl " nginx.ingress.kubernetes.io/proxy-buffer-size : " x k"

nginx.org/proxy-buffers : „ Zahl 4k|8k“ nginx.org/proxy-buffers-size : „4k|8k“

Proxy-Puffer Proxy-Puffergröße

nginx.ingress.kubernetes.io/proxy-connect-timeout : " Sekunden "

nginx.org/proxy-connect-timeout: : " Sekunden s"

Proxy_Verbindungs-Timeout

nginx.ingress.kubernetes.io/proxy-read-timeout : " Sekunden "

nginx.org/proxy-read-timeout : " Sekunden s"

Proxy_Lese-Timeout

nginx.ingress.kubernetes.io/proxy-send-timeout : " Sekunden "

nginx.org/proxy-send-timeout : " Sekunden s"

Proxy_Sendezeitüberschreitung

nginx.ingress.kubernetes.io/rewrite-target : " URI "

nginx.org/rewrites : „serviceName= svc rewrite= URI “

umschreiben

nginx.ingress.kubernetes.io/server-snippet : |

nginx.org/server-snippets : |

nginx.ingress.kubernetes.io/ssl-redirect : „wahr|falsch“

ingress.kubernetes.io/ssl-redirect : "Richtig|Falsch"

¹Der Community-Ingress-Controller verwendet Lua, um einige seiner Lastausgleichsalgorithmen zu implementieren. NGINX Ingress Controller hat nicht für alle ein Äquivalent.

²Leitet HTTP-Verkehr auf HTTPS um. Der Community-Ingress-Controller implementiert dies mit Lua-Code, während der NGINX-Ingress-Controller native NGINX- If -Bedingungen verwendet.

In der folgenden Tabelle sind die Annotationen des Community-Ingress-Controllers aufgeführt, die direkt den Annotationen entsprechen, die vom NGINX Ingress Controller basierend auf NGINX Plus unterstützt werden.

nginx.ingress.kubernetes.io/affinity : "Cookie" nginx.ingress.kubernetes.io/session-cookie-name : " Cookiename " nginx.ingress.kubernetes.io/session-cookie-expires : " Sekunden " nginx.ingress.kubernetes.io/session-cookie-path : "/ Route "

nginx.com/sticky-cookie-services : „serviceName= Beispiel-svc Cookie-Name läuft ab= Zeitpfad =/ Route “

Notiz: Der auf NGINX Plus basierende NGINX Ingress Controller verfügt über zusätzliche Anmerkungen für Funktionen, die der Community-Ingress-Controller überhaupt nicht unterstützt, darunter aktive Integritätsprüfungen und Authentifizierung mit JSON Web Tokens (JWTs).

Globale Konfiguration mit ConfigMaps

Die folgende Tabelle ordnet die ConfigMap-Schlüssel des Community-Ingress-Controllers den direkt entsprechenden ConfigMap-Schlüsseln des NGINX-Ingress-Controllers zu. Beachten Sie, dass einige ConfigMap-Schlüsselnamen identisch sind. Darüber hinaus verfügen sowohl der Community-Ingress-Controller als auch der NGINX-Ingress-Controller über ConfigMaps-Schlüssel, die der andere nicht hat (nicht in der Tabelle angezeigt).

Deaktivieren des Zugriffsprotokolls

Zugriff-Abmeldung

Fehlerprotokollebene

Fehlerprotokollebene

hsts

hsts

hsts-inklusive-subdomains

hsts-inklusive-subdomains

hsts-max-alter

hsts-max-alter

http-Ausschnitt

http-Ausschnitte

am Leben erhalten

Keepaliv-Zeitüberschreitung

Keep-Alive-Anfragen

Keepalive-Anfragen

Lastausgleich

lb-Methode

Standortausschnitt

Standortausschnitte

log-format-escape-json : „wahr“

Protokollformat-Escapen : "json"

Protokollformat-Stream

Stream-Log-Format

Log-Format-Upstream

Protokollformat

Hauptausschnitt

Hauptausschnitte

Maximale Anzahl an Arbeiterverbindungen 

Arbeiterverbindungen

Max-Worker-Öffnen-Dateien

Arbeiter-Rlimit-Nofile

Proxy-Körpergröße

Client-Max-Körpergröße

Proxy-Pufferung

Proxy-Pufferung

Proxy-Puffernummer : " Nummer " Proxy-Puffergröße : " Größe "

Proxy-Puffer : Zahlengröße

Proxy-Verbindungs-Timeout

Proxy-Verbindungs-Timeout

Proxy-Lese-Timeout

Proxy-Lese-Timeout

Proxy-Sende-Timeout

Proxy-Sende-Timeout

Servername-Hash-Bucket-Größe

Servernamen-Hash-Bucket-Größe

Servername-Hash-Maximalgröße

Servernamen-Hash-Maximalgröße

Server-Ausschnitt

Server-Snippets

Server-Token

Server-Token

SSL-Chiffren

SSL-Chiffren

SSL-DH-Parameter

SSL-Dhparam-Datei

SSL-Protokolle

SSL-Protokolle

SSL-Weiterleitung

SSL-Weiterleitung

Upstream-Keepalive-Verbindungen

am Leben bleiben

benutze http2

http2

Proxy-Protokoll verwenden

Proxy-Protokoll

Variablen-Hash-Bucket-Größe

Variablen-Hash-Bucket-Größe

Arbeiter-CPU-Affinität

Arbeiter-CPU-Affinität

Arbeitsprozesse

Arbeitsprozesse

Zeitüberschreitung beim Herunterfahren des Arbeiters

Zeitüberschreitung beim Herunterfahren des Arbeiters

Zusammenfassung

Sie können vom Community-Ingress-Controller zum NGINX-Ingress-Controller migrieren, indem Sie entweder benutzerdefinierte NGINX-Ingress-Ressourcen oder die standardmäßige Kubernetes-Ingress-Ressource mit Anmerkungen und ConfigMaps verwenden. Die erste Option unterstützt ein breiteres Spektrum an Netzwerkfunktionen und ist daher besser für Kubernetes-Umgebungen auf Produktionsniveau geeignet.

Dieser Beitrag ist ein Auszug aus unserem umfassenden E-Book „ Verwaltung des Kubernetes-Verkehrs mit F5 NGINX“: Ein praktischer Leitfaden . Laden Sie es noch heute kostenlos herunter .

Testen Sie den auf NGINX Plus basierenden NGINX Ingress Controller noch heute selbst in einer kostenlosen 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .