El traductor de coloquialismo de contenedores para NetOps

Hay días en los que la jerga que sale del mundo de los contenedores te hace dar vueltas la cabeza. Con cada nueva capacidad o característica ofrecida por soluciones relacionadas (malla de servicios, orquestadores, registros), parece surgir la necesidad de un nuevo término o frase. Esa frase a menudo tiene sentido para DevOps, pero evoca una expresión confusa y entrecerrada en NetOps.

Algo así como lo que dices cuando te pregunto dónde está el burbujeador más cercano. Lo llamas fuente de agua. En Wisconsin lo llamamos burbujeador. Lo mismo, diferente término.

Resulta que muchas de las “nuevas” capacidades y características relacionadas con el escalamiento de contenedores a nivel interno y en escenarios de múltiples nubes son en realidad solo fuentes de agua que DevOps llama burbujeadores. Este choque de coloquialismos puede provocar fricciones con NetOps a medida que los contenedores siguen ganando terreno sin cesar. Incluso si los clústeres de contenedores mantienen una existencia aislada, similar a una mininube, en producción, aún hay puntos de contacto con la red corporativa sobre los cuales NetOps continúa reinando. E invariablemente, NetOps y DevOps tendrán que trabajar juntos para escalar esos clústeres de forma segura en un mundo de múltiples nubes.

CONTROLADOR INGRESS

• Como se ha señalado , el término “controlador de ingreso” le da una nueva capa de pintura al equilibrio de carga de la capa 7 (conmutación de contenido, enrutamiento de contenido, etc.). Un controlador de ingreso es un proxy compatible con la capa 7 (HTTP) que enruta las solicitudes al recurso apropiado dentro de un clúster de contenedores.  La diferencia significativa entre los servidores proxy HTTP utilizados por NetOps en la red y aquellos que sirven como puntos de entrada a los clústeres de contenedores es que un controlador de ingreso debe ser consciente de los contenedores. Cuando digo "compatible con el contenedor" me refiero a que se configura y se gestiona automáticamente en función de los cambios que tienen lugar en el entorno de contenedores , en particular el del archivo de recursos que describe cómo el ingreso debe enrutar las solicitudes entrantes.

Equilibrio de carga consciente de la latencia

• Suena genial y fresco ¿no? Pero cuando se quita el kimono, NetOps asentirá enfáticamente al descubrir que esto no es realmente nada más que aprovechar un algoritmo de equilibrio de carga de "respuesta más rápida". La intención es mejorar el rendimiento de la aplicación al " desviar el tráfico de las instancias lentas ". El motivo por el cual se menciona esto es porque, en términos generales, los algoritmos de equilibrio de carga nativos utilizados por los orquestadores de contenedores son apáticos. Round Robin es prácticamente el estándar y sabemos que es el último algoritmo que deberías elegir si intentas optimizar el rendimiento. Poder enrutar solicitudes en función del mejor rendimiento es bastante importante teniendo en cuenta que cada llamada de microservicio a microservicio realizada para cumplir con una sola solicitud de cliente agrega su propia latencia.

Ingreso de múltiples clústeres

• Voy a empezar diciendo que esto suena mucho mejor que el término que la industria ha estado utilizando durante casi veinte años. Básicamente esto es GSLB (equilibrio de carga global del servidor). Sí, sé que estás decepcionado, pero en realidad eso es lo que hace el ingreso de múltiples clústeres . ¡Tomas un controlador de ingreso y le aplicas un poco de bondad en la gestión global del tráfico y listo! Tienes GSLB para clústeres de contenedores en una configuración de múltiples nubes. Estoy votando para reemplazar GSLB con este término en el lado de NetOps, porque suena más impresionante.

Éstos no son los únicos términos que aparecen, ni tampoco serán los últimos. Son los más relevantes en términos de funcionalidad y capacidades “en la red” siendo subsumidos por DevOps. Algunos de ellos necesitarán la atención de NetOps a medida que se trasladan a entornos de producción (como Multi-Cluster Ingress) y otros no: el equilibrio de carga consciente de la latencia dentro de los entornos de contenedores probablemente seguirá siendo competencia de DevOps, aunque es bueno tener un entendimiento durante las discusiones sobre cómo mejorar el rendimiento o la disponibilidad.

Hay un componente cultural en DevOps que a menudo se pasa por alto o se ignora por completo. A medida que el movimiento continúa dejando su huella en NetOps y las operaciones de red tradicionales adoptan lenta pero seguramente sus principios para lograr una red ágil, la comunicación se vuelve fundamental. Esto significa encontrar un terreno común. Comprender la jerga de los demás puede ser un buen primer paso hacia la creación de una cultura más colaborativa necesaria para garantizar que las implementaciones de aplicação sean tan rápidas, seguras y confiables como su entrega.