BLOG | NGINX

Migración del controlador de ingreso de la comunidad al controlador de ingreso de F5 NGINX

NGINX - Parte de F5 - horizontal, negro, tipo RGB
Miniatura de Amir Rawdat
Amir Rawdat
Publicado el 19 de mayo de 2022

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

Muchas organizaciones que configuran Kubernetes por primera vez comienzan con el controlador de ingreso 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 funciones avanzadas o desean soporte comercial mientras mantienen NGINX como el plano de datos.

Una opción es migrar al controlador de ingreso NGINX desarrollado y mantenido por F5 NGINX ( nginxinc/kubernetes-ingress ), y aquí brindamos instrucciones completas para que pueda evitar algunas complicaciones que resultan de las diferencias entre los dos proyectos.

¿No está seguro de en qué se diferencian estas opciones? Lea la Guía para elegir un controlador de ingreso, parte 4: Opciones del controlador de ingreso NGINX en nuestro blog.

Para distinguir entre los dos proyectos en el resto de esta publicación, nos referimos al controlador de ingreso NGINX mantenido por la comunidad de Kubernetes ( kubernetes/ingress-nginx ) como el “controlador de ingreso de la comunidad” y al mantenido por F5 NGINX ( nginxinc/kubernetes-ingress ) como “controlador de ingreso NGINX”.

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

Opción 1: Migrar usando recursos de ingreso de NGINX

Con esta opción de migración, utiliza el recurso Ingress de Kubernetes estándar para configurar las capacidades raíz y los recursos Ingress de NGINX para mejorar su configuración con mayores capacidades y facilidad de uso.

Las definiciones de recursos personalizadas (CRD) para los recursos de NGINX Ingress ( VirtualServer, VirtualServerRoute , TransportServer , GlobalConfiguration y Policy ) le permiten delegar fácilmente el control sobre varias partes de la configuración a diferentes equipos (como los equipos de desarrollo de aplicaciones y seguridad), además de proporcionar 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 asigna la configuración de la terminación SSL y el enrutamiento basado en rutas de capa 7 en el campo de especificación del recurso Ingress de Kubernetes estándar con el campo de especificación en el recurso NGINX VirtualServer . La sintaxis y la sangría difieren ligeramente en los dos recursos, pero logran las mismas funciones básicas de Ingress.

Recurso de ingreso de Kubernetes Recurso de servidor virtual NGINX 
Versión de API: networking.k8s.io/v1kind: Entrada
Metadatos:
Nombre: nginx-test
Especificación:
TLS:
- Hosts:
- Foo.bar.com
NombreSecreto: TLS-Secret
Reglas:
- Host: Foo.bar.com
http:
Rutas:
- Ruta: /login
Backend:
NombreServicio: login-svc
PuertoServicio: 80
- ruta: /facturación
nombre_del_servicio: servicio_facturación
Puerto_del_servicio: 80

Versión de API: networking.k8s.io/v1kind: Servidor virtual
Metadatos:
Nombre: nginx-test
Especificación:
Host: foo.bar.com
TLS:
Secreto: tls-secret
Upstreams:
Nombre: login
Servicio: login-svc
Puerto: 80
- Nombre: Facturación
Servicio: Billing-SVC
Puerto: 80
Rutas:
- Ruta: /login
Acción:
Contraseña: login
- Ruta: /facturación
Acción:
Contraseña: facturación

Configuración del equilibrio de carga TCP/UDP y el paso a través de TLS

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

Con NGINX Ingress Controller, los recursos de TransportServer definen una amplia gama de opciones para el equilibrio de carga de paso a través de TCP/UDP y TLS. Los recursos de TransportServer se utilizan junto con los recursos de GlobalConfiguration para controlar las conexiones entrantes y salientes.

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

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

Las implementaciones de Kubernetes de nivel de producción a menudo necesitan ampliar las reglas de ingreso básicas para implementar casos de uso avanzados, incluidas implementaciones canarias y azul-verde, limitación de tráfico, manipulación del tráfico de ingreso y egreso, y más.

El controlador de Ingress de la comunidad implementa muchos de estos casos de uso con anotaciones de Kubernetes. Sin embargo, muchas de estas anotaciones se crean con extensiones Lua personalizadas que pertenecen a definiciones de recursos de NGINX Ingress muy específicas y, como resultado, no son adecuadas para implementar funcionalidades avanzadas en un entorno de producción estable y compatible.

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

Despliegues de Canary

Incluso mientras envía cambios de código frecuentes a sus cargas de trabajo de contenedores de producción, debe continuar brindando servicio a sus usuarios existentes. Las implementaciones Canary y Blue-Green le permiten hacer esto y puede realizarlas en el plano de datos del controlador de ingreso NGINX para lograr actualizaciones estables y predecibles en entornos de Kubernetes de nivel de producción.

La tabla muestra los campos en los recursos NGINX VirtualServer y VirtualServerRoute que corresponden a las anotaciones del controlador de ingreso de la comunidad para implementaciones canarias .

El controlador de Ingress de la comunidad evalúa las anotaciones canarias en este orden de precedencia:

  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 NGINX VirtualServer o VirtualServerRoute.

Controlador de ingreso a la comunidad NGINX Ingress Controller 
nginx.ingress.kubernetes.io/canary: "verdadero" nginx.ingress.kubernetes.io/canary-by-header: "Encabezado http"

coincidencias :- condiciones: - encabezado: httpHeader valor: nunca acción: pasar: eco - encabezado: httpHeader valor: siempre acción: pasar: eco-canary acción: pasar: eco

nginx.ingress.kubernetes.io/canary: "verdadero" nginx.ingress.kubernetes.io/canary-by-header: "Encabezado http" nginx.ingress.kubernetes.io/canary-by-header-value: " mi-valor "

coincidencias:- condiciones: - encabezado: httpHeader valor: my-value acción: pass: echo-canary acción: pass: echo

nginx.ingress.kubernetes.io/canary: "verdadero" nginx.ingress.kubernetes.io/canary-by-cookie: "nombreDeCookie"

Coincidencias: - Condiciones:
- Cookie: NombreDeCookie
Valor: Nunca
Acción:
Pasar: Echo
- Cookie: NombreDeCookie
Valor: Siempre
Acción:
Pasar: Echo-Canary
Acción:
Pasar: Echo

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

divisiones :- peso: 90 acción: pasar: eco - peso: 10 acción: pasar: eco-canario

Control de tráfico

En entornos de microservicios, donde las aplicações son efímeras por naturaleza y, por lo tanto, tienen más probabilidades de devolver respuestas de error, los equipos de DevOps hacen un uso extensivo de políticas de control de tráfico (como interrupción de circuitos y limitación de velocidad y conexión) para evitar condiciones de error cuando las aplicações no funcionan correctamente o no funcionan como se espera.

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

Controlador de ingreso a la comunidad NGINX Ingress Controller 
nginx.ingress.kubernetes.io/custom-http-errors: " código " nginx.ingress.kubernetes.io/default-backend: "default-svc"

errorPages :- códigos: [ código ] redirección: código: URL 301: servicio predeterminado

nginx.ingress.kubernetes.io/limit-connections: " número "

http-snippets : | limit_conn_zone $binary_remote_addr zone= nombre_zona : tamaño ; rutas: - ruta: / ruta location-snippets : | limit_conn nombre_zona número ;

nginx.ingress.kubernetes.io/limit-rate: " número " nginx.ingress.kubernetes.io/limit-rate-after: " número "

fragmentos de ubicación: | limit_rate número ; limit_rate_after número ;

nginx.ingress.kubernetes.io/limit-rpm: " número " nginx.ingress.kubernetes.io/limit-burst-multiplier: " multiplicador "

rateLimit : tasa: número r/m ráfaga: número * multiplicador clave: ${binary_remote_addr} zoneSize: tamaño

nginx.ingress.kubernetes.io/limit-rps: " número " nginx.ingress.kubernetes.io/limit-burst-multiplier: " multiplicador "

rateLimit: tasa: número r/s ráfaga: número * multiplicador clave: ${binary_remote_addr} zoneSize: tamaño

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

fragmentos de http: | fragmentos de servidor : |

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

rewritePath : " URI "

Como se indica en la tabla, al momento de escribir este artículo los recursos de Ingress de NGINX no incluyen campos que traduzcan directamente las siguientes cuatro anotaciones del controlador de Ingress de la comunidad, y debe usar fragmentos. Se planea brindar soporte directo para las cuatro anotaciones, mediante recursos de políticas , para futuras versiones de NGINX Ingress Controller.

  • 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 encabezados

La manipulación de los encabezados HTTP es útil en muchos casos de uso, ya que contienen información adicional que es importante y relevante para los sistemas involucrados en una transacción HTTP. Por ejemplo, el controlador de Ingress de la comunidad permite habilitar y configurar encabezados de uso compartido de recursos de origen cruzado (CORS), que se usan con aplicações AJAX, donde el código JavaScript de front-end de un navegador se conecta a una aplicación de back-end o un servidor web.

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

Controlador de ingreso a la comunidad NGINX Ingress Controller 
nginx.ingress.kubernetes.io/enable-cors: "verdadero" nginx.ingress.kubernetes.io/cors-allow-credentials: "verdadero" nginx.ingress.kubernetes.io/cors-allow-headers: "X-Reenviado-Para" nginx.ingress.kubernetes.io/cors-allow-methods: "PONER, OBTENER, PUBLICAR, OPCIONES" nginx.ingress.kubernetes.io/cors-allow-origin: "*" nginx.ingress.kubernetes.io/cors-max-age: " segundos "

responseHeaders : agregar: - nombre: Valor de Access-Control-Allow-Credentials: "true" - nombre: Valor de Access-Control-Allow-Headers: "X-Reenviado-Para" - nombre: Valor de métodos permitidos de control de acceso: "PUT, GET, POST, OPCIONES" - nombre: Valor de Access-Control-Allow-Origin: "*" - nombre: Valor de Access-Control-Max-Age: " segundos "

Proxy y equilibrio de carga

Hay otras funcionalidades de proxy y equilibrio de carga que quizás desee configurar en NGINX Ingress Controller dependiendo del caso de uso específico. Estas funcionalidades incluyen la configuración del algoritmo de equilibrio de carga, así como la configuración de tiempo de espera y almacenamiento en búfer para conexiones mediante proxy.

La tabla muestra las declaraciones en el campo ascendente de los recursos NGINX VirtualServer y VirtualServerRoute que corresponden a las anotaciones del controlador de ingreso de la comunidad para el equilibrio de carga NGINX personalizado , los tiempos de espera del proxy , el almacenamiento en búfer del proxy y las conexiones de enrutamiento a la dirección IP y el puerto del clúster de un servicio .

Controlador de ingreso a la comunidad NGINX Ingress Controller 
nginx.ingress.kubernetes.io/load-balance

método lb

nginx.ingress.kubernetes.io/proxy-buffering

almacenamiento en búfer

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

amortiguadores

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

tiempo de espera de conexión

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

siguiente aguas arriba

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

próximo tiempo de espera ascendente

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

tiempo de espera de lectura

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

tiempo de espera de envío

nginx.ingress.kubernetes.io/service-upstream

usar-ip-del-cluster

Autenticación mTLS

Una malla de servicios es particularmente útil en un entorno estricto de confianza cero, donde las aplicações distribuidas dentro de un clúster se comunican de forma segura mediante la autenticación mutua. ¿Qué pasa si necesitamos imponer el 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 ingreso para que los sistemas finales de las conexiones externas se autentiquen entre sí presentando un certificado válido.

La tabla muestra los campos en los recursos de políticas de NGINX que corresponden a las anotaciones del controlador de ingreso de la comunidad para la autenticación de certificados de cliente y la autenticación de certificados de back-end .

Controlador de ingreso a la comunidad NGINX Ingress Controller 

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

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

nginx.ingress.kubernetes.io/proxy-ssl-secret: "nombresecreto"
nginx.ingress.kubernetes.io/proxy-ssl-verify: "activado|desactivado"
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: "PREDETERMINADO"
nginx.ingress.kubernetes.io/proxy-ssl-name: "nombre-del-servidor"
nginx.ingress.kubernetes.io/proxy-ssl-server-name: "activado|desactivado"

egressMTLS : tlsSecret: secretName verifyServer: verdadero|falso verifyDepth: 1 protocolos: Cifrados TLSv1.2: DEFAULT sslName: nombre-del-servidor serverName: verdadero|falso

Persistencia de sesión (exclusiva de NGINX Plus)

La tabla muestra los campos en los recursos de políticas de NGINX que son exclusivos del controlador de ingreso de NGINX basado en NGINX Plus y corresponden a las anotaciones del controlador de ingreso de la comunidad para la persistencia de la sesión (afinidad).

Controlador de ingreso a la comunidad NGINX Ingress Controller 
nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/session-cookie-name: "nombreDeCookie" nginx.ingress.kubernetes.io/session-cookie-expires: " x " nginx.ingress.kubernetes.io/session-cookie-path: "/ruta" nginx.ingress.kubernetes.io/session-cookie-secure: "verdadero"

sessionCookie : habilitar: verdadero nombre: cookieName caduca: x h ruta: /ruta segura: verdadero

Opción 2: Migrar usando el recurso de ingreso de Kubernetes

La segunda opción para migrar del controlador de Ingress de la comunidad al controlador de Ingress de NGINX es usar solo anotaciones y ConfigMaps en el recurso de Ingress estándar de Kubernetes y potencialmente confiar en el procesamiento de estilo “ maestro/súbdito ”. Esto mantiene toda la configuración en el objeto Ingress.

Nota:  Con este método, no altere el campo de especificación del recurso Ingress.

Configuración avanzada con anotaciones

La siguiente tabla describe las anotaciones del controlador de Ingress de la comunidad que corresponden directamente a las anotaciones compatibles con el controlador de Ingress NGINX.

Controlador de ingreso a la comunidad NGINX Ingress Controller Directiva NGINX 
nginx.ingress.kubernetes.io/configuration-snippet : |

nginx.org/location-snippets : |
N/A 
nginx.ingress.kubernetes.io/load-balance1

nginx.org/metodo-lb
Por defecto:

 

dos al azar con menor conexión

nginx.ingress.kubernetes.io/proxy-buffering : "activado|desactivado"

nginx.org/proxy-buffering : "Verdadero|Falso"

almacenamiento en búfer proxy

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

nginx.org/proxy-buffers : " número 4k|8k" nginx.org/proxy-buffer-size : "4k|8k"

búferes proxy tamaño del búfer proxy

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

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

tiempo de espera de conexión de proxy

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

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

tiempo de espera de lectura de proxy

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

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

tiempo de espera de envío de proxy

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

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

volver a escribir

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

nginx.org/server-snippets : |
N/A 
nginx.ingress.kubernetes.io/ssl-redirect : "verdadero|falso"

ingress.kubernetes.io/ssl-redirect : "Verdadero|Falso"
N/A2

1El controlador de Ingress de la comunidad utiliza Lua para implementar algunos de sus algoritmos de equilibrio de carga. El controlador de ingreso NGINX no tiene un equivalente para todos ellos.

2Redirige el tráfico HTTP a HTTPS. El controlador de Ingress de la comunidad implementa esto con código Lua, mientras que el controlador de Ingress NGINX usa condiciones if nativas de NGINX.

La siguiente tabla describe las anotaciones del controlador de Ingress de la comunidad que corresponden directamente a las anotaciones compatibles con el controlador de Ingress NGINX basado en NGINX Plus.

Controlador de ingreso a la comunidad Controlador de ingreso NGINX basado en NGINX Plus 
nginx.ingress.kubernetes.io/affinity : "cookie" nginx.ingress.kubernetes.io/session-cookie-name : " nombre_de_cookie " nginx.ingress.kubernetes.io/session-cookie-expires : " segundos " nginx.ingress.kubernetes.io/session-cookie-path : "/ ruta "

nginx.com/sticky-cookie-services : "serviceName= ejemplo-svc nombre_de_cookie caduca= tiempo ruta=/ ruta "

Nota: El controlador de ingreso NGINX basado en NGINX Plus tiene anotaciones adicionales para funciones que el controlador de ingreso de la comunidad no admite en absoluto, incluidos los controles de estado activos y la autenticación mediante tokens web JSON (JWT).

Configuración global con ConfigMaps

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

Controlador de ingreso a la comunidad NGINX Ingress Controller 
deshabilitar el registro de acceso

acceso-cierre de sesión

nivel de registro de errores

nivel de registro de errores

hsts

hsts

subdominios incluidos en hsts

subdominios incluidos en hsts

edad máxima de hsts

edad máxima de hsts

fragmento http

fragmentos de http

mantener viva

tiempo de espera de mantenimiento de conexión

solicitudes de mantenimiento de conexión

solicitudes de mantenimiento de conexión

equilibrio de carga

método lb

fragmento de ubicación

fragmentos de ubicación

log-format-escape-json : "verdadero"

Escape de formato de registro : "json"

flujo de formato de registro

formato de registro de transmisión

formato de registro ascendente

formato de registro

fragmento principal

fragmentos principales

conexiones máximas de trabajadores 

conexiones entre trabajadores

max-worker-archivos-abiertos

trabajador-rlimit-nofile

tamaño del cuerpo del proxy

tamaño corporal máximo del cliente

almacenamiento en búfer de proxy

almacenamiento en búfer de proxy

proxy-buffers-number : " número " proxy-buffer-size : " tamaño "

proxy-buffers : tamaño del número

tiempo de espera de conexión de proxy

tiempo de espera de conexión de proxy

tiempo de espera de lectura del proxy

tiempo de espera de lectura del proxy

tiempo de espera de envío de proxy

tiempo de espera de envío de proxy

tamaño del depósito de hash del nombre del servidor

tamaño del depósito de hash de nombres de servidor

tamaño máximo del hash del nombre del servidor

tamaño máximo del hash de nombres de servidor

fragmento de servidor

fragmentos de servidor

tokens de servidor

tokens de servidor

cifrados SSL

cifrados SSL

parámetro ssl-dh

archivo ssl-dhparam

protocolos SSL

protocolos SSL

redirección SSL

redirección SSL

conexiones de mantenimiento de flujo ascendente

mantener viva

usar-http2

http2

protocolo de uso proxy

protocolo proxy

variables-hash-bucket-size

variables-hash-bucket-size

afinidad de la CPU del trabajador

afinidad de la CPU del trabajador

procesos de trabajo

procesos de trabajo

tiempo de espera de apagado del trabajador

tiempo de espera de apagado del trabajador

resumen

Puede migrar del controlador de Ingress de la comunidad al controlador de Ingress de NGINX utilizando recursos de Ingress de NGINX personalizados o el recurso de Ingress de Kubernetes estándar con anotaciones y ConfigMaps. La primera opción admite un conjunto más amplio de capacidades de red y, por lo tanto, es más adecuada para entornos de Kubernetes de nivel de producción.

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

Pruebe usted mismo el controlador de ingreso NGINX basado en NGINX Plus hoy mismo con una prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .

Leer más publicaciones de blog sobre F5 NGINX ›

"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.