Conceptos básicos de redes Kubernetes

NodePort, LoadBalancer, controlador de Ingress… ¡Dios mío!

Cuando hablamos con clientes y la comunidad sobre cómo hacer que Kubernetes sea de nivel de producción, una de las preguntas más comunes es: ¿necesito un controlador de Ingress? La respuesta a esta pregunta rara vez es un simple sí o no, sino que implica cierta educación sobre las diferentes formas en que puede generar tráfico hacia sus grupos de clientes. En este blog, cubrimos los conceptos básicos de la red Kubernetes para que pueda tomar una decisión informada sobre si necesita 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 y no está diseñado para equilibrar el tráfico, controlar API o monitorear el comportamiento del servicio.

Afortunadamente, existen otras formas de administrar el tráfico externo, pero antes de continuar, hagamos una revisión rápida de los componentes de Kubernetes:

• Las implementaciones de Kubernetes se componen de nodos , que son máquinas físicas o virtuales.
• Los nodos se unen para formar un clúster .
• Cada clúster administra pods , que son el mínimo común denominador a nivel de red e infraestructura en Kubernetes. Uno o más pods juntos forman un servicio .
• Dentro de cada cápsula reside uno o más contenedores (dependiendo del tamaño de la aplicação ).

Kubernetes observa los pods que componen un servicio y los escala según sea necesario para satisfacer los requisitos de la aplicación. Pero ¿cómo conseguir tráfico hacia los pods? Aquí es donde entran en juego dos tipos de objetos de Kubernetes: servicios y controladores de ingreso.

¿Qué es un servicio 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 red de contenedores de modo que su ubicación en un nodo específico no sea relevante. Esto significa que el tráfico externo se puede enrutar a pods específicos incluso cuando cambian sus ubicaciones o incluso cuando se destruyen y se reinician. De esta manera, un servicio actúa de forma muy similar a un proxy inverso muy básico.

Hay varios tipos de servicios y tipos de objetos de servicio relevantes para enrutar el tráfico externo hacia Kubernetes. A menudo se confunden entre sí, pero en realidad cada uno hace cosas muy diferentes, por lo que vale la pena repasar sus funciones, usos y desventajas.

IP de clúster

ClusterIP es el servicio predeterminado que proporciona un servicio dentro de Kubernetes al que pueden acceder otros servicios dentro del clúster. No es accesible desde fuera del cluster. La única forma de exponer un servicio ClusterIP es usar algo como kube-proxy , pero hay pocos escenarios en los que esto tiene sentido. Los ejemplos limitados incluyen acceder a un servicio en su computadora portátil, depurar un servicio o mirar algún monitoreo y métricas.

NodePort

Un servicio NodePort abre un puerto específico en cada nodo del clúster y reenvía el tráfico enviado a dicho nodo a la aplicación correspondiente. Esta es una forma muy básica de dirigir tráfico a las aplicaciones, pero presenta muchas limitaciones en casos prácticos de gestión de tráfico. Solo puede tener un servicio por NodePort y solo puede usar puertos en el rango 30000 a 32767. Si bien 2768 puertos pueden parecer muchos, las organizaciones que ejecutan Kubernetes a gran escala se quedarán sin ellos rápidamente. Además, NodePort utiliza reglas de enrutamiento de capa 4 y la utilidad iptables de Linux, que limita el enrutamiento de capa 7.

Además de las limitaciones de enrutamiento, existen otras tres grandes desventajas al usar NodePort:

• Los clientes descendentes deben conocer la dirección IP de cada nodo para conectarse a él: esto se vuelve problemático si cambia la dirección IP del nodo o el host de la máquina virtual .

• NodePort no puede redirigir tráfico a múltiples 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 una sobrecarga del servicio y el agotamiento del puerto.

  

Balanceador de carga

Un servicio LoadBalancer acepta tráfico externo pero requiere un balanceador de carga externo como interfaz para ese tráfico. Esto admite el enrutamiento de capa 7 (a direcciones IP de pod), siempre que el balanceador de carga externo esté correctamente ajustado y reconfigurado para asignarse a pods en ejecución. LoadBalancer es una de las formas más populares de exponer servicios externamente. Se utiliza con mayor frecuencia en una plataforma en la nube y es una buena opción para implementaciones pequeñas y estáticas.

Si utiliza un servicio de Kubernetes administrado, obtendrá automáticamente el balanceador de carga seleccionado por el proveedor de nube. Por ejemplo, en Google Cloud Platform puedes activar un balanceador de carga de red usando el tipo de servicio LoadBalancer, mientras que Aplicação Load Balancer (ALB) es el predeterminado en AWS. Cada servicio que expones obtiene su propia dirección IP pública que reenvía todo el tráfico, pero sin ningún tipo de filtrado o enrutamiento, lo que significa que puedes enviar casi cualquier tipo de tráfico (HTTP, TCP/UDP, WebSocket, etc.). De manera alternativa, si no desea utilizar las herramientas del proveedor de la nube (por ejemplo, si necesita una mayor funcionalidad o una herramienta independiente de la plataforma), puede reemplazarlo con algo como F5 BIG-IP (como balanceador de carga externo) y F5 Container Ingress Services (como un operador que actúa en calidad de LoadBalancer). Para obtener más información sobre este patrón, consulte Implementación de BIG-IP y el controlador de ingreso NGINX en la misma arquitectura en nuestro blog.

El uso de LoadBalancer para exponer sus aplicaciones se vuelve un desafío en entornos dinámicos donde sus pods de aplicaciones necesitan escalar para satisfacer los niveles cambiantes de demanda. Debido a que cada servicio obtiene su propia dirección IP, una aplicación popular puede tener cientos, o incluso miles, de direcciones IP para administrar. En la mayoría de los casos, el balanceador de carga externo se conecta a los servicios a través de NodePort como se muestra en el siguiente diagrama. Si bien esto garantiza que el tráfico se distribuya de manera uniforme entre los nodos, el equilibrio de carga hacia los servicios aún no es posible, por lo que aún se produce sobrecarga de servicios y agotamiento de puertos.

¿Qué es un controlador de ingreso de Kubernetes?

Según la documentación de Kubernetes , “los controladores son bucles de control que observan el estado de su clúster y luego 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 administrar el estado en Kubernetes para muchas tareas: asignar recursos correctamente, designar almacenamiento persistente y administrar trabajos cron.

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

Un controlador de Ingress se utiliza para configurar y administrar interacciones externas con pods que están etiquetados para un servicio específico. Los controladores de ingreso están diseñados para tratar el enrutamiento dinámico de capa 7 como un ciudadano de primera clase. Esto significa que los controladores Ingress brindan un control granular con menos esfuerzo. Puede utilizar fácilmente un controlador de ingreso no solo para controlar el tráfico de ingreso, sino también para proporcionar métricas de rendimiento a nivel de servicio y como parte de una política de seguridad. Los controladores de ingreso tienen muchas características de los balanceadores de carga externos tradicionales, como la terminación TLS, el manejo de múltiples dominios y espacios de nombres y, por supuesto, el equilibrio de carga del tráfico. Los controladores de ingreso pueden equilibrar la carga del tráfico a nivel de solicitud en lugar de a nivel de servicio, una vista más útil del tráfico de capa 7 y una forma mucho mejor de hacer cumplir los SLA.

¡Y hay otra ventaja más! Los controladores de ingreso también pueden implementar reglas de salida que permitan el tráfico saliente desde ciertos pods solo a servicios externos específicos o garantizar que el tráfico esté encriptado mutuamente mediante mTLS. Exigir mTLS es crucial para brindar servicios regulados en industrias como la atención médica, las finanzas, las telecomunicaciones y el gobierno, y es un componente clave en una estrategia de cifrado de extremo a extremo (E2EE). Controlar el tráfico saliente desde la misma herramienta también simplifica la aplicação de la lógica empresarial a los servicios. Es mucho más fácil configurar reglas de recursos apropiadas cuando tanto el ingreso como el egreso están vinculados en el mismo plano de control.

El siguiente diagrama muestra cómo un controlador Ingress reduce la complejidad para el cliente, que ya no necesita conocer la dirección IP o el puerto de un servicio. Se garantiza la distribución del tráfico entre los servicios. Algunos controladores Ingress admiten múltiples algoritmos de equilibrio de carga para mayor flexibilidad y control.

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

Como analizamos en Implementación de BIG-IP y un controlador de ingreso NGINX en la misma arquitectura , muchas organizaciones tienen casos de uso que se benefician al implementar un balanceador de carga externo con un controlador de ingreso (o en la mayoría de los casos, múltiples instancias de controlador de ingreso). Esto es especialmente común cuando las organizaciones necesitan escalar Kubernetes u operar en entornos de alto cumplimiento. Las herramientas normalmente son administradas por diferentes equipos y utilizadas para diferentes propósitos:

• Balanceador de carga (o ADC):

  • Dueño: Un equipo de NetOps (o tal vez SecOps)
  • CASO DE USO:Fuera de Kubernetes como el único punto final público para servicios y aplicaciones entregados a usuarios fuera del clúster. Se utiliza como un dispositivo más genérico diseñado para facilitar la seguridad y ofrecer una gestión de red de nivel superior.

• Controlador de ingreso:

  • Dueño: Un equipo de Platform Ops o DevOps
  • CASO DE USO:Dentro de Kubernetes para un equilibrio de carga detallado del tráfico norte-sur (HTTP2, HTTP/HTTPS, terminación SSL/TLS, TCP/UDP, WebSocket, gRPC), funciones de puerta de enlace de API y seguridad e identidad centralizadas.

Este diagrama muestra el balanceador de carga manejando la distribución del tráfico entre múltiples clústeres, mientras que los clústeres tienen controladores de ingreso para garantizar una distribución equitativa a los servicios.

Próximos pasos

Si has leído todo esto y todavía te preguntas, mira el seminario web de la Fundación Linux Por qué necesitas un controlador de Ingress y cómo elegir uno , donde los expertos de NGINX ofrecen una introducción a las redes de Kubernetes, profundizan en los controladores de Ingress y debaten el panorama de los controladores de Ingress.

Para obtener más información sobre cómo usar un controlador Ingress y cómo elegir uno que funcione mejor para sus necesidades, lea Una guía para elegir un controlador Ingress, Parte 1: Identifique sus requisitos en nuestro blog.