Guía para elegir un controlador de entrada, parte 1: Identifique sus requisitos

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 (esta publicación)
6. Guía para elegir un controlador de entrada, parte 2: Riesgos y preparación para el futuro
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 .

Cuando las organizaciones comienzan a experimentar con Kubernetes, a menudo no piensan mucho en la elección del controlador de ingreso . Es posible que piensen que todos los controladores de Ingress son iguales y que, para comenzar a funcionar rápidamente, es más fácil seguir con el controlador de Ingress predeterminado para el marco de Kubernetes que eligieron. Y es cierto que prácticamente cualquier controlador Ingress funciona bien en entornos de prueba o de producción de bajo volumen. Pero a medida que escala, la elección del controlador Ingress se vuelve más importante. Esto se debe a que los controladores de Ingress pueden proporcionar mucho más que la funcionalidad básica de mover su tráfico del punto A al punto B.

Desde la gestión avanzada del tráfico hasta la visibilidad y la seguridad integrada, un controlador de Ingress puede ser una de las herramientas más poderosas en su pila de Kubernetes. De hecho, en F5 NGINX lo consideramos la base de cualquier implementación de Kubernetes de nivel de producción . Pero muchos desarrolladores y equipos de operaciones de plataforma no se dan cuenta del poder total de un controlador de Ingress ni de las consecuencias de elegir uno que no pueda escalar. Elegir un controlador de Ingress que no se escale bien o que no proteja entornos complejos puede impedirle sacar Kubernetes de las pruebas y llevarlo a producción. En esta serie de blogs, nuestro objetivo es educarlo sobre los conceptos básicos de los controladores Ingress y cómo hacer una elección inteligente que ofrezca la funcionalidad y la seguridad que necesita, hoy y mañana.

¿Qué es un controlador de ingreso?

Un controlador de ingreso es un balanceador de carga especializado que administra el tráfico de capas 4 y 7 que ingresa a los clústeres de Kubernetes y, potencialmente, el tráfico que sale de ellos. Para que estemos todos en la misma página, aquí están los términos que usamos en NGINX (y son en gran medida los mismos en toda la industria):

• Tráfico de entrada : tráfico que ingresa a 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 llamado tráfico de entrada y salida )
• Tráfico este-oeste : tráfico que se mueve entre servicios dentro de un clúster de Kubernetes (también llamado tráfico de servicio a servicio )
• Malla de servicios : una herramienta de gestión de tráfico para enrutar y proteger el tráfico entre servicios

¿Por qué necesita un controlador de ingreso?

De forma predeterminada, las aplicações que se ejecutan en pods (contenedores) de Kubernetes no son accesibles desde la red externa, sino solo desde otros pods dentro del clúster de Kubernetes. Kubernetes tiene un objeto de configuración integrado para el equilibrio de carga HTTP, llamado Ingress , que define cómo las entidades fuera de un clúster de Kubernetes pueden conectarse a los pods representados por uno o más servicios de Kubernetes.

Cuando necesita proporcionar acceso externo a sus servicios de Kubernetes, crea un recurso de Ingress para definir las reglas de conectividad, incluida la ruta URI, el nombre del servicio de respaldo y otra información. Sin embargo, por sí solo, el recurso Ingress no hace nada. Debe implementar y configurar una aplicação de controlador de Ingress (usando la API de Kubernetes) para implementar las reglas definidas en los recursos de Ingress.

¿Qué hace un controlador de ingreso?

• Acepta tráfico desde fuera del entorno de Kubernetes, potencialmente lo modifica (le da forma) y lo distribuye a los pods que se ejecutan dentro del entorno. El controlador de Ingress reemplaza el modelo de distribución de tráfico predeterminado de kube-proxy , lo que le brinda controles adicionales como los que brindan los controladores de entrega de aplicação (ADC) y los proxies inversos en entornos que no son Kubernetes.
• Monitorea los pods individuales de un servicio, garantizando un enrutamiento inteligente y evitando que las solicitudes queden “ bloqueadas ”.
• Implementa reglas de salida para mejorar la seguridad con TLS mutuo (mTLS) o limitar el tráfico saliente desde ciertos pods a servicios externos específicos.

A la hora de seleccionar un controlador Ingress, puede resultar tentador comenzar con una lista de características, pero podría terminar con un controlador Ingress que tenga características fantásticas pero que no satisfaga las necesidades de su negocio. En su lugar, asegúrese de explorar dos elementos que inciden en el buen funcionamiento del controlador Ingress para su equipo y sus aplicaciones: casos de uso (qué problemas resolverá) y recursos (cómo va a "pagar" por ello). Cubriremos estos dos temas en el resto de este blog.

¿Qué problemas desea que resuelva el controlador de ingreso?

El caso de uso principal de un controlador de Ingress es la gestión del tráfico, por lo que probablemente desee que el controlador de Ingress maneje uno o más de estos casos de uso comunes:

• Equilibrio de carga (HTTP2, HTTP/HTTPS, terminación SSL/TLS, TCP/UDP, WebSocket, gRPC)
• Control de tráfico (limitación de velocidad, interrupción de circuitos, controles de estado activos)
• División de tráfico (enrutamiento de depuración, pruebas A/B, implementaciones canarias, implementaciones azul-verde)

Pero no hay motivo para conformarse con un sistema que solo sirva para un único propósito: la mayoría de los controladores de Ingress pueden hacer más que gestionar el tráfico. Al usar el controlador Ingress para resolver múltiples problemas, no solo reduce el tamaño y la complejidad de su pila, sino que también puede descargar requisitos no funcionales de las aplicaciones al controlador Ingress. Veamos cuatro casos de uso de controladores de Ingress no tradicionales que pueden ayudar a que sus implementaciones de Kubernetes sean más seguras, ágiles y escalables, al tiempo que hacen un uso más eficiente de sus recursos.

Supervisión y visibilidad

La falta de visibilidad en el clúster de Kubernetes es uno de los mayores desafíos en los entornos de producción y contribuye a dificultar la resolución de problemas y la resiliencia. Debido a que los controladores de Ingress operan en el borde de sus clústeres de Kubernetes y tocan cada bit de tráfico, están bien posicionados para proporcionar datos que pueden ayudarlo a solucionar (e incluso evitar) dos problemas comunes: aplicaciones lentas y agotamiento de recursos en el clúster o plataforma de Kubernetes. Para que el controlador de Ingress mejore la visibilidad, necesita:

• Proporciona métricas en tiempo real para que puedas diagnosticar lo que está sucediendo "ahora mismo"
• Poder exportar métricas a herramientas de visibilidad populares, como Prometheus y Grafana, que trazan valores a lo largo del tiempo para ayudarlo a predecir picos de tráfico y otras tendencias.

Puerta de enlace de API

A menos que desees realizar una manipulación de solicitud-respuesta en Kubernetes, es muy probable que el controlador de Ingress pueda funcionar también como tu puerta de enlace de API. Dependiendo de su conjunto de características, un controlador de Ingress podría proporcionar funciones básicas de API, incluidas terminación TLS, autenticación de cliente, limitación de velocidad, control de acceso detallado y enrutamiento de solicitudes en las capas 4 a 7.

Autenticación e inicio de sesión único

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

• Permita que los usuarios inicien sesión en múltiples aplicaciones con un único conjunto de credenciales implementando el inicio de sesión único (SSO) con OpenID Connect (OIDC).
• Elimina la necesidad de incorporar funciones de autenticación en cada aplicação, lo que permite a tus desarrolladores centrarse en la lógica empresarial de sus aplicaciones.

Integración de firewall de aplicação web

No es que un controlador de Ingress pueda servir como un firewall de aplicação web (WAF), sino que el WAF se puede consolidar con el controlador de Ingress. Si bien un WAF se puede implementar en muchos lugares fuera y dentro de Kubernetes, para la mayoría de las organizaciones la ubicación más eficiente y efectiva es en el mismo pod que el controlador de Ingress. Este caso de uso es perfecto cuando las políticas de seguridad están bajo la dirección de SecOps o DevSecOps y cuando se necesita un enfoque detallado por servicio o por URI. Significa que puedes usar la API de Kubernetes para definir políticas y asociarlas con 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 cada oyente mientras los usuarios de DevOps establecen políticas por recurso de Ingress.

¿Cómo va a dotar de recursos al controlador de ingreso?

Cada controlador de Ingress tiene un costo… incluso aquellos que son gratuitos y de código abierto (quizás hayas escuchado la frase “gratis como un cachorro”). A algunos costos se les pueden asignar montos en dólares predecibles como partidas en su presupuesto, mientras que otros dependen de cuánto tiempo su equipo tenga que dedicar a lidiar con las consecuencias del controlador de Ingress que elija (mayor complejidad, falta de portabilidad, etc.). Veamos los costos, en términos de tiempo y dinero, a tener en cuenta al presupuestar un controlador Ingress: tiempo y dinero.

Presupuesto de costos de tiempo

La elaboración de un presupuesto para el número de personal puede ser mucho más compleja que la de partidas con costes fijos, especialmente cuando se intenta conseguir recursos para un proyecto en un espacio desconocido. Necesitas hacer preguntas como:

• ¿Quién configurará y administrará el controlador Ingress? ¿Es parte de su trabajo de tiempo completo (por ejemplo, como miembros de su equipo de operaciones de plataforma) o lo asumen como una responsabilidad adicional (como desarrolladores)?
• ¿Puede usted dedicar tiempo para que los empleados reciban capacitación formal? ¿O la herramienta debe ser lo suficientemente sencilla para poder aprenderla rápida y fácilmente en el trabajo?
• ¿Está preparado para que los empleados lo modifiquen cada vez que se necesite una nueva característica o para que dediquen mucho tiempo a solucionar problemas cuando hay un problema? ¿O necesita que aporten otro valor comercial?

Una nota sobre la propiedad de las herramientas de Kubernetes

Hemos observado una tendencia en la industria hacia la consolidación de herramientas y propiedad bajo el dominio de los equipos de NetOps. Si bien esto puede ayudar mucho a simplificar su pila y mejorar la seguridad, recomendamos una duplicación cuidadosa de herramientas en función de los objetivos del equipo . Tiene sentido que el equipo de NetOps administre las herramientas perimetrales (como los balanceadores de carga externos) porque se enfocan en la plataforma más amplia, pero los equipos de DevOps se preocupan más por los servicios implementados cerca del código de la aplicación y necesitan más agilidad y un control más detallado del que obtienen de las herramientas de NetOps. Las herramientas de Kubernetes, incluido el controlador Ingress, tienen mayores posibilidades de éxito cuando son seleccionadas por DevOps. ¡Eso no quiere decir que debamos conceder a los desarrolladores total libertad para elegir las herramientas! Una cierta estandarización brutal de las herramientas dentro de Kubernetes sigue siendo una buena práctica.

Presupuesto de costos de capital

Cuando las organizaciones experimentan por primera vez con Kubernetes, a menudo no destinan mucho presupuesto a herramientas o soporte. Si tienes los recursos humanos necesarios para dar soporte real a un controlador Ingress que necesita más “asistencia”, entonces no hay presupuesto monetario suficiente… al principio. Pero a medida que aumenta su inversión en Kubernetes, es posible que se sienta limitado por las características de la herramienta o que desee dedicar su equipo a otras prioridades. Ahí es cuando la balanza se inclina hacia el pago de una herramienta más estable y fácil de usar , con funciones y soporte empresariales.

Cuando esté listo para pagar por un controlador Ingress, tenga en cuenta que el modelo de licencia es importante. Según los modelos de precios tradicionales fuera de Kubernetes, el precio de los controladores de Ingress suele ser "por instancia" o "por proxy de Ingress". Si bien hay casos de uso en los que esto todavía tiene sentido en Kubernetes, obtener una licencia para un controlador de Ingress "por clúster" significa que se paga en función de la tenencia de la aplicação en lugar de por "la cantidad de servidores proxy".

Aquí están nuestras recomendaciones para diferentes escenarios:

• ¿Eres nuevo en Kubernetes? Elija la licencia por clúster.
  Cuando no tienes experiencia con Kubernetes, es muy difícil predecir con precisión la cantidad de instancias del controlador de Ingress que necesitas. Si se ve obligado a elegir una cantidad de instancias, puede subestimarlas (lo que dificultaría el logro de sus objetivos) o sobreestimarlas y desperdiciar dólares que podrían emplearse mejor en otras partes del proyecto Kubernetes. Negociar un precio fijo relativamente bajo para un “grupo pequeño” aumenta sus posibilidades de éxito.
• ¿Escalar Kubernetes? Elija la licencia por clúster.
  Es casi imposible predecir cuánto y con qué frecuencia necesitarás escalar los recursos de Kubernetes hacia arriba y hacia abajo (explosiones y colapsos). El precio por instancia obliga a su equipo a imponer umbrales arbitrarios para mantenerse dentro de los límites de licencia. Con licencias por clúster, no es necesario realizar un seguimiento de contenedores Ingress individuales y, según el proveedor (como NGINX), la expansión puede estar incluida sin costo adicional.
• ¿Implementaciones avanzadas o estáticas? Elija licencia por instancia.
  Si tiene suficientes conocimientos de Kubernetes para saber exactamente cómo va a utilizar el controlador de Ingress, y planea utilizar una pequeña cantidad de servidores proxy de Ingress por clúster y no necesita ningún servicio incluido que pueda venir junto con la herramienta, entonces el precio por instancia puede ser una excelente opción.

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

Ahora que tiene una idea de sus requisitos, el siguiente paso es decidir en equipo cuál es su tolerancia a los riesgos que un controlador de Ingress podría introducir y determinar cómo necesitará que el controlador de Ingress escale a medida que crece su implementación de Kubernetes. Abordaremos estos temas en la Parte 2 .