Migración del Ingress Controller de la comunidad a F5 NGINX Ingress Controller

Amir RawdatIngeniero de soluciones

Editor : Esta publicación es un extracto de nuestro completo libro electrónico Gestión del tráfico de Kubernetes con F5 NGINX: guía práctica. Descárguelo gratis hoy mismo.

Muchas organizaciones que configuran Kubernetes por primera vez comienzan con el controlador Ingress de NGINX desarrollado y mantenido por la comunidad de Kubernetes (kubernetes/ingress-nginx). Sin embargo, a medida que las implementaciones de Kubernetes maduran, algunas organizaciones descubren que necesitan funcionalidades avanzadas o desean contar con soporte comercial sin dejar de utilizar NGINX como plano de datos.

Una opción es migrar al controlador Ingress de NGINX desarrollado y mantenido por F5 NGINX (nginxinc/kubernetes-ingress), y aquí ofrecemos instrucciones completas para evitar algunas complicaciones derivadas de las diferencias entre ambos proyectos.

¿No tiene claro en qué se diferencian estas opciones? Lea «Guía para elegir un controlador de Ingress, parte 4: opciones de controladores de Ingress de NGINX» en nuestro blog.

Para distinguir entre los dos proyectos en el resto de este artículo, nos referiremos al controlador Ingress de NGINX mantenido por la comunidad de Kubernetes (kubernetes/ingress-nginx) como el «controlador Ingress de la comunidad» y al mantenido por F5 NGINX (nginxinc/kubernetes-ingress) como «NGINX Ingress Controller».

Hay dos formas de migrar del controlador Ingress de la comunidad a NGINX Ingress Controller:

• Opción 1: Migrar mediante recursos de NGINX Ingress
  Esta es la solución óptima, ya que los recursos de NGINX Ingress admiten el conjunto más amplio de funcionalidades de red de Ingress necesarias en entornos de Kubernetes de nivel de producción. Para obtener más información sobre los recursos de NGINX Ingress, vea nuestro seminario web Implementaciones avanzadas de Kubernetes con NGINX Ingress Controller.
• Opción 2: Migrar mediante el recurso Ingress de Kubernetes
  Esta opción se recomienda si desea utilizar el recurso estándar Ingress de Kubernetes para definir las reglas de equilibrio de carga de Ingress.

Opción 1: Migrar mediante recursos Ingress de NGINX

Con esta opción de migración, se utiliza el recurso Ingress estándar de Kubernetes para establecer las funcionalidades básicas y los recursos Ingress de NGINX para mejorar la configuración, ampliar sus funcionalidades y facilitar su uso.

Las definiciones de recursos personalizados (CRD) para los recursos de NGINX Ingress — VirtualServer, VirtualServerRoute, TransportServer, GlobalConfiguration y Policy— permiten delegar fácilmente el control de distintas partes de la configuración a diferentes equipos (como los equipos de AppDev y de seguridad), además de ofrecer una mayor seguridad y validación de la configuración.

Configuración de la terminación SSL y el enrutamiento basado en rutas HTTP

La tabla establece la correspondencia entre la configuración de la terminación SSL y el enrutamiento basado en rutas de capa 7 del campo spec del recurso Ingress estándar de Kubernetes y la del campo spec del recurso VirtualServer de NGINX. La sintaxis y la sangría difieren ligeramente entre ambos recursos, pero estos realizan las mismas funciones básicas de Ingress.

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

Configuración del balanceo de carga TCP/UDP y del paso directo de TLS

Con el controlador Ingress de la comunidad, un objeto de la API ConfigMap de Kubernetes es la única forma de exponer servicios TCP y UDP.

Con NGINX Ingress Controller, los recursos TransportServer ofrecen una amplia gama de opciones para el balanceo de carga TCP/UDP y TLS Passthrough. Los recursos TransportServer se utilizan junto con los recursos GlobalConfiguration para controlar las conexiones entrantes y salientes.

Para obtener más información, consulte Compatibilidad con servicios de paso directo de TCP, UDP y TLS en los recursos de NGINX Ingress en nuestro blog.

Convertir las anotaciones del controlador Ingress de la comunidad en recursos Ingress de NGINX

Las implementaciones de Kubernetes de nivel de producción suelen necesitar ampliar las reglas básicas de Ingress para abordar casos de uso avanzados, como despliegues canary y blue-green, limitación del tráfico, manipulación del tráfico de entrada y salida, entre otros.

El controlador Ingress de la comunidad implementa muchos de estos casos de uso mediante anotaciones de Kubernetes. Sin embargo, muchas de estas anotaciones se han creado con extensiones Lua personalizadas vinculadas a definiciones de recursos Ingress de NGINX muy específicas y, por tanto, no son adecuadas para implementar funcionalidades avanzadas en un entorno de producción estable y con soporte.

En las siguientes secciones, mostramos cómo convertir las anotaciones del controlador Ingress de la comunidad en recursos de NGINX Ingress Controller.

• Despliegues canary
• Control del tráfico
• Manipulación de encabezados
• Uso de proxy y balanceo de carga
• Autenticación mTLS
• Persistencia de sesión (exclusiva de NGINX Plus)

Despliegues canary

Aunque implemente con frecuencia cambios de código en sus cargas de trabajo de contenedores en producción, debe seguir prestando servicio a sus usuarios actuales. Los despliegues canary y blue-green le permiten hacerlo, y puede llevarlos a cabo en el plano de datos de NGINX Ingress Controller para lograr actualizaciones estables y predecibles en entornos de Kubernetes de nivel de producción.

La tabla muestra los campos de los recursos VirtualServer y VirtualServerRoute de NGINX que se corresponden con las anotaciones del controlador Ingress de la comunidad para las implementaciones canary.

El controlador Ingress de la comunidad evalúa las anotaciones de canary en el siguiente orden de prioridad:

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

Para que NGINX Ingress Controller los evalúe de la misma manera, deben aparecer en ese orden en el manifiesto VirtualServer o VirtualServerRoute de NGINX.

				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
				

Control del tráfico

En entornos de microservicios, donde las aplicaciones son efímeras por naturaleza y, por tanto, más propensas a devolver respuestas de error, los equipos de DevOps recurren ampliamente a políticas de control del tráfico —como los disyuntores y la limitación de la tasa y de las conexiones— para evitar situaciones de error cuando las aplicaciones presentan problemas o no funcionan según lo previsto.

La tabla muestra los campos de los recursos VirtualServer y VirtualServerRoute de NGINX que se corresponden con las anotaciones del controlador Ingress de la comunidad para la limitación de velocidad, los errores HTTP personalizados, un backend predeterminado personalizado y la reescritura de URI.

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"
				

Como se indica en la tabla, en el momento de redactar este documento, los recursos de NGINX Ingress no incluyen campos que permitan trasladar directamente las cuatro anotaciones siguientes del controlador Ingress de la comunidad, por lo que es necesario usar fragmentos de configuración. Está previsto que las próximas versiones de NGINX Ingress Controller admitan directamente estas cuatro anotaciones mediante recursos Policy.

• 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

Manipulación de cabeceras

La manipulación de las cabeceras HTTP resulta útil en muchos casos, ya que contienen información adicional importante y relevante para los sistemas que intervienen en una transacción HTTP. Por ejemplo, el controlador Ingress de la comunidad permite habilitar y configurar cabeceras de uso compartido de recursos entre orígenes (CORS), que se utilizan con aplicaciones AJAX cuando el código JavaScript del front-end ejecutado en un navegador se conecta a una aplicación de backend o a un servidor web.

La tabla muestra los campos de los recursos VirtualServer y VirtualServerRoute de NGINX que se corresponden con las anotaciones del controlador Ingress de la comunidad para la manipulación de encabezados.

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

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

Proxy inverso y balanceo de carga

Existen otras funcionalidades de proxy y balanceo de carga que puede interesarle configurar en NGINX Ingress Controller en función del caso de uso específico. Estas funcionalidades incluyen la configuración del algoritmo de balanceo de carga, así como de los tiempos de espera y del almacenamiento en búfer para las conexiones mediante proxy.

La tabla muestra las directivas del campo upstream de los recursos VirtualServer y VirtualServerRoute de NGINX que se corresponden con las anotaciones del controlador Ingress de la comunidad para el equilibrio de carga personalizado de NGINX, los tiempos de espera del proxy, el almacenamiento en búfer del proxy y el enrutamiento de conexiones a la dirección IP y al puerto de ClusterIP de un servicio.

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
				

Autenticación mTLS

Una malla de servicios resulta especialmente útil en un entorno estricto de confianza cero, donde las aplicaciones distribuidas dentro de un clúster se comunican de forma segura mediante autenticación mutua. ¿Y si necesitamos aplicar ese mismo nivel de seguridad al tráfico que entra y sale del clúster (tráfico norte-sur)?

Podemos configurar la autenticación mTLS en la capa del controlador de Ingress para que los sistemas finales de las conexiones externas se autentiquen mutuamente presentando un certificado válido.

La tabla muestra los campos de los recursos Policy de NGINX que se corresponden con las anotaciones del controlador Ingress de la comunidad para la autenticación mediante certificado de cliente y la autenticación mediante certificado del backend.

				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
				

Persistencia de sesión (exclusiva de NGINX Plus)

La tabla muestra los campos de los recursos Policy de NGINX que son exclusivos de NGINX Ingress Controller basado en NGINX Plus y que se corresponden con las anotaciones del controlador Ingress de la comunidad para la persistencia de sesión (afinidad).

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
				

Opción 2: Migrar mediante el recurso Ingress de Kubernetes

La segunda opción para migrar del controlador Ingress de la comunidad a NGINX Ingress Controller consiste en utilizar únicamente anotaciones y ConfigMaps en el recurso Ingress estándar de Kubernetes y, posiblemente, recurrir a un procesamiento de tipo «maestro/minion». De este modo, toda la configuración se mantiene en el objeto Ingress.

Nota: Con este método, no modifique el campo spec del recurso Ingress.

Configuración avanzada con anotaciones

La siguiente tabla muestra las anotaciones del controlador Ingress de la comunidad que se corresponden directamente con las anotaciones compatibles con NGINX Ingress Controller.

				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"
				

¹El controlador Ingress de la comunidad utiliza Lua para implementar algunos de sus algoritmos de equilibrio de carga. NGINX Ingress Controller no dispone de un equivalente para todos ellos.

²Redirige el tráfico HTTP a HTTPS. El controlador Ingress de la comunidad implementa esta función con código Lua, mientras que NGINX Ingress Controller utiliza condiciones if nativas de NGINX.

La siguiente tabla muestra las anotaciones del controlador Ingress de la comunidad que se corresponden directamente con las anotaciones compatibles con NGINX Ingress Controller basado en NGINX Plus.

				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"
				

Nota: NGINX Ingress Controller basado en NGINX Plus dispone de anotaciones adicionales para funciones que el controlador Ingress de la comunidad no admite en absoluto, entre ellas las comprobaciones de estado activas y la autenticación mediante tokens web JSON (JWT).

Configuración global con ConfigMaps

La siguiente tabla relaciona las claves de ConfigMap del controlador Ingress de la comunidad con sus correspondientes claves de ConfigMap de NGINX Ingress Controller. Tenga en cuenta que algunos nombres de claves de ConfigMap son idénticos. Además, tanto el controlador Ingress de la comunidad como NGINX Ingress Controller tienen claves de ConfigMap que el otro no tiene (no se muestran en la tabla).

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

Resumen

Puede migrar del controlador Ingress de la comunidad a NGINX Ingress Controller utilizando recursos personalizados de NGINX Ingress o el recurso Ingress estándar de Kubernetes con anotaciones y ConfigMaps. La primera opción admite un conjunto más amplio de funcionalidades de red, por lo que resulta más adecuada para entornos de Kubernetes de nivel empresarial.

Este artículo es un extracto de nuestro completo libro electrónico, «Gestión del tráfico de Kubernetes con F5 NGINX: guía práctica». «Descárgalo gratis hoy mismo».

Prueba por ti mismo NGINX Ingress Controller basado en NGINX Plus con una prueba gratuita de 30 días o ponte en contacto con nosotros para hablar sobre tus casos de uso.

Sobre el autor

Amir RawdatIngeniero de soluciones

Más artículos de Amir Rawdat