Migration vom Community Ingress Controller zu F5 NGINX Ingress Controller

Amir RawdatLösungsingenieur

Redaktion – Dieser Beitrag ist ein Auszug aus unserem umfassenden E-Book „Kubernetes-Datenverkehr mit F5 NGINX verwalten: Ein Praxisleitfaden“. Laden Sie es noch heute kostenlos herunter.

Viele Unternehmen, die Kubernetes zum ersten Mal einrichten, beginnen mit dem von der Kubernetes-Community entwickelten und gepflegten NGINX Ingress Controller (kubernetes/ingress-nginx). Mit zunehmender Reife ihrer Kubernetes-Bereitstellungen stellen einige Unternehmen jedoch fest, dass sie erweiterte Funktionen oder kommerziellen Support benötigen, NGINX aber weiterhin als Datenebene nutzen möchten.

Eine Möglichkeit besteht darin, zum von F5 NGINX entwickelten und gepflegten NGINX Ingress Controller (nginxinc/kubernetes-ingress) zu migrieren. Hier finden Sie eine vollständige Anleitung, mit der Sie 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: Optionen für NGINX Ingress Controller in unserem Blog.

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

Für die Migration vom Community-Ingress-Controller zum NGINX Ingress Controller gibt es zwei Möglichkeiten:

• Option 1: Migration mithilfe von NGINX Ingress-Ressourcen
  Dies ist die optimale Lösung, da NGINX Ingress-Ressourcen die umfassenderen Ingress-Netzwerkfunktionen unterstützen, die für produktionsreife Kubernetes-Umgebungen erforderlich sind. Weitere Informationen zu NGINX Ingress-Ressourcen erhalten Sie in unserem Webinar „Fortgeschrittene Kubernetes-Bereitstellungen mit dem NGINX Ingress Controller“.
• Option 2: Migration mithilfe der Kubernetes-Ingress-Ressource
  Diese Option wird empfohlen, wenn Sie die standardmäßige Kubernetes-Ingress-Ressource zur Definition von Ingress-Lastverteilungsregeln verwenden möchten.

Option 1: Migration mithilfe von NGINX-Ingress-Ressourcen

Bei dieser Migrationsoption verwenden Sie die standardmäßige Kubernetes-Ingress-Ressource, um grundlegende Funktionen festzulegen, und NGINX-Ingress-Ressourcen, um Ihre Konfiguration um zusätzliche Funktionen zu erweitern und die Bedienung zu vereinfachen.

Die benutzerdefinierten Ressourcendefinitionen (Custom Resource Definitions, CRDs) für NGINX-Ingress-Ressourcen – VirtualServer, VirtualServerRoute, TransportServer, GlobalConfiguration, und Policy – ermöglichen es Ihnen, die Kontrolle über verschiedene Teile der Konfiguration einfach an unterschiedliche Teams (z. B. AppDev- und Sicherheitsteams) zu delegieren, und bieten zugleich mehr Konfigurationssicherheit und eine zuverlässigere Validierung.

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

Die Tabelle stellt die Konfiguration der SSL-Terminierung und des pfadbasierten Routings auf Layer 7 im Feld spec der standardmäßigen Kubernetes-Ingress-Ressource der Konfiguration im Feld spec der NGINX-Ressource VirtualServer gegenüber. Syntax und Einrückung unterscheiden sich in den beiden Ressourcen geringfügig, sie erfüllen jedoch dieselben grundlegenden Ingress-Funktionen.

apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: nginx-testspec:  tls:    - hosts:      - foo.bar.com      secretName: tls-secret  rules:    - host: foo.bar.com      http:        paths:        - path: /login          backend:             serviceName: login-svc            servicePort: 80        - path: /billing            serviceName: billing-svc            servicePort: 80

apiVersion: networking.k8s.io/v1kind: VirtualServermetadata:  name: nginx-testspec:  host: foo.bar.com   tls:    secret: tls-secret  upstreams:    - name: login      service: login-svc      port: 80    - name: billing       service: billing-svc      port: 80  routes:   - path: /login    action:      pass: login   - path: /billing     action:       pass: billing

TCP/UDP-Lastverteilung und TLS-Passthrough konfigurieren

Beim Community-Ingress-Controller ist ein Kubernetes-ConfigMap-API-Objekt die einzige Möglichkeit, TCP- und UDP-Dienste bereitzustellen.

Mit dem NGINX Ingress Controller definieren TransportServer-Ressourcen eine Vielzahl von Optionen für den TCP/UDP-Lastenausgleich und den Lastenausgleich mit TLS-Passthrough. TransportServer-Ressourcen werden zusammen mit GlobalConfiguration-Ressourcen verwendet, um eingehende und ausgehende Verbindungen zu steuern.

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

Annotationen des Community Ingress Controllers in NGINX Ingress Resources konvertieren

Kubernetes-Bereitstellungen für den Produktionseinsatz müssen grundlegende Ingress-Regeln häufig erweitern, um fortgeschrittene Anwendungsfälle wie Canary- und Blue-Green-Bereitstellungen, Traffic-Drosselung, die Manipulation des Ingress- und Egress-Traffics und vieles mehr umzusetzen.

Der Community-Ingress-Controller implementiert viele dieser Anwendungsfälle mithilfe von Kubernetes-Annotationen. Viele dieser Annotationen basieren jedoch auf benutzerdefinierten Lua-Erweiterungen, die auf sehr spezifische Definitionen von NGINX-Ingress-Ressourcen zugeschnitten sind. Daher eignen sie sich nicht für die Implementierung erweiterter Funktionen in einer stabilen und unterstützten Produktionsumgebung.

In den folgenden Abschnitten zeigen wir, wie Sie Annotationen des Community Ingress Controllers in Ressourcen des NGINX Ingress Controllers konvertieren.

• Canary-Bereitstellungen
• Datenverkehrssteuerung
• Header-Manipulation
• Proxying und Lastverteilung
• mTLS-Authentifizierung
• Sitzungspersistenz (exklusiv für NGINX Plus)

Canary-Bereitstellungen

Auch wenn Sie häufig Codeänderungen an Ihren produktiven Container-Workloads bereitstellen, müssen Sie Ihre bestehenden Benutzer weiterhin bedienen. Canary- und Blue-Green-Deployments ermöglichen Ihnen dies. Sie können sie auf der Datenebene des NGINX Ingress Controllers durchführen, um stabile und vorhersehbare Aktualisierungen in Kubernetes-Produktivumgebungen zu gewährleisten.

Die Tabelle zeigt die Felder in den NGINX-Ressourcen „VirtualServer und VirtualServerRoute“, die den Annotationen des Community-Ingress-Controllers für Canary-Bereitstellungen entsprechen.

Der Community-Ingress-Controller wertet Canary-Annotationen in der folgenden Prioritätsreihenfolge 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 dieselbe Weise auswertet, müssen sie im NGINX-VirtualServer- oder VirtualServerRoute-Manifest in dieser Reihenfolge aufgeführt sein.

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

				matches:- conditions:  - header: httpHeader      value: never  action:    pass: echo   - header: httpHeader      value: always  action:    pass: echo-canaryaction:  pass: echo
				

				nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "httpHeader"nginx.ingress.kubernetes.io/canary-by-header-value: "my-value"
				

				matches:- conditions:  - header: httpHeader      value: my-value  action:    pass: echo-canary action:  pass: echo
				

nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-cookie: "cookieName"
				

				matches:- conditions:  - cookie: cookieName      value: never  action:    pass: echo   - cookie: cookieName      value: always  action:    pass: echo-canaryaction:  pass: echo
				

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

splits:- weight: 90   action:    pass: echo- weight: 10    action:     pass: echo-canary
				

Datenverkehrssteuerung

In Microservices-Umgebungen, in denen Anwendungen naturgemäß kurzlebig sind und daher häufiger Fehlermeldungen zurückgeben, setzen DevOps-Teams umfassend Richtlinien zur Datenverkehrssteuerung ein – etwa Circuit Breaking sowie die Begrenzung von Anfrageraten und Verbindungen –, um Fehlerzustände zu verhindern, wenn Anwendungen beeinträchtigt sind oder nicht wie erwartet funktionieren.

Die Tabelle zeigt die Felder in NGINX-VirtualServer- und VirtualServerRoute-Ressourcen, die den Annotationen des Community-Ingress-Controllers für Ratenbegrenzung, benutzerdefinierte HTTP-Fehler, ein benutzerdefiniertes Standard-Backend und URI-Umschreibung entsprechen.

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

				errorPages:- codes: [code]    redirect:      code: 301      url: default-svc
				

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

				http-snippets: |    limit_conn_zone $binary_remote_addr zone=zone_name:size;routes:- path: /path    location-snippets: |      limit_conn zone_name number;
				

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

location-snippets: |    limit_rate number;    limit_rate_after number;
				

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

				rateLimit:    rate: numberr/m    burst: number * multiplier    key: ${binary_remote_addr}    zoneSize: size
				

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

rateLimit:    rate: numberr/s    burst: number * multiplier    key: ${binary_remote_addr}    zoneSize: size
				

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

				http-snippets: |server-snippets: |
				

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

rewritePath: "URI"
				

Wie in der Tabelle angegeben, enthalten NGINX-Ingress-Ressourcen zum Zeitpunkt der Erstellung dieses Dokuments keine Felder, mit denen sich die folgenden vier Annotationen des Community-Ingress-Controllers direkt übertragen lassen. Daher müssen Sie Snippets verwenden. Eine direkte Unterstützung der vier Annotationen mithilfe von Policy-Ressourcen ist für zukü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

Die Bearbeitung 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. Der Community-Ingress-Controller unterstützt beispielsweise das Aktivieren und Festlegen von Cross-Origin Resource Sharing-Headern (CORS), die bei AJAX-Anwendungen verwendet werden, bei denen sich Frontend-JavaScript-Code aus einem Browser mit einer Backend-Anwendung oder einem Webserver verbindet.

Die Tabelle zeigt die Felder in den NGINX-Ressourcen „VirtualServer und VirtualServerRoute“, die den Annotationen des Community-Ingress-Controllers für die 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:  add:     - name: Access-Control-Allow-Credentials      value: "true"     - name: Access-Control-Allow-Headers      value: "X-Forwarded-For"    - name: Access-Control-Allow-Methods      value: "PUT, GET, POST, OPTIONS"    - name: Access-Control-Allow-Origin      value: "*"    - name: Access-Control-Max-Age      value: "Sekunden"
				

Proxying und Lastverteilung

Je nach konkretem Anwendungsfall können Sie im NGINX Ingress Controller weitere Proxy- und Lastverteilungsfunktionen konfigurieren. Dazu gehören die Festlegung des Lastverteilungsalgorithmus sowie Einstellungen für Zeitüberschreitungen und die Pufferung von Proxy-Verbindungen.

Die Tabelle zeigt die Anweisungen im Feld „upstream“ der NGINX-Ressourcen VirtualServer und VirtualServerRoute, die den Annotationen des Community-Ingress-Controllers für benutzerdefinierten NGINX-Lastenausgleich, Proxy-Zeitüberschreitungen, Proxy-Pufferung und das Weiterleiten von Verbindungen an die Cluster-IP-Adresse und den Port eines Dienstes entsprechen.

nginx.ingress.kubernetes.io/load-balance
				

				lb-method
				

				nginx.ingress.kubernetes.io/proxy-buffering
				

buffering
				

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

				buffers
				

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

				connect-timeout
				

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

				next-upstream
				

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

				next-upstream-timeout
				

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

read-timeout
				

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

				send-timeout
				

				nginx.ingress.kubernetes.io/service-upstream
				

				use-cluster-ip
				

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 miteinander kommunizieren. Was aber, wenn wir dasselbe Sicherheitsniveau auch für den Datenverkehr durchsetzen müssen, der in den Cluster hinein- und aus ihm herausfließt (Nord-Süd-Datenverkehr)?

Wir können die mTLS-Authentifizierung auf der Ebene des Ingress Controllers konfigurieren, sodass sich die Endsysteme externer Verbindungen gegenseitig authentifizieren, indem sie ein gültiges Zertifikat vorlegen.

Die Tabelle zeigt die Felder in NGINX-Policy-Ressourcen, die den Annotationen des Community-Ingress-Controllers für die Clientzertifikatauthentifizierung und die Backend-Zertifikatauthentifizierung entsprechen.

				nginx.ingress.kubernetes.io/auth-tls-secret: secretNamenginx.ingress.kubernetes.io/auth-tls-verify-client: "on"nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
				

				ingressMTLS:   clientCertSecret: secretName   verifyClient: "on"   verifyDepth: 1
				

nginx.ingress.kubernetes.io/proxy-ssl-secret: "secretName"nginx.ingress.kubernetes.io/proxy-ssl-verify: "on|off"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: "DEFAULT"nginx.ingress.kubernetes.io/proxy-ssl-name: "server-name"nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on|off"
				

egressMTLS:   tlsSecret: secretName   verifyServer: true|false   verifyDepth: 1   protocols: TLSv1.2   ciphers: DEFAULT   sslName: server-name   serverName: true|false
				

Sitzungspersistenz (exklusiv für NGINX Plus)

Die Tabelle zeigt die Felder in NGINX-Policy-Ressourcen, die ausschließlich im auf NGINX Plus basierenden NGINX Ingress Controller verfügbar sind und den Annotationen des Community-Ingress-Controllers für 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:  enable: true  name: cookieName  expires: xh  path: /route  secure: true
				

Option 2: Migration mithilfe der Kubernetes-Ingress-Ressource

Die zweite Möglichkeit für die Migration vom Community-Ingress-Controller zum NGINX Ingress Controller besteht darin, ausschließlich Annotationen und ConfigMaps in der standardmäßigen Kubernetes-Ingress-Ressource zu verwenden und gegebenenfalls auf eine Verarbeitung nach dem „Master/Minion“-Prinzip zu setzen. Dadurch verbleibt die gesamte Konfiguration im Ingress-Objekt.

Hinweis: Ändern Sie bei dieser Methode nicht das Feld „spec“ der Ingress-Ressource.

Erweiterte Konfiguration mit Annotationen

Die folgende Tabelle enthält eine Übersicht über die Annotationen des Community-Ingress-Controllers, 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-method
				

				random two least_conn
				

				nginx.ingress.kubernetes.io/proxy-buffering: "on|off"
				

				nginx.org/proxy-buffering: "True|False"
				

				proxy_buffering
				

				nginx.ingress.kubernetes.io/proxy-buffers-number: "number"nginx.ingress.kubernetes.io/proxy-buffer-size: "xk"
				

				nginx.org/proxy-buffers: "number 4k|8k"nginx.org/proxy-buffer-size: "4k|8k"
				

proxy_buffersproxy_buffer_size
				

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

nginx.org/proxy-connect-timeout: : "secondss"
				

				proxy_connect_timeout
				

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

				nginx.org/proxy-read-timeout: "secondss"
				

proxy_read_timeout
				

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

				nginx.org/proxy-send-timeout: "secondss"
				

				proxy_send_timeout
				

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

nginx.org/rewrites: "serviceName=svc rewrite=URI"
				

				rewrite
				

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

nginx.org/server-snippets: |
				

				nginx.ingress.kubernetes.io/ssl-redirect: "true|false"
				

				ingress.kubernetes.io/ssl-redirect: "True|False"
				

¹Der Community Ingress Controller verwendet Lua, um einige seiner Lastverteilungsalgorithmen zu implementieren. Der NGINX Ingress Controller bietet nicht für alle davon eine Entsprechung.

²Leitet HTTP-Datenverkehr an HTTPS weiter. Der Community-Ingress-Controller implementiert dies mit Lua-Code, während der NGINX Ingress Controller native NGINX-if-Bedingungen verwendet.

Die folgende Tabelle enthält eine Übersicht über die Annotationen des Community-Ingress-Controllers, die direkt den vom NGINX Ingress Controller auf Basis von NGINX Plus unterstützten Annotationen entsprechen.

				nginx.ingress.kubernetes.io/affinity: "cookie"nginx.ingress.kubernetes.io/session-cookie-name: "cookie_name"nginx.ingress.kubernetes.io/session-cookie-expires: "seconds"nginx.ingress.kubernetes.io/session-cookie-path: "/route"
				

				nginx.com/sticky-cookie-services: "serviceName=example-svc cookie_name expires=time path=/route"
				

Hinweis: Der auf NGINX Plus basierende NGINX Ingress Controller bietet zusätzliche Annotationen für Funktionen, die vom Community Ingress Controller überhaupt nicht unterstützt werden, darunter aktive Zustandsprüfungen und die Authentifizierung mit JSON Web Tokens (JWTs).

Globale Konfiguration mit ConfigMaps

Die folgende Tabelle ordnet die ConfigMap-Schlüssel des Community-Ingress-Controllers den jeweils 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 ConfigMap-Schlüssel, die beim jeweils anderen nicht vorhanden sind (in der Tabelle nicht aufgeführt).

disable-access-log

access-log-off

error-log-level

error-log-level

hsts

hsts

hsts-include-subdomains

hsts-include-subdomains

hsts-max-age

hsts-max-age

http-snippet

http-snippets

keep-alive

keepalive-timeout

keep-alive-requests

keepalive-requests

load-balance

lb-method

location-snippet

location-snippets

log-format-escape-json: "true"

log-format-escaping: "json"

log-format-stream

stream-log-format

log-format-upstream

log-format

main-snippet

main-snippets

max-worker-connections 

worker-connections

max-worker-open-files

worker-rlimit-nofile

proxy-body-size

client-max-body-size

proxy-buffering

proxy-buffering

proxy-buffers-number: "number"proxy-buffer-size: "size"

proxy-buffers: number size

proxy-connect-timeout

proxy-connect-timeout

proxy-read-timeout

proxy-read-timeout

proxy-send-timeout

proxy-send-timeout

server-name-hash-bucket-size

server-names-hash-bucket-size

server-name-hash-max-size

server-names-hash-max-size

server-snippet

server-snippets

server-tokens

server-tokens

ssl-ciphers

ssl-ciphers

ssl-dh-param

ssl-dhparam-file

ssl-protocols

ssl-protocols

ssl-redirect

ssl-redirect

upstream-keepalive-connections

keepalive

use-http2

http2

use-proxy-protocol

proxy-protocol

variables-hash-bucket-size

variables-hash-bucket-size

worker-cpu-affinity

worker-cpu-affinity

worker-processes

worker-processes

worker-shutdown-timeout

worker-shutdown-timeout

Zusammenfassung

Sie können vom Community-Ingress-Controller zum NGINX Ingress Controller migrieren und dabei entweder benutzerdefinierte NGINX-Ingress-Ressourcen oder die standardmäßige Kubernetes-Ingress-Ressource mit Annotationen und ConfigMaps verwenden. Die erste Option unterstützt ein breiteres Spektrum an Netzwerkfunktionen und eignet sich daher besser für Kubernetes-Umgebungen mit Produktionsanforderungen.

Dieser Beitrag ist ein Auszug aus unserem umfassenden E-Book „Kubernetes-Datenverkehr mit F5 NGINX verwalten: Ein Praxisleitfaden“. Laden Sie es noch heute kostenlos herunter.

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

Über den Autor

Amir RawdatLösungsingenieur

Weitere Blogbeiträge von Amir Rawdat