Introducción a las redes de Kubernetes

Brian EhlertDirector de Gestión de Producto

NodePort, LoadBalancer, controlador de Ingress… ¡madre mía!

Cuando hablamos con clientes y con la comunidad sobre cómo preparar Kubernetes para entornos de producción, una de las preguntas más habituales es: ¿necesito un controlador Ingress? La respuesta rara vez se reduce a un simple sí o no, sino que requiere conocer las distintas formas de dirigir el tráfico a los pods. En este artículo explicamos los fundamentos de las redes de Kubernetes para que puedas tomar una decisión informada sobre si necesitas un controlador Ingress y cuándo.

Kubernetes admite varios enfoques y capas posibles para enrutar el tráfico externo a un pod, pero no todos son iguales. El modelo predeterminado es kube-proxy, que en realidad no es un proxy ni está diseñado para equilibrar el tráfico, controlar las API o supervisar el comportamiento de los servicios.

Afortunadamente, hay otras formas de gestionar el tráfico externo, pero antes de continuar, repasemos brevemente los componentes de Kubernetes:

• Los despliegues de Kubernetes están formados por nodos, que son máquinas físicas o virtuales.
• Los nodos se unen para formar un clúster.
• Cada clúster gestiona pods, que son la unidad mínima común en el ámbito de las redes y la infraestructura de Kubernetes. Uno o varios pods forman un servicio.
• Dentro de cada pod se alojan uno o varios contenedores (dependiendo del tamaño de la aplicación).

Kubernetes supervisa los pods que componen un servicio y los escala según sea necesario para adaptarse a los requisitos de la aplicación. Pero ¿cómo se dirige el tráfico a los pods? Aquí es donde entran en juego dos tipos de objetos de Kubernetes: los servicios y los controladores de Ingress.

¿Qué es un servicio de Kubernetes?

Según la documentación de Kubernetes, un servicio es «una forma abstracta de exponer una aplicación que se ejecuta en un conjunto de pods». Un servicio conecta pods en un clúster o una red de contenedores de modo que su ubicación en un nodo concreto no sea relevante. Esto permite dirigir el tráfico externo a pods específicos aunque cambien de ubicación o incluso cuando se destruyan y se reinicien. De este modo, un servicio funciona de forma muy similar a un proxy inverso muy básico.

Existen varios tipos de servicios y de objetos de servicio relacionados con el enrutamiento del tráfico externo hacia Kubernetes. A menudo se confunden entre sí, pero en realidad cada uno cumple funciones muy distintas, por lo que conviene repasar sus funciones, usos e inconvenientes.

ClusterIP

ClusterIP es el servicio predeterminado que proporciona un servicio dentro de Kubernetes al que pueden acceder otros servicios del clúster. No se puede acceder a él desde fuera del clúster. La única forma de exponer un servicio ClusterIP es utilizar algo como kube-proxy, pero hay pocos casos en los que esto tenga sentido. Algunos ejemplos concretos son acceder a un servicio desde un portátil, depurar un servicio o consultar datos de supervisión y métricas.

NodePort

Un servicio NodePort abre un puerto específico en cada nodo del clúster y reenvía todo el tráfico enviado al nodo a través de ese puerto a la aplicación correspondiente. Esta es una forma muy básica de dirigir tráfico a sus aplicaciones y presenta muchas limitaciones en casos de uso reales de gestión del tráfico. Solo puede haber un servicio por cada NodePort y únicamente se pueden utilizar puertos del intervalo comprendido entre el 30000 y el 32767. Aunque 2768 puertos puedan parecer muchos, las organizaciones que ejecutan Kubernetes a gran escala los agotarán rápidamente. Además, NodePort utiliza reglas de enrutamiento de capa 4 y la utilidad de Linux iptables, lo que limita el enrutamiento de capa 7.

Además de las limitaciones de enrutamiento, el uso de NodePort presenta otros tres grandes inconvenientes:

• Los clientes descendentes deben conocer la dirección IP de cada nodo para conectarse a él; esto resulta problemático si cambia la dirección IP del nodo o el host de la máquina virtual.
• NodePort no puede redirigir el tráfico a varias direcciones IP.
• Como se muestra en el diagrama, NodePort no proporciona equilibrio de carga dentro de los clústeres de Kubernetes, por lo que el tráfico se distribuye aleatoriamente entre los servicios. Esto puede provocar la sobrecarga de los servicios y el agotamiento de los puertos.
  

LoadBalancer

Un servicio LoadBalancer acepta tráfico externo, pero requiere un balanceador de carga externo que actúe como interfaz para dicho tráfico. Esto permite el enrutamiento de capa 7 (a las direcciones IP de los pods), siempre que el balanceador de carga externo esté correctamente ajustado y reconfigurado para dirigir el tráfico a los pods en ejecución. LoadBalancer es una de las formas más populares de exponer servicios al exterior. Se utiliza principalmente en plataformas en la nube y es una buena opción para despliegues pequeños y estáticos.

Si utiliza un servicio de Kubernetes gestionado, obtendrá automáticamente el balanceador de carga seleccionado por el proveedor de la nube. Por ejemplo, en Google Cloud Platform puede poner en marcha un balanceador de carga de red mediante el tipo de servicio LoadBalancer, mientras que el balanceador de carga de aplicaciones (ALB) es la opción predeterminada en AWS. Cada servicio que exponga obtiene su propia dirección IP pública, que reenvía todo el tráfico, pero sin ningún tipo de filtrado ni enrutamiento, lo que significa que puede enviar casi cualquier tipo de tráfico (HTTP, TCP/UDP, WebSocket, etc.). Como alternativa, si no desea utilizar las herramientas del proveedor de la nube —por ejemplo, si necesita más funcionalidades o una herramienta independiente de la plataforma—, puede sustituirlas por una solución como F5 BIG-IP (como balanceador de carga externo) y F5 Container Ingress Services (como operador que desempeña la función de LoadBalancer). Para obtener más información sobre este patrón, consulte Implementación de BIG-IP y NGINX Ingress Controller en la misma arquitectura en nuestro blog.

Usar LoadBalancer para exponer sus aplicaciones resulta complicado en entornos dinámicos en los que los pods de las aplicaciones deben escalar para adaptarse a los cambios en la demanda. Como cada servicio obtiene su propia dirección IP, una aplicación popular puede tener cientos —o incluso miles— de direcciones IP que gestionar. En la mayoría de los casos, el balanceador de carga externo se conecta a los servicios mediante NodePort, como se muestra en el siguiente diagrama. Aunque esto garantiza que el tráfico se distribuya uniformemente entre los nodos, sigue sin ser posible balancear la carga entre los servicios, por lo que continúan produciéndose sobrecargas de los servicios y agotamiento de puertos.

¿Qué es un controlador de Ingress de Kubernetes?

Según la documentación de Kubernetes, «los controladores son bucles de control que supervisan el estado del clúster y, a continuación, realizan o solicitan cambios cuando es necesario. Cada controlador intenta acercar el estado actual del clúster al estado deseado». Los controladores se utilizan para gestionar el estado en Kubernetes en numerosas tareas, como asignar correctamente los recursos, designar el almacenamiento persistente y gestionar tareas cron.

En el contexto del enrutamiento, un controlador de Ingress permite superar las limitaciones de NodePort y LoadBalancer.

Un controlador Ingress se utiliza para configurar y gestionar las interacciones externas con los pods que están etiquetados para un servicio específico. Los controladores Ingress están diseñados para tratar el enrutamiento dinámico de capa 7 como una función de primer nivel. Esto significa que ofrecen un control y una gestión mucho más detallados con menos trabajo. Puede utilizar fácilmente un controlador Ingress no solo para controlar el tráfico entrante, sino también para proporcionar métricas de rendimiento a nivel de servicio y como parte de una política de seguridad. Los controladores Ingress incluyen muchas de las funciones de los balanceadores de carga externos tradicionales, como la terminación TLS, la gestión de varios dominios y espacios de nombres y, por supuesto, el balanceo del tráfico. Los controladores Ingress pueden balancear el tráfico por solicitud en lugar de por servicio, lo que ofrece una visión más útil del tráfico de capa 7 y una forma mucho más eficaz de aplicar los SLA.

¡Y hay otra ventaja! Los controladores de Ingress también pueden aplicar reglas de salida que permitan el tráfico saliente de determinados pods únicamente hacia servicios externos específicos, o garantizar que el tráfico se cifre mutuamente mediante mTLS. Exigir mTLS es fundamental para prestar servicios regulados en sectores como la sanidad, las finanzas, las telecomunicaciones y la Administración pública, y constituye un componente clave de una estrategia de cifrado de extremo a extremo (E2EE). Controlar el tráfico saliente desde la misma herramienta también simplifica la aplicación de la lógica de negocio a los servicios. Es mucho más fácil configurar reglas de recursos adecuadas cuando tanto el tráfico de entrada como el de salida están vinculados en el mismo plano de control.

El siguiente diagrama muestra cómo un controlador de Ingress reduce la complejidad para el cliente, que ya no necesita conocer la dirección IP ni el puerto de un servicio. La distribución del tráfico entre los servicios está garantizada. Algunos controladores de Ingress admiten varios algoritmos de balanceo de carga para ofrecer mayor flexibilidad y control.

Implementación de un balanceador de carga con un controlador de Ingress

Como explicamos en «Implementación de BIG-IP y NGINX Ingress Controller en la misma arquitectura», muchas organizaciones tienen casos de uso en los que resulta beneficioso implementar un equilibrador de carga externo junto con un controlador de Ingress (o, en la mayoría de los casos, varias instancias de este). Esto es especialmente habitual cuando las organizaciones necesitan escalar Kubernetes u operar en entornos con requisitos de cumplimiento normativo estrictos. Estas herramientas suelen estar gestionadas por equipos diferentes y utilizarse para fines distintos:

• Balanceador de carga (o ADC):
  • Responsable: un equipo de NetOps (o quizá de SecOps)
  • Caso de uso: fuera de Kubernetes, como único punto de conexión público para los servicios y las aplicaciones que se ofrecen a usuarios externos al clúster. Se utiliza como un dispositivo más genérico, diseñado para facilitar la seguridad y proporcionar una gestión de red de nivel superior.
• Controlador de Ingress:
  • Responsable: un equipo de Operaciones de Plataforma o DevOps
  • Caso de uso: Dentro de Kubernetes para el balanceo de carga granular del tráfico norte-sur (HTTP2, HTTP/HTTPS, terminación SSL/TLS, TCP/UDP, WebSocket, gRPC), funciones de puerta de enlace de API y gestión centralizada de la seguridad y la identidad.

Este diagrama muestra cómo el equilibrador de carga distribuye el tráfico entre varios clústeres, mientras que estos cuentan con controladores de Ingress para garantizar una distribución uniforme entre los servicios.

Próximos pasos

Si después de leer todo esto aún tienes dudas, echa un vistazo al seminario web de la Linux Foundation «Por qué necesitas un controlador de Ingress y cómo elegir uno», en el que expertos de NGINX ofrecen una introducción a las redes de Kubernetes, analizan en profundidad los controladores de Ingress y explican el panorama actual de estos controladores.

Para obtener más información sobre cómo puede utilizar un controlador Ingress y cómo elegir el que mejor se adapte a sus requisitos, lea Guía para elegir un controlador Ingress, parte 1: identifique sus requisitos en nuestro blog.

Sobre el autor

Brian EhlertDirector de Gestión de Producto

Más artículos de Brian Ehlert