Crear y gestionar un entorno de Kubernetes sólido requiere una colaboración fluida entre los equipos de Redes y Aplicaciones. Sin embargo, sus prioridades y formas de trabajar suelen ser bastante diferentes, lo que genera conflictos con consecuencias potencialmente graves: lentitud en el desarrollo de aplicaciones, retrasos en la implementación e incluso interrupciones de la red.
Solo el éxito de ambos equipos, trabajando por un objetivo común, puede garantizar que las aplicaciones modernas de hoy se entreguen a tiempo con la seguridad y la escalabilidad adecuadas. Entonces, ¿cómo puede aprovechar las habilidades y la experiencia de cada equipo y, al mismo tiempo, ayudarles a trabajar de forma coordinada?
En nuestro libro blanco «Llévame al clúster», detallamos una solución para habilitar el acceso externo a los servicios de Kubernetes que permite a los equipos de Redes y Aplicaciones aunar 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 las propias instalaciones, con nodos que se ejecutan en servidores físicos o en máquinas virtuales (VM) Linux tradicionales, y con switches estándar de capa 2 y routers de capa 3 que proporcionan la conectividad necesaria para la comunicación en el centro de datos. No es aplicable a los clústeres de Kubernetes alojados en la nube, ya que los proveedores de servicios en la nube no nos permiten controlar ni la infraestructura de red principal de sus centros de datos ni la red de su entorno de Kubernetes gestionado.
Antes de entrar en los detalles de nuestra solución, veamos por qué otros métodos estándar para exponer aplicaciones en un clúster de Kubernetes no funcionan en implementaciones locales:
- Servicio – Agrupa los pods que ejecutan las mismas aplicaciones. Es ideal para la comunicación interna entre pods, pero solo es visible dentro del clúster, por lo que no permite exponer las aplicaciones al exterior.
- NodePort – Abre un puerto específico en cada nodo del clúster y reenvía el tráfico a la aplicación correspondiente. Aunque esto permite que los usuarios externos accedan al servicio, no es la opción ideal porque la configuración es estática, hay que utilizar puertos TCP con números altos (en lugar de puertos con números más bajos y ampliamente conocidos) y coordinar los números de puerto con otras aplicaciones. Tampoco se pueden compartir puertos TCP comunes entre distintas aplicaciones.
- LoadBalancer – Utiliza las definiciones de NodePort de cada nodo para crear una ruta de red desde el exterior hasta los nodos de Kubernetes. Es una opción excelente para Kubernetes alojado en la nube, ya que AWS, Google Cloud Platform, Microsoft Azure y la mayoría de los demás proveedores de servicios en la nube la admiten como una funcionalidad fácil de configurar, eficaz y que proporciona la dirección IP pública necesaria y el registro DNS
Acorrespondiente para un servicio. Lamentablemente, no existe una opción equivalente para los clústeres locales.
Habilitación del acceso de usuarios externos a clústeres de Kubernetes locales
Esto nos deja con el objeto Ingress de Kubernetes, diseñado específicamente para el tráfico que fluye desde usuarios externos al clúster hasta los pods que se encuentran dentro de él (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 desde el que los usuarios externos pueden acceder a varios servicios. ¡Es justo lo que necesitamos! El objeto Ingress se implementa mediante un controlador de Ingress; en nuestra solución, se trata de F5 NGINX Ingress Controller, de categoría empresarial y basado en NGINX Plus.
Puede que le sorprenda saber que otro componente clave de la solución es el protocolo de puerta de enlace fronteriza (BGP), un protocolo de enrutamiento de capa 3. Pero una gran solución no tiene por qué ser compleja.
La solución descrita en «Cómo llegar al clúster» consta en realidad de cuatro componentes:
- Red iBGP – El 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 que la red sea fiable y escalable. iBGP ya está implementado y cuenta con el soporte del equipo de Redes en la mayoría de los centros de datos.
- Redes CNI de Project Calico – Project Calico es una solución de redes de código abierto que conecta de forma flexible entornos de centros de datos locales, al tiempo que permite un control detallado del flujo de tráfico. Utilizamos el complemento CNI de Project Calico para gestionar las redes del clúster de Kubernetes, con BGP habilitado. Esto permite controlar los grupos de direcciones IP asignados a los pods, lo que ayuda a identificar rápidamente cualquier problema de red.
- NGINX Ingress Controller basado en NGINX Plus – Con NGINX Ingress Controller puede supervisar las direcciones IP de los endpoints de servicio de los pods y reconfigurar automáticamente la lista de servicios ascendentes sin interrumpir el procesamiento del tráfico. Los equipos de aplicaciones también pueden aprovechar muchas otras funciones HTTP de capa 7 de nivel empresarial de NGINX Plus, como las comprobaciones de estado activas, mTLS y la autenticación basada en JWT.
- NGINX Plus como proxy inverso en el perímetro – NGINX Plus actúa como proxy inverso en el perímetro del clúster de Kubernetes y proporciona una ruta entre los conmutadores y routers del centro de datos y la red interna del clúster de Kubernetes. Esto sustituye al objeto LoadBalancer de Kubernetes y utiliza Quagga para BGP.
El diagrama ilustra la arquitectura de la solución e indica qué protocolos utilizan sus componentes para comunicarse, no el orden en que se intercambian los datos durante el procesamiento de las solicitudes.
Descarga gratis el libro blanco
Al colaborar para implementar una solución con componentes bien definidos, los equipos de Redes y Aplicaciones pueden ofrecer fácilmente un rendimiento y una fiabilidad óptimos.
Nuestra solución utiliza herramientas y protocolos de red modernos, así como arquitecturas existentes. Al estar diseñada para ser económica y fácil de implementar, gestionar y mantener, simplifica el trabajo y tiende puentes entre sus equipos.
Para ver el código en acción y aprender paso a paso a implementar nuestra solución, descarga gratis Get Me to the Cluster for free.
Sobre el autor
Artículos relacionados del blog
Únete a F5 NGINX en AppWorld 2024
Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.
Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.
Exposición de APIs en Kubernetes
La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».
NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.
Presentamos NGINX Plus R22
NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.
Presentamos NGINX Plus R17
NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.