Eres un desarrollador de aplicaciones modernas. Utilizas un conjunto de herramientas de código abierto y quizá algunas comerciales para escribir, probar, desplegar y gestionar nuevas aplicaciones y contenedores. Has elegido Kubernetes para ejecutar estos contenedores y pods en entornos de desarrollo, pruebas, preproducción y producción. Has adoptado las arquitecturas y los conceptos de los microservicios, la Cloud Native Computing Foundation y otros estándares modernos del sector.
A lo largo de este recorrido, has descubierto que Kubernetes es realmente potente. Pero probablemente también te haya sorprendido lo difícil, inflexible y frustrante que puede llegar a ser. Implementar y coordinar cambios y actualizaciones en routers, cortafuegos, balanceadores de carga y otros dispositivos de red puede resultar abrumador, especialmente en tu propio centro de datos. ¡Es para hacer llorar a cualquier desarrollador!
La forma de afrontar estos retos depende en gran medida de dónde y cómo se ejecute Kubernetes (como servicio gestionado o en las propias instalaciones). Este artículo aborda el balanceo de carga TCP, un ámbito clave en el que las decisiones de implementación influyen en la facilidad de uso.
Equilibrado de carga TCP con Kubernetes gestionado (también conocido como la opción fácil)
Si utilizas un servicio gestionado, como el de un proveedor de nube pública para Kubernetes, gran parte de esas tediosas tareas de red se gestionan por ti. Con un solo comando (kubectl apply -f loadbalancer.yaml), el tipo Service LoadBalancer te proporciona una IP pública, un registro DNS y un balanceador de carga TCP. Por ejemplo, podrías configurar Amazon Elastic Load Balancer para distribuir el tráfico entre los pods que contienen NGINX Ingress Controller y, con este comando, olvidarte de los cambios en los backends. Es tan fácil que seguro que lo das por sentado.
Equilibrado de carga TCP con Kubernetes en las instalaciones (también conocido como la opción difícil)
Con los clústeres locales, la situación es totalmente distinta. Tú o tus compañeros del equipo de redes debéis proporcionar los componentes de red. Quizá te preguntes: «¿Por qué es tan difícil permitir que los usuarios accedan a mis aplicaciones de Kubernetes?». La respuesta es sencilla, aunque un tanto sorprendente: el tipo de Service LoadBalancer, la puerta de entrada a tu clúster, en realidad no existe.
Para exponer sus aplicaciones y servicios fuera del clúster, es probable que su equipo de redes exija solicitudes, aprobaciones, procedimientos y quizá incluso revisiones de seguridad, todo ello antes de reconfigurar sus equipos. O puede que tenga que hacerlo todo usted mismo, lo que ralentizaría enormemente la entrega de aplicaciones. Y, lo que es aún peor, no se atreve a modificar ningún servicio de Kubernetes, porque, si cambia el NodePort —¡el tráfico podría quedar bloqueado! Y todos sabemos lo mucho que les gusta a los usuarios recibir errores 500. Probablemente a su jefe le gusten aún menos.
Una solución mejor para el balanceo de carga TCP en entornos locales: NGINX Loadbalancer para Kubernetes
Puede convertir la «opción difícil» en la «opción fácil» con nuestro nuevo proyecto: NGINX Loadbalancer for Kubernetes. Este proyecto gratuito es un controlador de Kubernetes que supervisa NGINX Ingress Controller y actualiza automáticamente una instancia externa de NGINX Plus configurada para el balanceo de carga. Gracias a la sencillez de su diseño, es fácil de instalar y utilizar. Con esta solución, puede implementar el balanceo de carga TCP en entornos locales, lo que garantiza que las nuevas aplicaciones y servicios se detecten de inmediato y estén disponibles para recibir tráfico, sin necesidad de intervención manual.
Arquitectura y flujo
NGINX Loadbalancer for Kubernetes se encuentra dentro de un clúster de Kubernetes. Está registrado en Kubernetes para supervisar el servicio nginx-ingress (NGINX Ingress Controller). Cuando se produce un cambio en los backends, NGINX Loadbalancer for Kubernetes recopila las IP de los nodos de trabajo y los números de puerto TCP de NodePort y, a continuación, envía las IP y los puertos a NGINX Plus a través de la API de NGINX Plus. Los servidores upstream de NGINX se actualizan sin necesidad de recarga, y NGINX Plus distribuye el tráfico entre los servidores upstream y los NodePort de Kubernetes correctos. Se pueden añadir instancias adicionales de NGINX Plus para lograr una alta disponibilidad.
Una instantánea del balanceador de carga NGINX para Kubernetes en acción
En la siguiente captura de pantalla, se muestran dos ventanas que demuestran que NGINX Loadbalancer for Kubernetes está desplegado y cumpliendo su función:
- Tipo de servicio – LoadBalancer (para
nginx-ingress) - IP externa – Se conecta a los servidores NGINX Plus
- Puertos – NodePort se asigna a 443:30158 con los servidores ascendentes de NGINX correspondientes (como se muestra en el panel de control en tiempo real)
- Registros – Indica que NGINX Loadbalancer for Kubernetes está enviando datos correctamente a NGINX Plus
Nota: En este ejemplo, los nodos de trabajo de Kubernetes son 10.1.1.8 y 10.1.1.10
Empieza hoy mismo
Si te frustran los problemas de red en el perímetro de tu clúster de Kubernetes, prueba el proyecto y cuéntanos qué te parece. El código fuente de NGINX Loadbalancer for Kubernetes es de código abierto (bajo la licencia Apache 2.0) y todas las instrucciones de instalación están disponibles en GitHub.
Para enviarnos tus comentarios, deja un comentario en el repositorio o escríbenos en el Slack de la comunidad de NGINX.
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.