Editor : Esta publicación es parte de una serie de 10 partes:
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.
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):
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.
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.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.
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:
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.
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:
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.
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.
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.
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.
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:
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.
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:
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 .
"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.