Controladores de ingreso: Nuevo nombre, función familiar
Coloquialismos. Éstas son aquellas palabras y frases que tienen un significado local único que puede confundir a aquellos que no son nativos del área. Por ejemplo, cuando estoy fuera y tengo sed, busco un bebedero. Probablemente (supongo que no eres un 'Sconnie') busques una fuente de agua. En Wisconsin, medimos las distancias en tiempo, no en millas. Los semáforos son luces de “parar y seguir”. Porque eso es lo que haces.
La frase favorita de mi marido (que no es nativo) para reírse es “Ven aquí una vez”. No intentaré explicarlo más allá de lo que tenga sentido para mí y para los niños con quienes lo uso. Y entendemos inherentemente que “Up North” no es una dirección, sino un lugar cuya ubicación puede ser específica para el hablante pero conlleva una connotación común a cada nativo de Wisconsin que describe “ese lugar al que vamos para escapar de todo”.
Probablemente tengas tu propia lista, ya que creciste en otro lugar. Pero este es mi blog, así que puedo usar el mío.
Sin embargo, el objetivo de hoy no es dar una lección de semántica per se, sino más bien su aplicabilidad a un fenómeno más localizado en nuestro propio patio trasero. Si tu patio trasero fuera tu organización, al menos.
El auge de los contenedores y sus sistemas de control de agrupamiento automatizado, bastante necesarios (a menudo denominados orquestación), ha tenido la consecuencia no deseada de forzar el uso de coloquialismos de un lado a otro de la línea estatal. Por cierto, eso es desarrollo de aplicaciones en TI propiamente dicho.
El curioso caso de los coloquialismos en torno a los contenedores
Muchas de las funciones requeridas para lograr la flexibilidad y confiabilidad de la escala requerida han significado la migración de ciertos servicios que anteriormente solo estaban disponibles en producción al “entorno” de contenedores. Estas funciones están aparentemente "integradas" a ese entorno ahora, mediante una integración liviana (API y colas de mensajes) para lograr lo que hasta ahora solo se podía lograr desde un entorno de computación en la nube completamente implementado: aplicações de alta disponibilidad y escalamiento automático.
Al hacerlo, las funciones de equilibrio de carga son nativas de los pods/nodos a través de pequeños servicios similares a demonios. Si bien no son muy avanzados (estamos hablando de capacidades apenas superiores a las de equilibrio de carga de la red), hacen el trabajo para el que fueron diseñados. Estos servicios pueden ser (y son) conectables, por así decirlo, lo que permite otros proyectos (de código abierto y proporcionados por el proveedor) que desbloquean capacidades más avanzadas (y, se espera, algoritmos).
Pero, en sí mismas, estas funciones de equilibrio de carga no permiten la escala y la alta disponibilidad que en última instancia buscamos (y necesitamos en entornos de producción). Tampoco son capaces de enrutar API, que requieren inteligencia HTTP (L7). Necesitamos eso si vamos a escalar de manera eficiente aplicações modernas respaldadas por microservicios y protegidas por fachadas API. Necesitamos una solución más robusta.
Ahí es donde entran en escena los controladores de ingreso . Estos son los “balanceadores de carga” que diseccionan y dirigen el tráfico de ingreso en función de URI y encabezados HTTP para permitir el enrutamiento y la escalabilidad de la capa de aplicação .
Lo que ha sucedido es que los desarrolladores que crearon (y posteriormente utilizan) controladores de ingreso básicamente han recreado lo que nosotros (en netops) llamaríamos gestión de tráfico, o distribución de aplicação , o conmutación/enrutamiento de contenido. Hemos utilizado muchos términos diferentes a lo largo de los años en netops, al igual que en dev(ops). El enrutamiento de aplicaciones y el enrutamiento de páginas también son términos que los desarrolladores han utilizado para describir el enrutamiento L7. El concepto no es desconocido para ninguno de los dos grupos. Pero los términos, los coloquialismos, sí lo son.
Un controlador de ingreso tiene la tarea de enrutar las solicitudes al servicio (virtual) apropiado dentro del clúster de contenedores. Ese servicio podría ser otro proxy de equilibrio de carga o podría ser una construcción específica del sistema de contenedores. En cualquier caso, la función del controlador de ingreso es enrutar el tráfico en función de los valores de la capa 7 (HTTP) dentro de los encabezados HTTP de una solicitud HTTP. Generalmente es la URI, pero podría ser el nombre del host o algún otro valor personalizado (como un número de versión o una clave API).
Una vez que el controlador de ingreso ha extraído el valor del encabezado, utiliza políticas descritas por archivos de recursos para determinar cómo distribuirlo. Puede distribuirse equitativamente o enviar el 75% a una versión del servicio y el 25% a otra. De esa manera es bastante flexible. El controlador de ingreso también tiene responsabilidades de monitoreo (estado y salud) y debe tener mucho cuidado de no distribuir una solicitud a un servicio “inactivo”.
¿Te suena familiar, netops? Debería, porque esas son básicamente las funciones de un proxy inteligente (con capacidad L7) (como BIG-IP).
Ahora que ya sabes en qué se parecen, déjame asegurarte que hay algunas diferencias. En particular, un controlador de ingreso se configura de forma declarativa. Es decir, su configuración está determinada por una descripción en un archivo de recursos externo al propio controlador. Esto no es como los proxies inteligentes tradicionales que controlan y dirigen el tráfico de ingreso. Los proxies inteligentes tradicionales son fuentes autorizadas del entorno. Un controlador de ingreso no lo es. Lo busca en otra parte, en archivos que actúan como una especie de “capa de abstracción” que permite flexibilidad en las implementaciones. Esto significa que éste (o un componente complementario) tiene que leerlo, interpretarlo y crear la configuración adecuada a esa descripción. Y tiene que mantenerlo actualizado. Si bien la variabilidad en el control de ingreso a un entorno en contenedores es menor que en lo más profundo del sistema, aun así cambia y es necesario prestar atención a ella.
Cuando todo está dicho y hecho, el controlador de ingreso es responsable del enrutamiento de las solicitudes de la capa de aplicação desde el exterior al recurso apropiado dentro del entorno en contenedores. Lo cual es prácticamente la definición de un balanceador de carga inteligente.
El nombre puede haber cambiado, pero las funciones siguen siendo prácticamente las mismas.