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: Migration mit NGINX Ingress-Ressourcen
  Wir empfehlen diese Lösung, da NGINX Ingress-Ressourcen die umfassenderen Ingress-Netzwerkfunktionen bieten, die Sie für produktionsreife Kubernetes-Umgebungen benötigen. Mehr zu NGINX Ingress-Ressourcen erfahren Sie in unserem Webinar Advanced Kubernetes Deployments mit NGINX Ingress Controller.
• Option 2: Migration mit der Kubernetes Ingress-Ressource
  Wir empfehlen diese Option, wenn Sie sich darauf festgelegt haben, die standardmäßige Kubernetes Ingress-Ressource zur Definition von Ingress-Lastausgleichsregeln zu verwenden.

Option 1: Migration mit NGINX Ingress-Ressourcen

Mit dieser Migrationsoption nutzen Sie die standardmäßige Kubernetes-Ingress-Ressource, um grundlegende Funktionen festzulegen, und NGINX Ingress-Ressourcen, um Ihre Konfiguration mit erweiterten Funktionen und mehr Benutzerfreundlichkeit zu optimieren.

Die benutzerdefinierten Ressourcendefinitionen (CRDs) für NGINX Ingress-Ressourcen – VirtualServer, VirtualServerRoute, TransportServer, GlobalConfiguration und Policy – erlauben Ihnen, die Kontrolle über verschiedene Teile der Systemkonfiguration einfach an unterschiedliche Teams (wie AppDev- und Sicherheitsteams) zu übergeben und sorgen gleichzeitig für mehr Sicherheit und Validierung bei der Konfiguration.

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

Die Tabelle vergleicht die Konfiguration der SSL-Terminierung und des pfad-basierten Routings auf Layer 7 im spec-Feld der standardmäßigen Kubernetes Ingress-Ressource mit dem spec-Feld der NGINX VirtualServer-Ressource. Syntax und Einrückung unterscheiden sich leicht, doch beide Ressourcen erfüllen die gleichen 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 in unserem Blog unter Support für TCP-, UDP- und TLS-Passthrough-Dienste in NGINX Ingress-Ressourcen.

Community-Ingress-Controller-Anmerkungen in NGINX-Ingress-Ressourcen umwandeln

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 setzt viele dieser Anwendungsfälle mithilfe von Kubernetes-Annotations um. Wir verwenden allerdings viele dieser Annotations mit individuellen Lua-Erweiterungen, die auf sehr spezifische NGINX-Ingress-Ressourcendefinitionen zugeschnitten sind und sich daher nicht eignen, um erweiterte Funktionen in einer stabilen und unterstützten Produktionsumgebung umzusetzen.

In den folgenden Abschnitten zeigen wir Ihnen, wie Sie Community-Ingress-Controller-Annotationen in Ressourcen des NGINX Ingress Controllers umwandeln.

• 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 Felder in den NGINX VirtualServer- und VirtualServerRoute-Ressourcen, die den Annotationen des Community-Ingress-Controllers 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 zu Ratenbegrenzung, benutzerdefinierten HTTP-Fehlern, einem benutzerdefinierten Standard-Backend und URI-Umschreibungen 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} Zonengröße: 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} Zonengröße: Größe

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

http-Snippets: | Server-Snippets : |

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

Pfad umschreiben : " URI "

Wie die Tabelle zeigt, enthalten die NGINX-Ingress-Ressourcen derzeit keine Felder, die die folgenden vier Community-Ingress-Controller-Anmerkungen direkt abbilden. Deshalb müssen Sie Snippets verwenden. Direkte Unterstützung der vier Anmerkungen über Policy-Ressourcen ist für künftige Versionen des NGINX Ingress Controllers 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

Das Manipulieren von HTTP-Headern hilft in vielen Fällen, da sie wichtige Zusatzinformationen für Systeme liefern, die an einer HTTP-Transaktion beteiligt sind. So ermöglicht der Community-Ingress-Controller beispielsweise das Aktivieren und Setzen von Cross-Origin Resource Sharing (CORS)-Headern. Diese nutzt man bei AJAX-Anwendungen, bei denen JavaScript im Browser mit einer Backend-App oder einem Webserver kommuniziert.

Die Tabelle zeigt die Felder in NGINX VirtualServer- und VirtualServerRoute-Ressourcen, die den Annotationen des Community Ingress Controllers 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 Angaben im upstream-Feld der NGINX VirtualServer- und VirtualServerRoute-Ressourcen, die den Annotations des Ingress-Controllers aus der Community für benutzerdefinierten NGINX-Lastausgleich, Proxy-Timeouts, Proxy-Pufferung und die Anforderungsweiterleitung zu Cluster-IP-Adressen und Ports 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 der NGINX-Policy-Ressourcen, die den Annotationen des Community Ingress Controllers für Client-Zertifikatsauthentifizierung und Backend-Zertifikatsauthentifizierung 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 Felder in NGINX Policy-Ressourcen, die nur im NGINX Ingress Controller auf Basis von NGINX Plus vorkommen und den Anmerkungen des Community-Ingress-Controllers zur 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: Migration mit der Kubernetes Ingress-Ressource

Die zweite Option für die Migration vom Community-Ingress-Controller zum NGINX Ingress Controller besteht darin, ausschließlich Annotationen und ConfigMaps im Standard-Kubernetes-Ingress-Objekt zu verwenden und möglicherweise auf eine Master-/Minion-Verarbeitung zu setzen. So halten Sie die gesamte Konfiguration im Ingress-Objekt.

Hinweis: Verändern Sie bei dieser Methode das spec-Feld der Ingress-Ressource nicht.

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 auf den NGINX Ingress Controller umsteigen, indem Sie entweder benutzerdefinierte NGINX Ingress-Ressourcen oder die Standard-Kubernetes-Ingress-Ressource mit Annotationen und ConfigMaps nutzen. Die erste Variante bietet ein breiteres Spektrum an Netzwerkfunktionen und eignet sich daher besser für produktionsreife Kubernetes-Umgebungen.

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 .