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

Editor : Esta publicación es parte de una serie de 10 partes:

1. Reduzca la complejidad con Kubernetes de nivel de producción
2. Cómo mejorar la resiliencia en Kubernetes con la 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 entrada, parte 1: Identifique sus requisitos
6. Guía para elegir un controlador de entrada, parte 2: Riesgos y preparación para el futuro (esta publicación)
7. Guía para elegir un controlador de entrada, parte 3: Código abierto vs. Predeterminado vs. Comercial
8. Guía para elegir un controlador de entrada, parte 4: Opciones del controlador de ingreso NGINX
9. Cómo elegir una malla de servicios
10. Pruebas de rendimiento de controladores de ingreso NGINX en un entorno dinámico de nube de Kubernetes

También puede descargar el conjunto completo de blogs como un libro electrónico gratuito: Cómo llevar Kubernetes de la prueba a la producción .

En la Parte 1 de nuestra guía para elegir un controlador Ingress , explicamos cómo identificar sus requisitos. ¡Pero todavía no es momento de probar productos! En esta publicación, explicamos cómo el controlador de Ingress incorrecto puede reducir la velocidad de lanzamiento e incluso costarle clientes. Como ocurre con cualquier herramienta, los controladores de Ingress pueden introducir riesgos y afectar la escalabilidad futura. Veamos cómo eliminar opciones que podrían causar más daño que bien.

Riesgos del controlador de ingreso

Hay tres riesgos específicos que debes considerar al introducir una herramienta de gestión de tráfico para Kubernetes: complejidad, latencia y seguridad. Estos problemas a menudo están entrelazados: cuando uno está presente, es probable que veas los demás. Cada uno de ellos puede ser introducido por un controlador de Ingress y depende de su organización decidir si el riesgo es tolerable. Los consumidores de hoy son volubles y cualquier cosa que provoque una mala experiencia digital puede ser inaceptable a pesar de contar con un conjunto de características atractivas.

Complejidad: ¿Acaso frustra el propósito de una arquitectura de microservicios?

Las mejores herramientas de Kubernetes son aquellas que cumplen los objetivos de la arquitectura de microservicios: diseño ligero y simple. Es posible desarrollar un controlador Ingress con muchas funciones que respete estos principios, pero esa no siempre es la norma. Algunos diseñadores incluyen demasiadas funciones o utilizan secuencias de comandos complicadas para agregar capacidades que no son nativas del motor subyacente, lo que da como resultado un controlador de Ingress innecesariamente complejo.

¿Y por qué importa eso? En Kubernetes, una herramienta demasiado compleja puede afectar negativamente el rendimiento de la aplicación y limitar su capacidad de escalar su implementación horizontalmente. Generalmente, puedes identificar un controlador Ingress demasiado complejo por su tamaño: cuanto mayor sea el espacio ocupado, más compleja será la herramienta.

Latencia: ¿El controlador de ingreso ralentiza sus aplicaciones?

Los controladores de ingreso pueden agregar latencia debido al uso de recursos, errores y tiempos de espera. Analice la latencia agregada en implementaciones estáticas y dinámicas y elimine las opciones que introducen una latencia inaceptable en función de sus requisitos internos. Para obtener más detalles sobre cómo las reconfiguraciones pueden afectar la velocidad de la aplicación, consulte Pruebas de rendimiento de controladores de ingreso NGINX en un entorno de nube Kubernetes dinámico en nuestro blog.

Seguridad: ¿El controlador de ingreso abre la puerta a los piratas informáticos?

Las vulnerabilidades y exposiciones comunes (CVE) abundan en Internet hoy en día, y el tiempo que tarda el proveedor del controlador de Ingress en proporcionar un parche CVE puede ser la diferencia entre la seguridad y una infracción. Según la tolerancia al riesgo de su organización, es posible que desee eliminar las soluciones que demoran más de unos pocos días (o semanas como máximo) en proporcionar parches.

Más allá de los CVE, algunos controladores de Ingress lo exponen a otra vulnerabilidad potencial. Considere este escenario: usted trabaja para un minorista en línea y necesita ayuda para solucionar problemas de configuración de su controlador Ingress de código abierto. El soporte comercial no está disponible, por lo que publica el problema en un foro como Stack Overflow. Alguien se ofrece a ayudar y quiere buscar problemas en los archivos de configuración y registro del controlador Ingress y otros componentes de Kubernetes. Sintiendo la presión de resolver el problema rápidamente, compartes los archivos.

El “buen samaritano” le ayuda a resolver su problema, pero seis meses después descubre una vulneración: han robado números de tarjetas de crédito de sus registros de clientes. Ups. Resulta que los archivos que compartiste incluían información que se utilizó para infiltrar tu aplicación. Este escenario ilustra una de las principales razones por las que las organizaciones optan por pagar por soporte: garantiza la confidencialidad.

Una nota sobre los controladores de ingreso basados en OpenResty

OpenResty es una plataforma web construida sobre NGINX Open Source que incorpora LuaJIT, scripts Lua y módulos NGINX de terceros para ampliar la funcionalidad en NGINX Open Source. A su vez, hay varios controladores de Ingress creados en OpenResty, que creemos que podrían agregar potencialmente dos riesgos en comparación con nuestros controladores de Ingress basados en NGINX Open Source y NGINX Plus:

• Tiempos de espera : como se señaló, OpenResty utiliza scripts de Lua para implementar funciones avanzadas como las de nuestro controlador de ingreso comercial basado en NGINX Plus . Una de estas características es la reconfiguración dinámica, que elimina un requisito de código abierto de NGINX que reduce la disponibilidad, es decir, que la configuración de NGINX debe volver a cargarse cuando cambian los puntos finales del servicio. Para lograr una reconfiguración dinámica con OpenResty, el controlador Lua elige a qué servicio ascendente enrutar la solicitud, eliminando así la necesidad de volver a cargar la configuración de NGINX.

  Sin embargo, Lua debe verificar continuamente si hay cambios en los backends, lo que consume recursos. Las solicitudes entrantes tardan más en procesarse, lo que provoca que algunas se detengan, lo que aumenta la probabilidad de tiempos de espera. A medida que se amplía a más usuarios y servicios, la brecha entre la cantidad de solicitudes entrantes por segundo y la cantidad que Lua puede manejar se amplía exponencialmente. La consecuencia es latencia, complejidad y mayores costos.

  Lea Pruebas de rendimiento de controladores de ingreso NGINX en un entorno de nube Kubernetes dinámico para ver cuánta latencia puede agregar Lua.

• Retrasos en la aplicación de parches CVE : en comparación con los controladores de ingreso de NGINX, los parches para CVE inevitablemente tardan más en aparecer en los controladores de ingreso basados en herramientas como OpenResty, que a su vez se basan en NGINX de código abierto. Como describimos en detalle en Mitigación de vulnerabilidades de seguridad de forma rápida y sencilla con NGINX Plus , cuando se descubre una CVE en NGINX, nosotros, como proveedores, generalmente recibimos información antes de que la CVE se divulgue públicamente. Esto nos permite lanzar un parche para NGINX Open Source y NGINX Plus tan pronto como se anuncie el CVE.

  Es posible que las tecnologías basadas en NGINX de código abierto no se enteren de CVE hasta ese momento y, según nuestra experiencia, los parches de OpenResty tienen un retraso significativo con respecto a los nuestros ( cuatro meses en un caso reciente) . Los parches para un controlador de Ingress basado en OpenResty inevitablemente toman aún más tiempo, lo que le da a un actor malicioso una amplia oportunidad de explotar la vulnerabilidad.

Prepare su controlador de ingreso para el futuro

Incluso si recién estás empezando a incursionar en 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 sus necesidades crezcan con el tiempo: infraestructura, seguridad, soporte y multitenencia.

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

Es raro que una organización esté total y permanentemente comprometida con un tipo de entorno. Lo más común es que las organizaciones tengan una combinación de instalaciones locales y en la nube, que pueden incluir nubes privadas, públicas, híbridas y multinube. (Para profundizar en las diferencias entre estos entornos, lea ¿Cuál es la diferencia entre nube múltiple y nube híbrida? ).

Como mencionamos en la Parte 1 de esta serie, es tentador elegir herramientas que vienen predeterminadas con cada entorno, pero hay una serie de problemas específicos de los controladores Ingress predeterminados. Cubriremos todas las desventajas en la Parte 3 de la serie, pero el problema que es más relevante para la preparación para el futuro es el bloqueo del proveedor: no se puede usar un controlador de Ingress específico de la nube en todos los entornos. El uso de herramientas específicas de la nube predeterminadas afecta su capacidad de escalar porque solo le quedan dos alternativas poco atractivas:

1. Intente hacer que la nube existente funcione para todas sus necesidades
2. Reescriba todas sus configuraciones, no solo el equilibrio de carga, sino también la seguridad, para el controlador de Ingress en cada nuevo entorno.

Si bien la primera alternativa a menudo no es viable por razones comerciales, la segunda también es complicada porque provoca una proliferación de herramientas, abre nuevas vulnerabilidades de seguridad y requiere que los empleados superen curvas de aprendizaje pronunciadas. La tercera alternativa, y la más eficiente, es elegir un controlador de Ingress independiente de la infraestructura desde el principio, lo que le permitirá utilizar la misma herramienta en todos sus entornos.

Cuando se trata de infraestructura, hay otro elemento a considerar: las certificaciones. Utilicemos el ejemplo de Red Hat OpenShift Container Platform (OCP). Si es usuario de OCP, probablemente ya sepa que Red Hat Marketplace ofrece operadores certificados para OCP, incluido el operador de ingreso NGINX . Los estándares de certificación de Red Hat le brindan tranquilidad al saber que la herramienta funciona con su implementación e incluso puede incluir soporte conjunto de Red Hat y el proveedor. Muchas organizaciones tienen requisitos para utilizar herramientas certificadas por razones de seguridad y estabilidad, por lo que incluso si ahora solo está en pruebas, vale la pena tener en cuenta los requisitos de su empresa para los entornos de producción.

Seguridad: ¿Cómo protegerá Kubernetes desde adentro?

Atrás quedaron los días en que la seguridad perimetral por sí sola era suficiente para mantener las aplicaciones y los clientes seguros. Las aplicaciones de Kubernetes están mejor protegidas cuando la seguridad, incluida la autenticación y la autorización, está cerca de las aplicaciones. Y como las organizaciones exigen cada vez más el cifrado de extremo a extremo y adoptan un modelo de red de confianza cero dentro de Kubernetes, una malla de servicios podría estar en su futuro.

¿Qué tiene todo esto que ver con tu controlador Ingress? ¡Mucho! Centralizar la seguridad (autenticación, autorización, protección DoS, firewall de aplicação web) en el punto de ingreso tiene mucho sentido desde el punto de vista de los costos y la eficiencia. Y si bien la mayoría de las mallas de servicio se pueden integrar con la mayoría de los controladores de Ingress, la forma en que se integran es muy importante. Un controlador de Ingress que se alinee con su estrategia de seguridad puede evitar grandes dolores de cabeza durante todo el proceso de desarrollo de su aplicación.

Lea Cómo proteger aplicaciones nativas de la nube sin perder velocidad para obtener más detalles sobre los riesgos de la entrega de aplicaciones nativas de la nube e Implementación de servicios de aplicação en Kubernetes, parte 2 para conocer más sobre los factores que determinan la mejor ubicación para las herramientas de seguridad.

Apoyo – ¿Hasta qué punto puedes permitirte estar “solo”?

Cuando los equipos recién están experimentando con Kubernetes, el soporte (ya sea de la comunidad o de una empresa) a menudo no es la máxima prioridad. Esto está bien si sus equipos tienen mucho tiempo para encontrar sus propias soluciones y alternativas, pero no es sostenible cuando se pasa a producción. Incluso si no necesita soporte hoy, puede ser una buena idea elegir un controlador Ingress que le permita agregar soporte en el futuro o que tenga un nivel de soporte económico que pueda actualizarse a medida que escala.

Multi-tenencia: ¿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 empieza cada historia? La historia a menudo continúa con ese equipo que desarrolló con éxito su única aplicación de Kubernetes, lo que llevó 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 tecnología multitenencia y adoptan un modelo Kubernetes que admite el acceso y el aislamiento exigidos por sus procesos de negocios y, al mismo tiempo, proporciona la tranquilidad y los controles que necesitan sus operadores. Algunos controladores de Ingress pueden ayudarle a dividir esos clústeres a través de una serie de características y conceptos: múltiples ingresos, clases, espacios de nombres y recursos con alcance que admiten la configuración de controles de acceso basados en roles (RBAC).

Próximo paso: Reducir las opciones

Ahora que ha pensado en sus requisitos, su tolerancia al riesgo y su preparación para el futuro, tiene suficiente información para comenzar a limitar el amplio campo de controladores de Ingress. Dividir ese campo por categoría puede ayudarle a realizar rápidamente este paso. En la Parte 3 de nuestra serie, exploraremos tres categorías diferentes de controladores de Ingress, incluidos los pros y los contras de cada uno.