BLOG | NGINX

¿Llevarme al cluster…con BGP?

NGINX - Parte de F5 - horizontal, negro, tipo RGB
Miniatura de Chris Akker
Chris Akker
Publicado el 28 de febrero de 2023

La creación y gestión de un entorno de Kubernetes sólido exige una colaboración fluida entre los equipos de red y de aplicação . Pero sus prioridades y estilos de trabajo suelen ser bastante diferentes, lo que genera conflictos con consecuencias potencialmente graves: desarrollo lento de aplicaciones, implementación retrasada e incluso tiempo de inactividad de la red.

Solo el éxito de ambos equipos, trabajando hacia un objetivo común, puede garantizar que las aplicações modernas actuales se entreguen a tiempo con la seguridad y escalabilidad adecuadas. Entonces, ¿cómo aprovechar las habilidades y la experiencia de cada equipo y al mismo tiempo ayudarlos a trabajar en conjunto?

En nuestro documento técnico Get Me to the Cluster , detallamos una solución para habilitar el acceso externo a los servicios de Kubernetes que permite a los equipos de redes y aplicação combinar sus fortalezas sin conflictos.

Cómo exponer aplicaciones en clústeres de Kubernetes

La solución funciona específicamente para clústeres de Kubernetes alojados en instalaciones locales , con nodos que se ejecutan en hardware o máquinas virtuales Linux tradicionales (VM) y conmutadores de capa 2 estándar y enrutadores de capa 3 que proporcionan la red para la comunicación en el centro de datos. No se extiende a los clústeres de Kubernetes alojados en la nube, porque los proveedores de la nube no nos permiten controlar la red central en sus centros de datos ni la red en su entorno de Kubernetes administrado.

Diagrama de clústeres de Kubernetes alojados en las instalaciones, con nodos y conmutadores de capa 2 estándar y enrutadores de capa 3 que proporcionan la red para la comunicación en el centro de datos.

Antes de repasar los detalles de nuestra solución, revisemos por qué otras formas estándar de exponer aplicações en un clúster de Kubernetes no funcionan para implementaciones locales:

  • Servicio : agrupa pods que ejecutan las mismas aplicaciones. Esto es excelente para la comunicación interna entre pods , pero solo es visible dentro del clúster, por lo que no ayuda a exponer aplicaciones externamente.
  • NodePort : Abre un puerto específico en cada nodo del clúster y reenvía el tráfico a la aplicación correspondiente. Si bien esto permite que los usuarios externos accedan al servicio, no es ideal, ya que la configuración es estática y es necesario usar puertos TCP de alta numeración (en lugar de los puertos de menor numeración conocidos) y coordinar los números de puerto con otras aplicaciones. Tampoco puedes compartir puertos TCP comunes entre diferentes aplicaciones.
  • LoadBalancer : utiliza las definiciones de NodePort en cada nodo para crear una ruta de red desde el mundo exterior a sus nodos de Kubernetes. Es excelente para Kubernetes alojado en la nube, porque AWS, Google Cloud Platform, Microsoft Azure y la mayoría de los demás proveedores de la nube lo admiten como una función de fácil configuración que funciona bien y proporciona la dirección IP pública requerida y el registro DNS A correspondiente para un servicio. Lamentablemente, no existe un equivalente para los clústeres locales.

Habilitación del acceso de usuarios externos a clústeres de Kubernetes locales

Eso nos deja con el objeto Ingress de Kubernetes, que está diseñado específicamente para el tráfico que fluye desde usuarios fuera del clúster a pods dentro del clúster (tráfico norte-sur). Ingress crea un punto de entrada HTTP/HTTPS externo para el clúster: una única dirección IP o nombre DNS en el que los usuarios externos pueden acceder a múltiples servicios. ¡Esto es justo lo que se necesita! El objeto Ingress se implementa mediante un controlador Ingress: en nuestra solución, el controlador Ingress F5 NGINX de nivel empresarial basado en NGINX Plus .

Tal vez le sorprenda saber que otro componente clave de la solución es el Border Gateway Protocol (BGP), un protocolo de enrutamiento de capa 3. ¡Pero una gran solución no tiene por qué ser compleja!

La solución descrita en Get Me to the Cluster en realidad tiene cuatro componentes:

  1. Red iBGP : el protocolo BGP interno (iBGP) se utiliza para intercambiar información de enrutamiento dentro de un sistema autónomo (AS) en el centro de datos y ayuda a garantizar la confiabilidad y escalabilidad de la red. iBGP ya está implementado y cuenta con el respaldo del equipo de red en la mayoría de los centros de datos.
  2. Redes CNI del Proyecto Calico : el Proyecto Calico es una solución de red de código abierto que conecta de forma flexible entornos en centros de datos locales al tiempo que proporciona un control detallado sobre el flujo de tráfico. Utilizamos el complemento CNI del Proyecto Calico para la red en el clúster Kubernetes, con BGP habilitado. Esto le permite controlar los grupos de direcciones IP asignados a los pods, lo que ayuda a identificar rápidamente cualquier problema de red.
  3. Controlador de ingreso NGINX basado en NGINX Plus : con el controlador de ingreso NGINX puede observar las direcciones IP de los puntos finales de servicio de los pods y reconfigurar automáticamente la lista de servicios ascendentes sin interrumpir el procesamiento del tráfico. Los equipos de aplicação también pueden aprovechar muchas otras funciones HTTP de capa 7 de nivel empresarial en NGINX Plus, incluidos controles de estado activos, mTLS y autenticación basada en JWT.
  4. NGINX Plus como proxy inverso en el borde : NGINX Plus funciona como un proxy inverso en el borde del clúster de Kubernetes, proporcionando una ruta entre los conmutadores y enrutadores en el centro de datos y la red interna en el clúster de Kubernetes. Esto funciona como reemplazo del objeto LoadBalancer de Kubernetes y utiliza Quagga para BGP.

El diagrama ilustra la arquitectura de la solución, indicando qué protocolos utilizan los componentes de la solución para comunicarse, no el orden en que se intercambian los datos durante el procesamiento de la solicitud.

Diagrama que ilustra la arquitectura de la solución, indicando qué protocolos utilizan los componentes de la solución para comunicarse.

Descargue el documento técnico gratis

Al trabajar juntos para implementar una solución con componentes bien definidos, los equipos de redes y aplicação pueden ofrecer fácilmente un rendimiento y una confiabilidad óptimos.

Nuestra solución utiliza herramientas de red modernas, protocolos y arquitecturas existentes. Debido a que está diseñado para ser económico y fácil de implementar, administrar y soportar, agrega facilidad y construye puentes entre sus equipos.

Para ver el código en acción y aprender paso a paso cómo implementar nuestra solución, descargue Get Me to the Cluster gratis .


"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.