Controladores de Ingress: nuevo nombre, función conocida

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Coloquialismos. Son esas palabras y expresiones que tienen un significado exclusivamente local y que pueden desconcertar a quienes no son de la zona. Por ejemplo, cuando estoy fuera de casa y tengo sed, busco un «bubbler». Tú probablemente (supongo que no eres de Wisconsin) buscas una fuente de agua. En Wisconsin, medimos las distancias en tiempo, no en kilómetros. Los semáforos son luces de «parar y seguir». Porque eso es lo que haces.

La expresión favorita de mi marido (que no es de aquí) para reírse es «C’mere once». No intentaré explicarla; simplemente, tiene sentido para mí y para los niños con los que la uso. Y entendemos de forma innata que «Up North» no es una dirección, sino un lugar cuya ubicación concreta puede variar según quien hable, pero que para cualquier persona nacida en Wisconsin tiene la misma connotación: «ese lugar al que vamos para evadirnos de todo».

Probablemente tengas tu propia lista, ya que creciste en otro lugar. Pero este es mi blog, así que puedo usar la mía.

Sin embargo, el objetivo de hoy no es dar una lección de semántica en sí, sino hablar de su aplicación a un fenómeno más localizado que se produce en tu propio patio trasero. Siempre que ese patio trasero sea tu organización, claro.

El auge de los contenedores y de los sistemas automatizados de control de clústeres que estos requieren (a menudo denominados «orquestación») ha tenido la consecuencia imprevista de trasladar expresiones coloquiales de un lado al otro de la frontera. Por cierto, nos referimos al paso del desarrollo de aplicaciones al ámbito de las TI propiamente dicho.

El curioso caso de la jerga de los contenedores

Muchas de las funciones necesarias para lograr la flexibilidad y la fiabilidad requeridas a gran escala han supuesto la migración al «entorno» de contenedores de determinados servicios que antes se utilizaban exclusivamente en producción. Ahora, estas funciones están aparentemente «integradas» en dicho entorno y utilizan mecanismos de integración ligeros (API y colas de mensajes) para conseguir lo que hasta ahora solo podía lograrse mediante un entorno de computación en la nube plenamente implementado: escalado automático y aplicaciones de alta disponibilidad.

De este modo, las funciones de equilibrio de carga están integradas de forma nativa en los pods/nodos mediante pequeños servicios similares a demonios. Aunque no son muy avanzadas (apenas superan las capacidades del equilibrio de carga de red), cumplen la función para la que fueron diseñadas. Estos servicios pueden ser —y son— modulares, por así decirlo, lo que permite incorporar otros proyectos (de código abierto o proporcionados por proveedores) que ofrecen capacidades más avanzadas (y, cabe esperar, también algoritmos).

Pero, por sí solas, estas funciones de equilibrio de carga no proporcionan la escalabilidad y la alta disponibilidad que, en última instancia, buscamos (y necesitamos en los entornos de producción). Tampoco son capaces de enrutar API, ya que para ello se requiere la inteligencia de HTTP (L7). La necesitamos para poder escalar horizontalmente y de forma eficiente aplicaciones modernas sustentadas por microservicios y expuestas mediante fachadas de API. Necesitamos una solución más robusta.

Aquí es donde entran en juego los controladores de entrada . Estos son los «balanceadores de carga» que analizan y dirigen el tráfico entrante en función de los URI y los encabezados HTTP para permitir el enrutamiento en la capa de aplicación y la escalabilidad.

Lo que ha ocurrido es que los desarrolladores que crearon (y posteriormente utilizan) controladores de entrada han reinventado, en esencia, lo que nosotros (en operaciones de red) denominaríamos gestión del tráfico, entrega de aplicaciones o conmutación/enrutamiento de contenidos. A lo largo de los años, en operaciones de red hemos utilizado muchos términos distintos, al igual que en desarrollo (y operaciones). Enrutamiento de aplicaciones y enrutamiento de páginas son otros términos que los desarrolladores han utilizado para describir el enrutamiento de capa 7. El concepto resulta familiar para ambos grupos, pero no así los términos, es decir, los coloquialismos.

Un controlador de entrada se encarga de dirigir las solicitudes al servicio (virtual) adecuado dentro del clúster de contenedores. Dicho servicio puede ser otro proxy de equilibrio de carga o una estructura específica del sistema de contenedores. En cualquier caso, la función del controlador de entrada es dirigir el tráfico en función de los valores de la capa 7 (HTTP) incluidos en las cabeceras HTTP de una solicitud HTTP. Normalmente se trata del URI, pero también podría ser el nombre de host u otro valor personalizado (como un número de versión o una clave de API).

Una vez que el controlador de entrada ha extraído el valor de la cabecera, utiliza las políticas descritas en los archivos de recursos para determinar cómo distribuir el tráfico. Puede distribuirlo de forma equitativa o enviar el 75 % a una versión del servicio y el 25 % a otra. En ese sentido, ofrece bastante flexibilidad. El controlador de entrada también se encarga de la supervisión (estado y disponibilidad) y debe tener mucho cuidado de no enviar una solicitud a un servicio «inactivo».

¿Os suena, profesionales de operaciones de red? Debería, porque esas son básicamente las funciones de un proxy inteligente (compatible con L7), como BIG-IP.

Ahora que ya sabe en qué se parecen, permítame asegurarle que existen algunas diferencias. En particular, un controlador de entrada se configura de forma declarativa. Es decir, su configuración viene determinada por una descripción incluida en un archivo de recursos externo al propio controlador. Esto difiere de los proxies inteligentes tradicionales que controlan y dirigen el tráfico de entrada. Los proxies inteligentes tradicionales son las fuentes autoritativas del entorno. Un controlador de entrada no lo es. Para obtener esa información, consulta otros recursos: archivos que actúan como una especie de «capa de abstracción» y permiten flexibilidad en las implementaciones. Esto significa que el controlador (o un componente complementario) debe leerlos, interpretarlos y crear la configuración adecuada para esa descripción. Además, debe mantenerla actualizada. Aunque la variabilidad en el control de entrada de un entorno en contenedores es menor que en las capas más internas del sistema, sigue habiendo cambios que deben supervisarse.

En definitiva, el controlador de entrada se encarga de enrutar, en la capa de aplicación, las solicitudes procedentes del exterior hacia el recurso adecuado dentro del entorno en contenedores. Lo que viene a ser, básicamente, la definición de un balanceador de carga inteligente.

Puede que el nombre haya cambiado, pero las funciones siguen siendo prácticamente las mismas.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie