Guía para elegir un controlador de Ingress, parte 1: identifica tus requisitos

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 (esta publicación)
6. Guía para elegir un controlador de Ingress, parte 2: riesgos y preparación para el futuro
7. Guía para elegir un controlador de Ingress, parte 3: código abierto frente a opción predeterminada frente a solución 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 de entrada 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».

Cuando las organizaciones empiezan a experimentar con Kubernetes, no suelen prestar demasiada atención a la elección de un controlador de Ingress. Puede que piensen que todos los controladores de Ingress son iguales y que, para ponerse en marcha rápidamente, lo más sencillo es utilizar el controlador de Ingress predeterminado del entorno de Kubernetes que hayan elegido. Y es cierto que prácticamente cualquier controlador de Ingress resulta adecuado para entornos de pruebas o de producción con poco volumen. Sin embargo, a medida que se escala, la elección del controlador de Ingress cobra mayor importancia. Esto se debe a que los controladores de Ingress pueden ofrecer mucho más que la funcionalidad básica de trasladar el tráfico del punto A al punto B.

Desde la gestión avanzada del tráfico hasta la observabilidad y la seguridad integrada, un controlador Ingress puede ser una de las herramientas más potentes de su stack de Kubernetes. De hecho, en F5 NGINX lo consideramos la base de cualquier implementación de Kubernetes apta para producción. Sin embargo, muchos desarrolladores y equipos de operaciones de plataforma no son conscientes de todo el potencial de un controlador Ingress ni de las consecuencias de elegir uno que no pueda escalar. Elegir un controlador Ingress que no escale bien o no proteja entornos complejos puede impedirle llevar Kubernetes de las pruebas a la producción. En esta serie de artículos del blog, nuestro objetivo es explicarle los fundamentos de los controladores Ingress y cómo tomar una decisión acertada que le proporcione la funcionalidad y la seguridad que necesita, tanto hoy como en el futuro.

¿Qué es un controlador de Ingress?

Un controlador de Ingress es un balanceador de carga especializado que gestiona el tráfico de las capas 4 y 7 que entra en los clústeres de Kubernetes y, potencialmente, el tráfico que sale de ellos. Para asegurarnos de que todos hablamos de lo mismo, estos son los términos que utilizamos en NGINX (y que son, en gran medida, los mismos en todo el sector):

• Tráfico de entrada – Tráfico que entra en un clúster de Kubernetes
• Tráfico de salida – Tráfico que sale de un clúster de Kubernetes
• Tráfico norte-sur – Tráfico que entra y sale de un clúster de Kubernetes (también denominado tráfico de entrada-salida)
• Tráfico este-oeste – Tráfico que circula entre servicios dentro de un clúster de Kubernetes (también denominado tráfico servicio a servicio)
• Malla de servicios – Una herramienta de gestión del tráfico para enrutar y proteger el tráfico entre servicios

¿Por qué necesita un controlador de Ingress?

De forma predeterminada, las aplicaciones que se ejecutan en pods (contenedores) de Kubernetes no son accesibles desde la red externa, sino únicamente desde otros pods del clúster de Kubernetes. Kubernetes cuenta con un objeto de configuración integrado para el balanceo de carga HTTP denominado «Ingress», que define cómo pueden conectarse las entidades externas a un clúster de Kubernetes con los pods representados por uno o varios servicios de Kubernetes.

Cuando necesite proporcionar acceso externo a sus servicios de Kubernetes, debe crear un recurso Ingress para definir las reglas de conectividad, incluida la ruta del URI, el nombre del servicio de backend y otra información. Sin embargo, el recurso Ingress no hace nada por sí solo. Debe implementar y configurar una aplicación de controlador Ingress (mediante la API de Kubernetes) para aplicar las reglas definidas en los recursos Ingress.

¿Qué hace un controlador de Ingress?

• Accepts traffic from outside the Kubernetes environment, potentially modify (shape) it, and distribute it to pods running inside the environment. The Ingress controller replaces the default kube-proxy traffic distribution model, giving you additional controls like those that application delivery controllers (ADCs) and reverse proxies provide in non‑Kubernetes environments.
• Supervisa los pods individuales de un servicio, lo que garantiza un enrutamiento inteligente y evita que las solicitudes acaben en un «agujero negro».
• Implementa reglas de salida para reforzar la seguridad mediante TLS mutuo (mTLS) o limitar el tráfico saliente de determinados pods a servicios externos específicos.

A la hora de elegir un controlador de Ingress, puede resultar tentador empezar por una lista de funcionalidades, pero podría acabar eligiendo uno con prestaciones fantásticas que no satisfaga las necesidades de su empresa. En su lugar, asegúrese de analizar dos aspectos que influyen en la eficacia del controlador de Ingress para su equipo y sus aplicaciones: los casos de uso (qué problemas resolverá) y los recursos (cómo va a «pagarlo»). Abordaremos estos dos temas en el resto de este artículo.

¿Qué problemas quieres que resuelva el controlador de Ingress?

El principal caso de uso de un controlador Ingress es la gestión del tráfico, por lo que probablemente querrá que el controlador Ingress se encargue de uno o varios de estos casos de uso habituales:

• Equilibrado de carga (HTTP2, HTTP/HTTPS, terminación SSL/TLS, TCP/UDP, WebSocket, gRPC)
• Control del tráfico (limitación de velocidad, interrupción de circuitos, comprobaciones de estado activas)
• División del tráfico (enrutamiento de depuración, pruebas A/B, despliegues canary y despliegues blue-green)

Pero no hay razón para conformarse con una solución que solo sirve para una cosa: la mayoría de los controladores Ingress pueden hacer mucho más que gestionar el tráfico. Al utilizar el controlador Ingress para resolver varios problemas, no solo se reducen el tamaño y la complejidad de la pila, sino que también se pueden trasladar los requisitos no funcionales de las aplicaciones al controlador Ingress. Veamos cuatro casos de uso no tradicionales de los controladores Ingress que pueden ayudar a que los despliegues de Kubernetes sean más seguros, ágiles y escalables, al tiempo que se aprovechan los recursos de forma más eficiente.

Monitorización y visibilidad

La falta de visibilidad del clúster de Kubernetes es uno de los mayores retos en los entornos de producción, ya que dificulta la resolución de problemas y la resiliencia. Dado que los controladores Ingress operan en el perímetro de los clústeres de Kubernetes y gestionan todo el tráfico, se encuentran en una posición idónea para proporcionar datos que ayuden a diagnosticar (e incluso evitar) dos problemas habituales: la lentitud de las aplicaciones y el agotamiento de los recursos del clúster o de la plataforma de Kubernetes. Para mejorar la visibilidad, un controlador Ingress debe:

• Proporcionar métricas en tiempo real para que pueda diagnosticar lo que está sucediendo «ahora mismo»
• Permitir exportar métricas a herramientas de observabilidad populares, como Prometheus y Grafana, que representan los valores a lo largo del tiempo para ayudarle a predecir picos de tráfico y otras tendencias

Puerta de enlace de API

A menos que necesites manipular las solicitudes y respuestas en Kubernetes, es muy probable que el controlador Ingress también pueda actuar como gateway de API. En función de sus características, un controlador Ingress podría proporcionar funciones esenciales de un gateway de API, como la terminación TLS, la autenticación de clientes, la limitación de la tasa de solicitudes, el control de acceso granular y el enrutamiento de solicitudes en las capas 4 a 7.

Autenticación e inicio de sesión único

Delegar la autenticación de las credenciales de inicio de sesión de sus servicios de Kubernetes a su controlador Ingress puede resolver dos problemas.

• Permita que los usuarios inicien sesión en varias aplicaciones con un único conjunto de credenciales mediante la implementación del inicio de sesión único (SSO) con OpenID Connect (OIDC).
• Elimine la necesidad de desarrollar funcionalidades de autenticación en cada aplicación, lo que permitirá a sus desarrolladores centrarse en la lógica de negocio de sus aplicaciones.

Integración con un firewall de aplicaciones web

No se trata de que un controlador de Ingress pueda actuar como firewall de aplicaciones web (WAF), sino de que el WAF puede integrarse con el controlador de Ingress. Aunque un WAF puede implementarse en muchos puntos tanto dentro como fuera de Kubernetes, para la mayoría de las organizaciones la ubicación más eficiente y eficaz es en el mismo pod que el controlador de Ingress. Este caso de uso es ideal cuando las políticas de seguridad están bajo la dirección de SecOps o DevSecOps y se necesita un enfoque granular por servicio o por URI. Esto permite utilizar la API de Kubernetes para definir políticas y asociarlas a servicios. Además, la funcionalidad de control de acceso basado en roles (RBAC) del controlador de Ingress puede permitir que SecOps aplique políticas por listener, mientras que los usuarios de DevOps establecen políticas por recurso de Ingress.

¿Cómo va a asignar recursos al controlador de Ingress?

Todos los controladores Ingress tienen un coste, incluso los que son gratuitos y de código abierto (quizá haya oído la expresión «gratis como un cachorro»). Algunos costes pueden asignarse a importes previsibles como partidas de su presupuesto, mientras que otros dependen del tiempo que su equipo tenga que dedicar a afrontar las consecuencias de elegir un controlador Ingress u otro (mayor complejidad, falta de portabilidad, etc.). Veamos los costes, tanto en tiempo como en dinero, que debe tener en cuenta al elaborar el presupuesto para un controlador Ingress.

Presupuestar los costes de tiempo

Presupuestar los costes de personal puede ser mucho más complicado que hacerlo para partidas de costes fijos, especialmente cuando se intenta dotar de recursos a un proyecto en un ámbito desconocido. Es necesario plantearse preguntas como:

• ¿Quién configurará y administrará el controlador Ingress? ¿Forma parte de su trabajo a tiempo completo (por ejemplo, como miembros del equipo de Operaciones de Plataforma) o lo asumirán como una responsabilidad adicional (como desarrolladores)?
• ¿Puede reservar tiempo para que los empleados reciban formación reglada? ¿O la herramienta debe ser lo bastante sencilla como para aprender a utilizarla rápida y fácilmente en el trabajo?
• ¿Está dispuesto a que sus empleados tengan que trastear con la herramienta cada vez que se necesite una nueva función o a que dediquen mucho tiempo a solucionar problemas cuando surjan? ¿O necesita que aporten valor al negocio de otras formas?

Una nota sobre la responsabilidad de las herramientas de Kubernetes

Hemos observado una tendencia en el sector a consolidar las herramientas y su gestión bajo la responsabilidad de los equipos de NetOps. Aunque esto puede contribuir en gran medida a simplificar la pila tecnológica y mejorar la seguridad, abogamos por una duplicación meditada de las herramientas en función de los objetivos de cada equipo. Tiene sentido que el equipo de NetOps gestione las herramientas perimetrales (como los balanceadores de carga externos), ya que se centra en la plataforma en su conjunto; sin embargo, a los equipos de DevOps les preocupan sobre todo los servicios desplegados cerca del código de la aplicación y necesitan más agilidad y un control más granular del que ofrecen las herramientas de NetOps. Las herramientas de Kubernetes, incluido el controlador Ingress, tienen más probabilidades de funcionar correctamente cuando las selecciona el equipo de DevOps. ¡Eso no significa que deba concederse a los desarrolladores total libertad para elegir las herramientas! Una cierta estandarización drástica de las herramientas dentro de Kubernetes sigue siendo una práctica recomendada.

Presupuestación de los costes de capital

Cuando las organizaciones empiezan a experimentar con Kubernetes, no suelen destinar mucho presupuesto a herramientas o soporte. Si dispone de los recursos humanos necesarios para mantener adecuadamente un controlador de Ingress que requiere más «atención», puede prescindir de un presupuesto económico… al principio. Sin embargo, a medida que aumenta su inversión en Kubernetes, puede verse limitado por las funcionalidades de la herramienta o preferir que su equipo se dedique a otras prioridades. Es entonces cuando la balanza se inclina a favor de pagar por una herramienta más fácil de usar y estable, con funcionalidades y soporte para empresas.

Cuando esté listo para pagar por un controlador de Ingress, tenga en cuenta que el modelo de licencias es importante. Siguiendo los modelos de precios tradicionales ajenos a Kubernetes, el precio de los controladores de Ingress suele establecerse «por instancia» o «por proxy de Ingress». Aunque hay casos de uso en los que esto sigue teniendo sentido en Kubernetes, optar por una licencia de controlador de Ingress «por clúster» significa que se paga en función de la tenencia de las aplicaciones, en lugar de por el «número de proxies».

Estas son nuestras recomendaciones para distintos escenarios:

• ¿Es la primera vez que utiliza Kubernetes? Elija una licencia por clúster.
  Si no tiene experiencia con Kubernetes, es muy difícil predecir con precisión cuántas instancias del controlador Ingress necesita. Si se ve obligado a elegir un número de instancias, puede quedarse corto —lo que dificultaría la consecución de sus objetivos— o excederse y malgastar dinero que podría invertir mejor en otras partes del proyecto de Kubernetes. Negociar un precio fijo relativamente bajo para un «clúster pequeño» aumenta sus probabilidades de éxito.
• ¿Necesita escalar Kubernetes? Elija las licencias por clúster.
  Es prácticamente imposible predecir cuánto y con qué frecuencia tendrá que aumentar o reducir los recursos de Kubernetes (expansión y contracción). Los precios por instancia obligan a su equipo a establecer umbrales arbitrarios para no superar los límites de las licencias. Con las licencias por clúster, no tiene que realizar un seguimiento de cada contenedor de Ingress y, según el proveedor (como NGINX), la expansión puede estar incluida sin coste adicional.
• ¿Despliegues avanzados o estáticos? Elija licencias por instancia.
  Si tiene suficiente experiencia con Kubernetes para saber exactamente cómo va a utilizar el controlador de Ingress, tiene previsto utilizar un número reducido de proxies de Ingress por clúster y no necesita ninguno de los servicios incluidos que pueda ofrecer la herramienta, el modelo de precios por instancia puede ser una excelente opción.

Próximos pasos: tolerancia al riesgo y preparación para el futuro

Ahora que ya conoce bien sus requisitos, el siguiente paso es decidir en equipo qué nivel de tolerancia tienen ante los riesgos que podría introducir un controlador Ingress y determinar cómo deberá escalar dicho controlador a medida que crezca su despliegue de Kubernetes. Abordamos estos temas en la parte 2.

Sobre el autor

Jenn GileResponsable de Marketing de Producto, NGINX

Más artículos de Jenn Gile