Arquitectura de infraestructuras: los contenedores crean un cuarto plano

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

En las infraestructuras de red tradicionales suele haber tres planos arquitectónicos asociados: datos, control y gestión.

Las definiciones exactas pueden variar según el tipo y la implementación específica de la infraestructura, pero estos modelos generales son válidos para la mayoría de las infraestructuras de red.

• Plano de datos
  
  • En la terminología moderna, el plano de datos, denominado a veces ruta de datos, es la ruta por la que se transmiten los paquetes (datos). El plano de datos se encarga de aceptar un paquete y reenviarlo al destino correcto.
• Plano de control
  
  • Por lo general, el plano de control determina adónde se reenvían los datos. Los protocolos de enrutamiento son buenos ejemplos de funciones del plano de control, al igual que la toma de decisiones de nivel superior, que hoy en día puede ser más dinámica. La implementación concreta varía y puede ir desde que el plano de datos transfiera los datos al plano de control para que este tome una decisión hasta que el plano de control observe los datos de forma transparente y actúe ante determinados desencadenantes. Los planos de control también suelen encargarse de supervisar el estado de los dispositivos y recopilar estadísticas.
• Plano de gestión
  
  • El plano de gestión es el más visible de los tres, ya que es donde interactuamos con el plano de control. Los planos de gestión tradicionales utilizan CLI (interfaces de línea de comandos), mientras que los modernos prefieren API (interfaces de programación de aplicaciones). Independientemente del método utilizado, el plano de gestión permite a los operadores establecer políticas que aplica el plano de control. Esto incluye opciones de configuración como algoritmos de equilibrio de carga y políticas de autorización o denegación basadas en características como la dirección IP y el tipo de dispositivo.

Pero hay otro tipo de orquestación que funciona entre bastidores y que, en gran medida, pasa desapercibida para los operadores. No tiene nada que ver con la gestión, salvo que está asumiendo algunas responsabilidades que antes recaían en los operadores humanos.

La diferencia aquí es que las acciones se desencadenan automáticamente debido a cambios en el entorno durante la ejecución, en lugar de producirse como parte de un evento de despliegue. Sin embargo, la información sobre lo que ha cambiado es fundamental, lo que significa que debe obtenerse de algún sitio.

En un modelo operativo tradicional, esa información suele proceder de tickets o solicitudes de cambio. En el caso de los modelos operativos modernos y, en concreto, de los contenedores, esta información procede de los registros de servicios mediante un mecanismo de descubrimiento.

Registros y descubrimiento de servicios

La naturaleza de los entornos de contenedores parte de la premisa de que, en la práctica, las direcciones IP no son relevantes para el entorno de la aplicación. Sin embargo, sí lo son para la infraestructura, ya que los datos deben seguir enrutándose y reenviándose de un dispositivo a otro para recorrer el trayecto entre el cliente y la aplicación. En los entornos modernos, esas direcciones IP suelen existir durante periodos breves (el tiempo de vida de un contenedor o servicio).

Tenga en cuenta estas conclusiones de DataDog (énfasis añadido):

La rápida adopción de los orquestadores (véase el dato 4) parece estar reduciendo aún más la vida útil de los contenedores, ya que su inicio y detención automatizados generan una mayor tasa de rotación. En las organizaciones que utilizan un orquestador, la vida útil habitual de un contenedor es de unas 12 horas. En las organizaciones sin orquestación, un contenedor dura una media de seis días.

_{Fuente: <https://www.datadoghq.com/docker-adoption>}

Imagine que usted, como operador, tuviera que actualizar las tablas de enrutamiento o los grupos de balanceo de carga cada seis días, por no hablar de cada doce horas. Apenas podría dedicarse a otra cosa. El riesgo de que se produjeran errores de configuración sería considerable y probablemente aumentaría cuanto más tiempo se viera obligado a trabajar en modo manual para gestionar los cambios en un clúster de contenedores.

Un registro de servicios, como Consul, se convierte en un componente fundamental del despliegue de contenedores. Los registros de servicios realizan un seguimiento de las instancias y los servicios, así como de sus direcciones IP asociadas. En este sentido, pueden compararse con un «DNS para contenedores y servicios».

Así, el registro de servicios realiza un seguimiento de las características actuales de los contenedores del clúster. El descubrimiento es el proceso de conectarse al registro de servicios (mediante una API o suscribiéndose a una cola de mensajes) para asociar las instancias con direcciones IP.

Esto significa que la infraestructura que necesite dirigir el tráfico a un servicio o una instancia específicos dentro de un clúster de contenedores debe poder obtener una dirección IP. Porque, por mucho que los contenedores oculten la red a la aplicación, siguen dependiendo de ella para trasladar los datos de un lugar a otro.

El cuarto plano: orquestación

Esto introduce una nueva capa arquitectónica en la infraestructura que interactúa con los entornos de orquestación de contenedores. Esta capa —la capa de orquestación— se integra con el entorno de contenedores y utiliza funciones como la detección de servicios para automatizar la identificación de servicios e instancias. De este modo, un equilibrador de carga puede detectar automáticamente los miembros de un grupo y actualizarlo continuamente en función de los cambios en el entorno. Esto evita que el equipo de operaciones tenga que actualizar manualmente los grupos de equilibrado de carga, una tarea cada vez más tediosa cuando los contenedores tienen una vida media inferior a una semana.

Este plano no está pensado para la interacción con los operadores. La configuración, la supervisión y las operaciones se siguen llevando a cabo a través de un plano de gestión. La ubicación de un registro de servicios se configuraría mediante el plano de gestión, pero el plano de orquestación la utilizaría para conectarse al plano de control y comunicarle los cambios.

Podemos definir el plano de orquestación de la siguiente manera.

• El plano de orquestación es uno de los planos menos visibles de la arquitectura de infraestructura. La interacción con él se lleva a cabo a través del plano de gestión, cuya principal función es dirigir el plano de orquestación al registro de servicios adecuado. Su responsabilidad consiste en actualizar los componentes dinámicos del plano de control para garantizar el encaminamiento correcto y la disponibilidad de los recursos en contenedores.

Sigue sin estar claro si este plano debería integrarse en el dispositivo junto con los planos de control y de datos, o si se trata simplemente de una capa superpuesta sobre el plano de gestión (lo que modificaría ligeramente nuestro diagrama, pero no afectaría a la interacción entre los planos y los componentes). Muchos dispositivos tradicionales ya son compatibles con este plano emergente mediante extensiones que se integran con entornos de contenedores y realizan cambios a través del plano de gestión. Este es un buen ejemplo de cómo refactorizar las arquitecturas tradicionales para ampliar su funcionalidad a entornos modernos. Sin embargo, puede que, en última instancia, no sea la solución ideal.

¿Por qué es importante?

Al principio puede parecer que la introducción de un cuarto plano para la infraestructura no tiene importancia. Al fin y al cabo, su función es liberar a los operadores de parte de la responsabilidad de realizar tareas tediosas. Eso no puede ser malo.

No es algo malo, pero es importante comprender que este paso de una configuración estática a una dinámica tiene consecuencias para algunas de las funciones más importantes del plano de control. El descubrimiento de servicios adquiere tal importancia crítica que garantizar su disponibilidad y seguridad debe ser una prioridad. En la práctica, se convierte en el único punto de fallo del que depende toda la infraestructura de la aplicación.

Los registros de servicios se basan en las mismas premisas que sustentan la mayoría de las aplicaciones modernas: están diseñados para hacer frente a los fallos. Puede darse una situación en la que la dirección IP que acaba de descubrir desaparezca antes de que pueda reenviar el tráfico a su instancia. La mayoría de las infraestructuras pueden retransmitirlo en ese momento, pero el proceso lleva tiempo. En la economía digital, los microsegundos importan, por lo que las opciones tradicionales, como los tiempos de espera y los intervalos de detección, marcarán la diferencia en las arquitecturas modernas que dependen del descubrimiento de servicios. La supervisión también adquiere mucha más importancia, ya que la capacidad de determinar el estado y la disponibilidad lo antes posible puede marcar la diferencia entre un usuario satisfecho y uno que deje de interactuar. Ambas son cuestiones empresariales que todos los miembros de una organización moderna deberían tener presentes e incorporar a sus propias métricas y expectativas.

La implementación del plano de orquestación en su infraestructura, así como la elección del registro de servicios, se convierten en factores importantes a la hora de decidir qué tecnología utilizar. Sopese detenidamente sus opciones, ya que afectan tanto a la disponibilidad como al rendimiento de las aplicaciones suministradas mediante arquitecturas basadas en contenedores.

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