BLOG | NGINX

Controlador de ingreso NGINX versión 2.0: Lo que necesitas saber

NGINX - Parte de F5 - horizontal, negro, tipo RGB
Miniatura de Brian Ehlert
Brian Ehlert
Publicado el 27 de diciembre de 2021

En octubre, lanzamos F5 NGINX Ingress Controller versión 2.0 ( nginxinc/kubernetes-ingress ) , agregando soporte para Kubernetes 1.22 y la versión 1 de la API de Ingress ( networking.k8s.io/v1 ). Quizás te estés preguntando: ¿y qué?

Ese “y qué” tiene matices y lo responderemos respondiendo tres preguntas interrelacionadas:

Continúe leyendo para conocer las respuestas y sintonice su plan de batalla para cuando las versiones de Kubernetes ataquen el 11 de enero de 2022 .

¿Por qué son tan importantes los lanzamientos de Kubernetes?

La respuesta a esta pregunta es simple pero complicada. La gestión de la compatibilidad para Kubernetes es un desafío porque los operadores de Kubernetes deben administrar tres categorías de versiones:

  1. La plataforma Kubernetes en sí : en cada nuevo lanzamiento, el equipo de Kubernetes deja de mantener una versión anterior. Seguir usando dicha versión es problemático para su estrategia de gestión de riesgos y dificulta la resolución de problemas porque la ayuda del equipo de Kubernetes ya no está disponible. En la actualidad, el proyecto Kubernetes mantiene ramas de lanzamiento para las tres versiones menores más recientes (1.20, 1.21 y 1.22). Kubernetes 1.19 y versiones posteriores reciben aproximadamente 1 año de soporte de parches, mientras que 1.18 y versiones anteriores reciben aproximadamente 9 meses de soporte de parches. (El lapso de tiempo más corto para la versión 1.18 y anteriores se debe a que Kubernetes solía lanzar cuatro veces al año, en lugar de las tres actuales).

  2. Las API de Kubernetes : en cada lanzamiento de Kubernetes nacen nuevas API y las obsoletas quedan en desuso, y los cambios en las API afectan los recursos y las herramientas correspondientes. Cuando actualice su plataforma Kubernetes, es posible que también tenga que actualizar las API.

  3. Las herramientas que ha implementado en Kubernetes : un cambio importante en Kubernetes o sus API puede afectar si sus herramientas (como un controlador de Ingress) y los recursos correspondientes continúan funcionando correctamente.

Por lo tanto, debe realizar un seguimiento de tres líneas de tiempo: una para Kubernetes, una para la API de Ingress y una para el controlador de Ingress NGINX. Para evitar romper Kubernetes, debes encontrar el punto óptimo donde la versión de Kubernetes sea compatible con las API y el controlador de ingreso NGINX. Actualizar cualquiera de los tres componentes sin verificar la compatibilidad puede tener consecuencias drásticas. Si los tres componentes no son compatibles entre sí… ¡felicitaciones, has dañado tus aplicaciones!

¿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 La API de Ingress v1 se introdujo con Kubernetes 1.19. En ese momento, Kubernetes admitía tanto v1beta1 como v1 y presentaba automáticamente una versión como la otra. Esta compatibilidad “oculta” de las versiones API lo beneficia operativamente, pero puede obstaculizar sus esfuerzos de planificación.

Con el lanzamiento de Kubernetes 1.22, la v1 se convirtió en la única versión de la API de Ingress. Esto es importante, ya que, al convertirse la v1 en la única, todas las versiones beta ( extensions/v1beta1 y networking.k8s.io/v1beta1 ) quedaron obsoletas. Si bien esto es disruptivo para las organizaciones que aún no han adoptado Ingress API v1, en NGINX vemos este cambio como una buena señal. La salida de la versión beta de la API de Ingress indica su transición a una API madura y plenamente desarrollada. Ahora bien, ¿por qué es importante este cambio? Bueno, eso se relaciona con la gestión de versiones. Digamos que actualiza un clúster existente a Kubernetes 1.22, pero continúa usando recursos relacionados con Ingress v1beta1 ... ¡felicitaciones, ha dañado sus recursos de Ingress!

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

Debido a que NGINX Ingress Controller está estrechamente acoplado a la API de Ingress, el lanzamiento de la versión v1 nos impactó significativamente como producto, y también a ustedes como nuestros clientes, por lo que hemos aumentado el número de versión de NGINX Ingress Controller de 1. x a 2. x . Rediseñamos NGINX Ingress Controller 2.0 para aprovechar Ingress API v1, haciéndolo totalmente compatible con Kubernetes 1.22.

Si usa el controlador de ingreso NGINX, debe tomar algunas acciones dependientes de la versión de inmediato para evitar dañar Kubernetes, sus recursos de ingreso o el controlador de ingreso NGINX:

  • Kubernetes 1.18 y anteriores:

    • Asegúrese de utilizar NGINX Ingress Controller 1.12 para poder aprovechar el conjunto más completo de funciones disponibles. (Cuando actualice a NGINX Ingress Controller 2.0, también deberá actualizar a Kubernetes 1.19 o posterior).

    • Haga un plan para migrar a una versión más nueva de Kubernetes (y NGINX Ingress Controller) en los próximos meses, ya que Kubernetes 1.18 no será compatible después del próximo lanzamiento de Kubernetes.

  • Kubernetes 1.19–1.21:

    • Actualice al controlador de ingreso NGINX 2.0.

    • Si aún no ha migrado sus recursos relacionados con Ingress a networking.k8s.io/v1 (consulte las notas de la versión de NGINX Ingress Controller 2.0 ), cree su plan ahora. Kubernetes 1.19–1.21 admite todas las versiones actuales de la API de Ingress (tanto v1beta1 como v1 ), lo que le brinda la oportunidad de realizar la conversión en el lugar.

    • Si aún no lo ha hecho, mueva inmediatamente sus recursos Ingress e IngressClass a networking.k8s.io/v1 .

      • Si está utilizando la anotación obsoleta kubernetes.io/ingress.class en sus recursos de Ingress, le recomendamos cambiar al campo ingressClassName .

      • Utilice nuestra documentación y 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 y no admiten Ingress API v1.

Una historia (no tan) breve del controlador de ingreso NGINX

Desde su primer lanzamiento en 2016, NGINX Ingress Controller ha pasado de ser una herramienta incipiente a convertirse en una potencia para las redes de Kubernetes. He aquí un vistazo a su evolución desde su lanzamiento hasta la actualidad.

2016 ( versión 0.5.0 )

El ingeniero de NGINX Michael Pleshakov publica la primera entrada en nuestro repositorio de GitHub ( nginxinc/kubernetes-ingress ) , lo que hace posible el uso de NGINX y F5 NGINX Plus como un controlador de ingreso de Kubernetes (KIC).

El controlador de ingreso NGINX hace su primera aparición pública en KubeCon EU 2016 . Mira la grabación: Día 1, Creación de una solución de equilibrio de carga avanzada para Kubernetes con NGINX; KubeCon EU 2016 .

2017 ( versión 1.0.0 )

El proyecto alcanza la etapa de preparación para producción, incluido soporte clave para JSON Web Tokens (JWT) en la versión basada en NGINX Plus .

En NGINX Conf 2017, Michael Pleshakov demuestra capacidades de producción que incluyen equilibrio de carga avanzado en Uso de NGINX Plus como controlador de ingreso para aplicações de equilibrio de carga en Kubernetes .

2018

El controlador de ingreso NGINX presenta grandes mejoras en las áreas de visibilidad, facilidad de uso y flexibilidad:

En NGINX Conf 2018, Michael Pleshakov sube al escenario para Usar NGINX como controlador de ingreso de Kubernetes , donde comparte cómo implementar el controlador de ingreso de NGINX con Helm, configurar el equilibrio de carga HTTP y TCP/UDP, monitorear con Prometheus y solucionar problemas.

2019

Presentamos nuestra alternativa a los recursos estándar de Ingress de Kubernetes, haciendo más fácil y confiable la ejecución de capacidades avanzadas.

En La próxima generación del controlador de ingreso NGINX , Michael Pleshakov regresa a NGINX Conf 2019 para demostrar VS/VSR para casos de uso que incluyen implementaciones azul-verde y 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 NGINX.

En Aplicaciones de producción seguras con NGINX y OpenShift , el ingeniero de marketing técnico Amir Rawdat demuestra cómo utilizar el operador de ingreso NGINX, aprovechar el control de acceso basado en roles (RBAC) para el aprovisionamiento multifuncional, proteger aplicaciones en contenedores con NGINX App Protect y validar clientes con JWT.

2021

La seguridad es un tema principal, junto con más integraciones del ecosistema.

En su sesión NGINX Sprint 2.0 , Master Microservices with End-to-End Encryption , el ingeniero de software Aidan Carson demuestra cómo proteger el borde con NGINX Ingress Controller, configurar un control de acceso seguro entre servicios con NGINX Service Mesh y usar ambos productos para proteger el tráfico de salida con mTLS.

Próximo paso: Pruebe NGINX Ingress Controller

Si ha decidido que un controlador de Ingress de código abierto es la opción correcta para sus aplicaciones, puede comenzar rápidamente con el controlador de Ingress NGINX basado en código abierto en nuestro repositorio de GitHub .

Para implementaciones de producción a gran escala, esperamos que pruebe nuestro controlador de ingreso NGINX comercial basado en NGINX Plus. Está disponible para una prueba gratuita de 30 días que incluye NGINX App Protect.

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.