Guía para elegir un controlador de Ingress, parte 2: riesgos y preparación para el futuro

Jenn GileResponsable de Marketing de Producto, NGINX

Editor – Esta publicación forma parte de una serie de 10 entregas:

1. Reduzca la complejidad con Kubernetes preparado para producción
2. Cómo mejorar la resiliencia en Kubernetes con una gestión avanzada del tráfico
3. Cómo mejorar la visibilidad en Kubernetes
4. Seis formas de proteger Kubernetes mediante herramientas de gestión del tráfico
5. Guía para elegir un controlador de Ingress, parte 1: identifique sus requisitos
6. Guía para elegir un controlador de Ingress, parte 2: riesgos y preparación para el futuro (esta publicación)
7. Guía para elegir un controlador de Ingress, parte 3: código abierto, predeterminado o comercial
8. Guía para elegir un controlador de Ingress, parte 4: opciones del controlador de Ingress de NGINX
9. Cómo elegir una malla de servicios
10. Pruebas de rendimiento de los controladores Ingress de NGINX en un entorno dinámico de Kubernetes en la nube

También puedes descargar la colección completa de artículos del blog como libro electrónico gratuito: «Cómo llevar Kubernetes de las pruebas a producción».

En la parte 1 de nuestra guía para elegir un controlador de Ingress, explicamos cómo identificar sus requisitos. Pero todavía no ha llegado el momento de probar productos. En este artículo, explicamos cómo elegir el controlador de Ingress equivocado puede ralentizar el ritmo de sus lanzamientos e incluso hacerle perder clientes. Como cualquier otra herramienta, los controladores de Ingress pueden introducir riesgos y afectar a la escalabilidad futura. Veamos cómo descartar las opciones que podrían causar más perjuicios que beneficios.

Riesgos de los controladores de Ingress

Hay tres riesgos específicos que debe tener en cuenta al introducir una herramienta de gestión del tráfico para Kubernetes: la complejidad, la latencia y la seguridad. Estos problemas suelen estar interrelacionados; cuando aparece uno, es probable que también surjan los demás. Cualquiera de ellos puede deberse a un controlador Ingress, y corresponde a su organización decidir si el riesgo es asumible. Los consumidores actuales son volubles, y cualquier factor que provoque una mala experiencia digital puede resultar inaceptable, por muy atractivo que sea el conjunto de funcionalidades.

Complejidad: ¿desvirtúa el propósito de una arquitectura de microservicios?

Las mejores herramientas de Kubernetes son aquellas que cumplen los objetivos de la arquitectura de microservicios: son ligeras y tienen un diseño sencillo. Es posible desarrollar un controlador Ingress con numerosas funcionalidades que respete estos principios, pero no siempre es así. Algunos diseñadores incluyen demasiadas funciones o recurren a scripts complejos para añadir capacidades que no son nativas del motor subyacente, lo que da lugar a un controlador Ingress innecesariamente complejo.

¿Y por qué es importante? En Kubernetes, una herramienta excesivamente compleja puede afectar negativamente al rendimiento de las aplicaciones y limitar la capacidad de escalar horizontalmente el despliegue. Por lo general, se puede detectar un controlador Ingress demasiado complejo por su tamaño: cuanto mayor sea su huella, más compleja será la herramienta.

Latencia: ¿el controlador de Ingress ralentiza tus aplicaciones?

Los controladores de Ingress pueden aumentar la latencia debido al uso de recursos, los errores y los tiempos de espera. Analice la latencia añadida tanto en implementaciones estáticas como dinámicas y descarte las opciones que introduzcan una latencia inaceptable según sus requisitos internos. Para obtener más información sobre cómo las reconfiguraciones pueden afectar a la velocidad de las aplicaciones, consulte Pruebas de rendimiento de los controladores de Ingress de NGINX en un entorno dinámico de Kubernetes en la nube en nuestro blog.

Seguridad: ¿el controlador de Ingress abre la puerta a los hackers?

Las vulnerabilidades y exposiciones comunes (CVE) proliferan en la Internet actual, y el tiempo que tarde el proveedor de su controlador de Ingress en proporcionar un parche para una CVE puede marcar la diferencia entre mantenerse a salvo y sufrir una brecha de seguridad. En función de la tolerancia al riesgo de su organización, quizá le convenga descartar las soluciones que tarden más de unos días (o, como máximo, unas semanas) en proporcionar parches.

Más allá de las CVE, algunos controladores Ingress pueden exponerle a otra posible vulnerabilidad. Imagine esta situación: trabaja para un minorista en línea y necesita ayuda para solucionar problemas de configuración de su controlador Ingress de código abierto. Como no dispone de soporte comercial, publica el problema en un foro como Stack Overflow. Alguien se ofrece a ayudarle y quiere revisar los archivos de configuración y de registro del controlador Ingress y de otros componentes de Kubernetes para detectar posibles problemas. Ante la presión por resolver el problema rápidamente, comparte los archivos.

El «buen samaritano» te ayuda a resolver el problema, pero seis meses después descubres una brecha de seguridad: han robado números de tarjetas de crédito de los registros de tus clientes. Vaya. Resulta que los archivos que compartiste contenían información que se utilizó para infiltrarse en tu aplicación. Este caso ilustra uno de los principales motivos por los que las organizaciones optan por pagar por un servicio de soporte: garantiza la confidencialidad.

Nota sobre los controladores de Ingress basados en OpenResty

OpenResty es una plataforma web basada en NGINX Open Source que incorpora LuaJIT, scripts de Lua y módulos de NGINX de terceros para ampliar la funcionalidad de NGINX Open Source. A su vez, existen varios controladores de Ingress basados en OpenResty que, en nuestra opinión, podrían añadir dos riesgos con respecto a nuestros controladores de Ingress basados en NGINX Open Source y NGINX Plus:

• Tiempos de espera – Como se ha señalado, OpenResty utiliza scripts de Lua para implementar funciones avanzadas como las de nuestro Ingress Controller comercial basado en NGINX Plus. Una de estas funciones es la reconfiguración dinámica, que elimina un requisito de NGINX Open Source que reduce la disponibilidad: concretamente, la necesidad de volver a cargar la configuración de NGINX cuando cambian los endpoints de servicio. Para llevar a cabo la reconfiguración dinámica con OpenResty, el controlador de Lua elige el servicio ascendente al que se debe dirigir la solicitud, lo que elimina la necesidad de volver a cargar la configuración de NGINX. Sin embargo, Lua debe comprobar continuamente si hay cambios en los backends, lo que consume recursos. Las solicitudes entrantes tardan más en procesarse, lo que provoca que algunas queden bloqueadas y aumenta la probabilidad de que se agote el tiempo de espera. A medida que aumenta el número de usuarios y servicios, la diferencia entre el número de solicitudes entrantes por segundo y el número que Lua puede gestionar crece exponencialmente. El resultado es una mayor latencia y complejidad, así como costes más elevados. Consulte Pruebas de rendimiento de los Ingress Controllers de NGINX en un entorno dinámico de nube de Kubernetes para comprobar cuánta latencia puede añadir Lua.
• Retrasos en la aplicación de parches para CVE – En comparación con los controladores Ingress de NGINX, los parches para CVE tardan inevitablemente más en aparecer en los controladores Ingress basados en herramientas como OpenResty, que a su vez se basan en NGINX Open Source. Como explicamos en detalle en Mitigación rápida y sencilla de vulnerabilidades de seguridad con NGINX Plus, cuando se descubre una CVE en NGINX, por lo general se nos informa como proveedor antes de que se divulgue públicamente. Esto nos permite publicar un parche para NGINX Open Source y NGINX Plus en cuanto se anuncia la CVE. Es posible que las tecnologías basadas en NGINX Open Source no tengan conocimiento de la CVE hasta ese momento y, según nuestra experiencia, los parches de OpenResty se retrasan considerablemente con respecto a los nuestros: cuatro meses en un caso reciente. Los parches para un controlador Ingress basado en OpenResty tardan inevitablemente aún más, lo que brinda a un agente malintencionado tiempo de sobra para aprovechar la vulnerabilidad.

Prepare su controlador de Ingress para el futuro

Aunque apenas estés empezando a experimentar con Kubernetes, es muy probable que aspires a ponerlo en producción algún día. Hay cuatro áreas principales en las que es probable que tus necesidades aumenten con el tiempo: infraestructura, seguridad, soporte y multitenencia.

Infraestructura: ¿Utilizará Kubernetes en entornos híbridos o multinube?

Es poco habitual que una organización se comprometa de forma plena y permanente con un único tipo de entorno. Lo más común es que las organizaciones combinen entornos locales y en la nube, que pueden incluir nubes privadas, públicas, híbridas y múltiples. (Para obtener más información sobre las diferencias entre estos entornos, consulte «¿Cuál es la diferencia entre la multinube y la nube híbrida?»).

Como mencionamos en la Parte 1 de esta serie, puede resultar tentador elegir las herramientas predeterminadas de cada entorno, pero los controladores de Ingress predeterminados presentan numerosos problemas específicos. Abordaremos todos sus inconvenientes en la Parte 3 de la serie, pero el problema más relevante de cara al futuro es la dependencia de un proveedor: no se puede utilizar un controlador de Ingress específico de una nube en todos los entornos. El uso de herramientas predeterminadas específicas de una nube afecta a la capacidad de escalar, ya que solo quedan dos alternativas poco atractivas:

1. Intentar que la nube actual cubra todas tus necesidades
2. Reescriba todas sus configuraciones —no solo las de equilibrio de carga, sino también las de seguridad— para el controlador Ingress en cada nuevo entorno

Aunque la primera alternativa a menudo no es viable por motivos empresariales, la segunda también resulta complicada, ya que provoca la proliferación de herramientas, abre nuevas vulnerabilidades de seguridad y obliga a los empleados a afrontar curvas de aprendizaje pronunciadas. La tercera alternativa, y la más eficiente, consiste en elegir desde el principio un controlador de Ingress independiente de la infraestructura, lo que permite utilizar la misma herramienta en todos los entornos.

En lo que respecta a la infraestructura, hay otro aspecto que debe tenerse en cuenta: las certificaciones. Tomemos como ejemplo Red Hat OpenShift Container Platform (OCP). Si utiliza OCP, probablemente ya sepa que Red Hat Marketplace ofrece operadores certificados para OCP, entre ellos NGINX Ingress Operator. Los estándares de certificación de Red Hat le ofrecen la tranquilidad de saber que la herramienta funciona con su implementación y que incluso puede incluir soporte conjunto de Red Hat y del proveedor. Muchas organizaciones exigen el uso de herramientas certificadas por motivos de seguridad y estabilidad, por lo que, aunque ahora solo esté realizando pruebas, conviene tener presentes los requisitos de su empresa para los entornos de producción.

Seguridad: ¿cómo protegerá Kubernetes desde dentro?

Atrás quedaron los días en que la seguridad perimetral bastaba por sí sola para proteger las aplicaciones y a los clientes. Las aplicaciones de Kubernetes están mejor protegidas cuando la seguridad —incluidas la autenticación y la autorización— se sitúa cerca de ellas. Y dado que cada vez más organizaciones exigen el cifrado de extremo a extremo y adoptan un modelo de red de confianza cero dentro de Kubernetes, es posible que una malla de servicios forme parte de su futuro.

¿Qué tiene que ver todo esto con tu controlador de Ingress? ¡Mucho! Centralizar la seguridad (autenticación, autorización, protección contra ataques DoS y firewall de aplicaciones web) en el punto de entrada tiene mucho sentido tanto desde el punto de vista de los costes como de la eficiencia. Y aunque la mayoría de las mallas de servicios pueden integrarse con la mayoría de los controladores de Ingress, la forma en que se integran es muy importante. Un controlador de Ingress que se ajuste a tu estrategia de seguridad puede evitarte grandes quebraderos de cabeza durante todo el proceso de desarrollo de tus aplicaciones.

Lea «Proteja las aplicaciones nativas de la nube sin perder velocidad» para obtener más información sobre los riesgos de la entrega de aplicaciones nativas de la nube y «Implementación de servicios de aplicaciones en Kubernetes, parte 2» para conocer mejor los factores que determinan la ubicación óptima de las herramientas de seguridad.

Soporte: ¿hasta qué punto puede permitirse estar «por su cuenta»?

Cuando los equipos apenas están empezando a experimentar con Kubernetes, el soporte —ya sea de la comunidad o de una empresa— no suele ser la máxima prioridad. Esto no supone un problema si sus equipos disponen de mucho tiempo para idear sus propias soluciones y alternativas, pero no es sostenible cuando se pasa a producción. Aunque actualmente no necesite soporte, puede ser conveniente elegir un controlador de Ingress que le permita añadirlo en el futuro o que cuente con un nivel de soporte económico que pueda ampliarse a medida que crece.

Multiinquilinato: ¿cómo pueden varios equipos y aplicaciones compartir un entorno de contenedores de forma segura?

Al principio, había un equipo y una aplicación… ¿no es así como empiezan todas las historias? La historia suele continuar con ese equipo desarrollando con éxito su aplicación en Kubernetes, lo que lleva a la organización a ejecutar más servicios en Kubernetes. Y, por supuesto, más servicios = más equipos = más complejidad.

Para lograr la máxima eficiencia, las organizaciones adoptan la tenencia múltiple y un modelo de Kubernetes que permite aplicar el acceso y el aislamiento exigidos por sus procesos empresariales, al tiempo que proporciona la coherencia y los controles que necesitan sus operadores. Algunos controladores de Ingress pueden ayudarle a segmentar esos clústeres mediante diversas funciones y conceptos: múltiples Ingress, clases, espacios de nombres y recursos con ámbito definido que permiten configurar controles de acceso basados en roles (RBAC).

Siguiente paso: reducir las opciones

Ahora que ha reflexionado sobre sus requisitos, su tolerancia al riesgo y la capacidad de adaptación a necesidades futuras, dispone de información suficiente para empezar a acotar el amplísimo abanico de controladores Ingress. Dividirlos por categorías puede ayudarle a completar rápidamente este paso. En la parte 3 de nuestra serie, analizaremos tres categorías diferentes de controladores Ingress, incluidas las ventajas y desventajas de cada una.

Sobre el autor

Jenn GileResponsable de Marketing de Producto, NGINX

Más artículos de Jenn Gile