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.

apiVersion: networking.k8s.io/v1kind: Ingress
metadata:
  name: nginx-test
spec:
  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: VirtualServer
metadata:
  name: nginx-test
spec:
  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

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"

matches:- conditions:
  - header: httpHeader
      value: never
  action:
    pass: echo 
  - header: httpHeader
      value: always
  action:
    pass: echo-canary
action:
  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-canary
action:
  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

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"

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 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: "seconds"

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: "seconds"

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-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 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: "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 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:  enable: true

  name: cookieName

  expires: xh

  path: /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-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_buffers
proxy_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 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: "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"

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).

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 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 .