NGINX Ingress Controller versión 2.0: lo que necesitas saber

Brian EhlertDirector de Gestión de Producto

En octubre, lanzamos la versión 2.0 de F5 NGINX Ingress Controller (nginxinc/kubernetes-ingress), que incorporaba compatibilidad con Kubernetes 1.22 y la versión 1 de la API de Ingress (networking.k8s.io/v1). Quizá te preguntes: «¿y qué?»

La respuesta a ese «¿y qué?» tiene sus matices, y la abordaremos respondiendo a tres preguntas relacionadas entre sí:

• ¿Por qué son tan importantes las versiones de Kubernetes?
• ¿Qué es la API Ingress y por qué es importante actualizar a networking.k8s.io/v1?
• ¿Cómo afecta NGINX Ingress Controller 2.0 a los clientes actuales?

Sigue leyendo para conocer las respuestas y no te pierdas Tu plan de batalla para cuando ataquen las versiones de Kubernetes el 11 de enero de 2022.

¿Por qué son tan importantes las versiones de Kubernetes?

La respuesta a esta pregunta es sencilla y, a la vez, complicada. La gestión de la compatibilidad de Kubernetes resulta difícil porque sus operadores tienen que gestionar tres categorías de versiones:

1. La propia plataforma Kubernetes – Con cada nueva versión, el equipo de Kubernetes deja de mantener una versión anterior. Seguir utilizando una versión de este tipo plantea problemas para su estrategia de gestión de riesgos y dificulta la resolución de problemas, ya que el equipo de Kubernetes deja de ofrecer asistencia. Actualmente, el proyecto Kubernetes mantiene ramas para las tres versiones secundarias más recientes (1.20, 1.21 y 1.22). Kubernetes 1.19 y las versiones posteriores reciben aproximadamente 1 año de soporte para parches, mientras que la versión 1.18 y las anteriores recibieron aproximadamente 9 meses. (Este periodo más corto para la versión 1.18 y las anteriores se debe a que Kubernetes solía publicar cuatro versiones al año, en lugar de las tres actuales).
2. Las API de Kubernetes – En cada versión de Kubernetes se crean nuevas API y se dejan obsoletas las antiguas, y los cambios en las API afectan a los recursos y las herramientas correspondientes. Al actualizar la plataforma Kubernetes, es posible que también tenga que actualizar las API.
3. Las herramientas que has implementado en Kubernetes – Un cambio importante en Kubernetes o en sus API puede afectar al correcto funcionamiento de tus herramientas – como un controlador de Ingress – y de los recursos correspondientes.

Por tanto, debes hacer un seguimiento de tres ciclos de versiones: uno para Kubernetes, otro para la API de Ingress y otro para NGINX Ingress Controller. Para evitar que Kubernetes deje de funcionar, debes encontrar el punto óptimo en el que la versión de Kubernetes sea compatible con las API y con NGINX Ingress Controller. Actualizar cualquiera de los tres componentes sin comprobar su compatibilidad puede tener consecuencias drásticas. Si los tres componentes no son compatibles entre sí… ¡enhorabuena, has dejado tus aplicaciones fuera de servicio!

¿Qué es la API de Ingress y por qué es importante networking.k8s.io/v1?

La API de Ingress permite que un controlador de Ingress exponga de forma segura sus aplicaciones de Kubernetes. La API networking.k8s.io/v1 (también conocida como API de Ingress v1) se introdujo con Kubernetes 1.19. En aquel momento, Kubernetes admitía tanto v1beta1 como v1 y convertía automáticamente una versión en la otra. Esta compatibilidad «interna» entre versiones de la API aporta ventajas operativas, pero puede dificultar sus tareas de planificación.

Con el lanzamiento de Kubernetes 1.22, v1 pasó a ser la única versión de la API de Ingress. Esto es importante porque, al convertirse la versión v1 de la API de Ingress en «la única», todas las versiones beta (extensions/v1beta1 y networking.k8s.io/v1beta1) quedan obsoletas. Aunque esto supone un contratiempo para las organizaciones que aún no han adoptado la versión v1 de la API de Ingress, en NGINX consideramos que este cambio es una buena señal. La salida de la fase beta de la API de Ingress indica que ha alcanzado la madurez y se ha convertido en una API plenamente desarrollada. Ahora bien, ¿por qué es importante este cambio? La respuesta tiene que ver con la gestión de versiones. Supongamos que actualiza un clúster existente a Kubernetes 1.22, pero sigue utilizando recursos relacionados con Ingress de la versión v1beta1… Enhorabuena: ¡acaba de inutilizar sus recursos de Ingress!

¿Cómo afecta NGINX Ingress Controller 2.0 a los clientes actuales?

Dado que NGINX Ingress Controller está estrechamente vinculado a la API Ingress, el lanzamiento de v1 tuvo un impacto significativo tanto en nuestro producto como en vosotros, nuestros clientes, por lo que hemos cambiado el número de versión de NGINX Ingress Controller de 1.x a 2.x. Rediseñamos la arquitectura de NGINX Ingress Controller 2.0 para aprovechar la API Ingress v1, lo que lo hace totalmente compatible con Kubernetes 1.22.

Si utiliza NGINX Ingress Controller, debe tomar de inmediato algunas medidas en función de la versión para evitar que Kubernetes, sus recursos de Ingress o NGINX Ingress Controller dejen de funcionar:

• Kubernetes 1.18 y versiones anteriores:
  • Asegúrate de utilizar NGINX Ingress Controller 1.12 para poder aprovechar el conjunto más completo de funcionalidades disponible. (Cuando actualices a NGINX Ingress Controller 2.0, también tendrás que actualizar a Kubernetes 1.19 o una versión posterior.)
  • Planifique la migración a una versión más reciente de Kubernetes (y de NGINX Ingress Controller) en los próximos meses, ya que Kubernetes 1.18 dejará de ser compatible tras la próxima versión de Kubernetes.
• Kubernetes 1.19–1.21:
  • Actualice a NGINX Ingress Controller 2.0.
  • Si aún no has migrado tus recursos relacionados con Ingress a networking.k8s.io/v1 (consulta las notas de la versión 2.0 de NGINX Ingress Controller), prepara ya tu plan. Kubernetes 1.19–1.21 admite todas las versiones actuales de la API de Ingress (tanto las versiones v1beta1 como v1), lo que te permite realizar la conversión directamente.
  • Si aún no lo ha hecho, migre inmediatamente sus recursos Ingress e IngressClass a networking.k8s.io/v1.
    • Si utiliza la anotación obsoleta kubernetes.io/ingress.class en sus recursos Ingress, le recomendamos que utilice el campo ingressClassName.
    • Utilice nuestra documentación y nuestros ejemplos (disponibles con networking.k8s.io/v1 y el campo ingressClassName del recurso Ingress) para planificar sus actualizaciones.
• Kubernetes 1.22:
  • Asegúrese de que ya está ejecutando NGINX Ingress Controller 2.0, ya que las versiones anteriores de NGINX Ingress Controller no son compatibles con Kubernetes 1.22 ni admiten Ingress API v1.

Breve historia (o no tanto) de NGINX Ingress Controller

Desde su primera versión en 2016, NGINX Ingress Controller ha pasado de ser una herramienta incipiente a convertirse en una solución de referencia para las redes de Kubernetes. Veamos cómo ha evolucionado desde su lanzamiento hasta la actualidad.

2016 (v0.5.0)

El ingeniero de NGINX Michael Pleshakov publica la primera entrada en nuestro repositorio de GitHub (nginxinc/kubernetes-ingress), lo que permite utilizar NGINX y F5 NGINX Plus como controlador de Ingress de Kubernetes (KIC).

NGINX Ingress Controller hace su primera aparición pública en KubeCon EU 2016. Vea la grabación: Día 1: Creación de una solución avanzada de balanceo de carga para Kubernetes con NGINX; KubeCon EU 2016.

2017 (v1.0.0)

El proyecto alcanza un nivel de madurez apto para producción e incluye compatibilidad esencial con JSON Web Tokens (JWT) en la versión basada en NGINX Plus.

En NGINX Conf 2017, Michael Pleshakov demuestra las capacidades de producción, incluido el balanceo de carga avanzado, en «Uso de NGINX Plus como controlador de entrada para el balanceo de carga de aplicaciones en Kubernetes».

2018

NGINX Ingress Controller incorpora importantes mejoras en cuanto a visibilidad, facilidad de uso y flexibilidad:

• Mayo (v1.2.0) – El proyecto adopta la nueva API de NGINX Plus y las imágenes de nginx-ingress se trasladan al repositorio oficial de NGINX Docker Hub. Esta versión incorpora por primera vez compatibilidad con gRPC, comprobaciones de estado pasivas, gráficos de Helm y Prometheus.
• Agosto (v1.3.0) – Los clientes de NGINX Plus ahora pueden exportar métricas a Prometheus y aprovechar las comprobaciones de estado activas, mientras que todos los usuarios se benefician de las mejoras en los charts de Helm, los recursos Ingress combinables y una gestión más sencilla de las plantillas personalizadas (consulte Anuncio de NGINX Ingress Controller para Kubernetes, versión 1.3.0).
• Noviembre (v1.4.0) – Se añade compatibilidad con TCP/UDP, lo que permite gestionar el tráfico de capa 4. Otras funciones incluyen un desarrollo más sencillo de anotaciones personalizadas y compatibilidad con el algoritmo de balanceo de carga «Random with Two Choices» (consulte Anuncio de NGINX Ingress Controller para Kubernetes, versión 1.4.0).

En NGINX Conf 2018, Michael Pleshakov sube al escenario para presentar «Uso de NGINX como controlador de entrada de Kubernetes», donde explica cómo implementar NGINX Ingress Controller con Helm, configurar el balanceo de carga HTTP y TCP/UDP, monitorizarlo con Prometheus y solucionar problemas.

2019

Presentamos nuestra alternativa a los recursos Ingress estándar de Kubernetes, que permite implementar funcionalidades avanzadas de forma más sencilla y fiable.

• Mayo (v1.5.0) – Se introducen los recursos VirtualServer y VirtualServerRoute (VS/VSR) como un nuevo enfoque de configuración. VS/VSR son los primeros recursos Ingress de NGINX, que ofrecen un estilo de configuración nativo, con seguridad de tipos y basado en sangrías que simplifica la implementación del balanceo de carga de Ingress (consulte Anuncio de NGINX Ingress Controller para Kubernetes, versión 1.5.0<.htmla>).
• Diciembre (v1.6.0) – Se publica la documentación en docs.nginx.com. Los recursos VS/VSR incorporan una compatibilidad más amplia con el balanceo de carga y quedan listos para su uso en producción. Se añade compatibilidad con OpenTracing para mejorar la supervisión y la depuración, así como la posibilidad de ejecutarse como un usuario distinto de «root» para reforzar la seguridad (consulte Anuncio de NGINX Ingress Controller para Kubernetes, versión 1.6.0).

En «La nueva generación de NGINX Ingress Controller», Michael Pleshakov vuelve a NGINX Conf 2019 para mostrar el uso de VS/VSR en casos como las implementaciones blue-green y las pruebas A/B.

2020

Además de numerosas mejoras en los recursos de NGINX Ingress, el tema principal de este año es la integración con las herramientas del ecosistema y los productos de NGINX.

• Abril (v1.7.0) – Lanzamos NGINX Ingress Operator para ofrecer una forma rápida, sencilla y certificada de implementar NGINX Ingress Controller en entornos OpenShift 4.x. Los recursos de NGINX Ingress siguen ampliándose con compatibilidad con protocolos adicionales, disyuntores y mejoras en la validación y la generación de informes (consulte Anuncio de NGINX Ingress Controller para Kubernetes, versión 1.7.0).
• Julio (v1.8.0) – La integración con F5 NGINX App Protect WAF permite a los clientes implementar un WAF ligero y flexible en el mismo contenedor que el controlador de Ingress. Se añade la posibilidad de personalizar los recursos de NGINX Ingress mediante fragmentos de código o plantillas personalizadas, y funciones como la reescritura de URI y las listas de control de acceso ofrecen un control más granular (consulte Anuncio de NGINX Ingress Controller para Kubernetes, versión 1.8.0).
• Octubre (v1.9.0) – La integración con F5 NGINX Service Mesh permite gestionar el tráfico norte-sur y este-oeste en una misma configuración. Se añaden paneles de Grafana para facilitar la visualización de datos históricos (consulte Anuncio de NGINX Ingress Controller versión 1.9.0).

En Protección de aplicaciones en producción con NGINX y OpenShift, el ingeniero de marketing técnico Amir Rawdat muestra cómo utilizar NGINX Ingress Operator, aprovechar el control de acceso basado en roles (RBAC) para el aprovisionamiento entre distintos equipos, proteger aplicaciones en contenedores con NGINX App Protect y validar clientes mediante JWT.

2021

La seguridad es un tema central, junto con una mayor integración con el ecosistema.

• Febrero (v1.10.0) – La principal novedad es la autenticación mediante OpenID Connect (OIDC), que facilita el uso de la autenticación JWT para ofrecer una opción sólida de inicio de sesión único (SSO) (consulte Inicio de sesión único sencillo y sólido con OpenID Connect y NGINX Ingress Controller).
• Marzo (v1.11.0) – Las importantes mejoras en las políticas del WAF y de equilibrio de carga ofrecen mayor potencia y flexibilidad, incluidas las comprobaciones de estado y los informes de estado (consulte Equilibrio de carga TCP/UDP mejorado y configuración del WAF con NGINX Ingress Controller).
• Julio (v1.12.0) – Los aspectos más destacados de esta versión se centran en facilitar la implementación. Además de poder adquirirlo a través de AWS Container Marketplace, ofrecemos la posibilidad de descargar imágenes precompiladas desde F5 Container Registry (consulte NGINX está disponible en AWS Marketplace for Containers).
• Octubre (v2.0.3) – Aunque no supone un gran hito en cuanto a funcionalidades, esta versión marca un antes y un después en la interoperabilidad con la API de Kubernetes y la evolución del objeto Ingress. Este cambio implica que NGINX Ingress Controller 2.0 (y versiones posteriores) es compatible con Kubernetes 1.19 y versiones posteriores. NGINX Ingress Controller 2.0 también es la única versión que se puede implementar con Kubernetes 1.22 y versiones posteriores.

En su sesión de NGINX Sprint 2.0, Domine los microservicios con cifrado de extremo a extremo, el ingeniero de software Aidan Carson muestra cómo proteger el perímetro con NGINX Ingress Controller, configurar un control de acceso seguro entre servicios con NGINX Service Mesh y utilizar ambos productos para proteger el tráfico saliente con mTLS.

Siguiente paso: prueba NGINX Ingress Controller

Si has decidido que un controlador Ingress de código abierto es la opción adecuada para tus aplicaciones, puedes empezar rápidamente con NGINX Ingress Controller, basado en NGINX Open Source, en nuestro repositorio de GitHub.

Para grandes implementaciones en producción, esperamos que pruebe nuestro NGINX Ingress Controller comercial basado en NGINX Plus. Está disponible con una prueba gratuita de 30 días que incluye NGINX App Protect.

Sobre el autor

Brian EhlertDirector de Gestión de Producto

Más artículos de Brian Ehlert