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.
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.
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:
A
correspondiente para un servicio. Lamentablemente, no existe un equivalente para los clústeres 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:
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.
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.