Arquitectura de la infraestructura: contenedores que crean el cuarto plano
En la infraestructura de red tradicional generalmente hay tres planos arquitectónicos asociados con la infraestructura de red: datos, control y gestión.
Las definiciones exactas de estos pueden variar dependiendo del género y la implementación específica de la infraestructura, pero los arquetipos son en gran medida precisos para la mayoría de las infraestructura de red.
- Plano de datos
- El plano de ruta de datos de datos, es la ruta por la que pasan los paquetes (datos). El plano de datos es responsable de aceptar un paquete y reenviarlo al destino correcto.
- Plano de control
- Generalmente, el plano de control determina dónde se envían los datos. Los protocolos de enrutamiento son buenos ejemplos de funciones de un plano de control, como también lo son las tomas de decisiones de orden superior que hoy en día pueden ser más dinámicas. La implementación específica varía, pero puede ir desde el plano de datos que pasa datos al plano de control para tomar una decisión hasta el plano de control que observa los datos de manera transparente y actúa sobre desencadenantes específicos. Los planos de control a menudo también son responsables de supervisar la salud de los dispositivos y recopilar estadísticas.
- Plano de gestión
- El plano de gestión es el más visible de los tres planos porque es donde interactuamos con el plano de control. Los planos de administración tradicionales utilizan CLI (interfaces de línea de comandos), mientras que los planos de administración modernos prefieren API (interfaces de programación de aplicação ). Independientemente del método utilizado, el plano de administración permite a los operadores establecer políticas que son aplicadas por el plano de control. Esto incluye opciones de configuración como algoritmos de equilibrio de carga y políticas de permitir/denegar basadas en características como la dirección IP y el tipo de dispositivo.
Pero hay otro tipo de orquestación en funcionamiento, que está bajo el capó y en gran medida pasa desapercibida para los operadores. No tiene nada que ver con la gestión, excepto que se trata de apropiarse de algunas responsabilidades de los operadores humanos.
La distinción aquí es que las acciones se activan automáticamente por cambios en el entorno durante la ejecución en lugar de como un evento de implementación. Pero la información sobre lo que ha cambiado es vital y eso significa que debe obtenerse de alguna parte.
En un modelo operativo tradicional, esa información generalmente proviene 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 servicio a través de un mecanismo de descubrimiento.
Registros de servicios y descubrimiento
La naturaleza de los entornos de contenedores incluye el supuesto de que las direcciones IP efectivamente no importan para el entorno de la aplicação . Pero sí son importantes para la infraestructura porque los datos todavía tienen que enrutarse y reenviarse de un dispositivo a otro para poder recorrer la ruta entre el cliente y la aplicação. En entornos modernos, esas direcciones IP a menudo existen durante períodos cortos de tiempo (la vida útil de un contenedor/servicio).
Considere estos hallazgos de DataDog (énfasis añadido):
La rápida adopción de orquestadores ( ver hecho 4 ) parece estar llevando a los contenedores hacia vidas útiles aún más cortas, ya que el inicio y la detención automatizados de los contenedores conducen a una mayor tasa de abandono. En las organizaciones que ejecutan un orquestador, la vida útil típica de un contenedor es de aproximadamente 12 horas. En organizaciones sin orquestación, el contenedor promedio vive seis días.
Desde < https://www.datadoghq.com/docker-adoption >
Imagínese si usted, como operador, tuviera que actualizar las tablas de enrutamiento o los grupos de equilibrio de carga cada seis días, y mucho menos cada doce horas. No harías mucho más. El potencial de una configuración incorrecta sería significativo y probablemente aumentaría cuanto más tiempo estuviera obligado a operar en modo manual para administrar los cambios en un clúster de contenedores.
Un registro de servicios, como Consul , se convierte en un componente crítico de la implementación de su contenedor. Los registros de servicio realizan un seguimiento de las instancias y los servicios y sus direcciones IP asociadas. En este sentido podrían compararse con un «DNS para contenedores y servicios».
De este modo, el registro de servicios realiza un seguimiento de las características actuales de los contenedores en el clúster. El descubrimiento es el proceso de conexión al registro de servicio (a través de API o suscribiéndose a una cola de mensajes) de instancias coincidentes con direcciones IP.
Esto significa que para la infraestructura que necesita enrutar tráfico a un servicio o instancia específica dentro de un clúster de contenedores, debe poder recuperar una dirección IP. Porque por mucho que los contenedores oculten la red a la aplicação, aún dependen de ella para trasladar datos de un lugar a otro.
El cuarto plano: Orquestación
Lo que esto hace es introducir 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 capacidades como el descubrimiento de servicios para automatizar el descubrimiento de servicios e instancias. Esto significa que un balanceador de carga puede descubrir automáticamente los miembros de un grupo y actualizarlo continuamente en función de los cambios en el entorno. Esto alivia la carga de operaciones para actualizar manualmente los grupos de equilibrio de carga, una tarea cada vez más tediosa cuando los contenedores viven en promedio menos de una semana.
Este avión no está diseñado para interactuar con operadores. La configuración, la supervisión y la operación todavía se realizan a través de un plano de gestión. La ubicación de un registro de servicio se configuraría a través del plano de administración, pero sería utilizada por el plano de orquestación para conectar y comunicar cambios al plano de control.
Podemos definir el plano de orquestación de la siguiente manera.
- El plano de orquestación es uno de los planos menos visibles en la arquitectura de infraestructura. La interacción con él se realiza a través del plano de administración, que es el principal responsable de apuntar el plano de orquestación al registro de servicio apropiado. Su responsabilidad es actualizar los componentes dinámicos en el plano de control para garantizar el reenvío y la disponibilidad adecuados de los recursos en contenedores.
Aún quedan dudas sobre si este plano se debe integrar en el dispositivo junto con los planos de control y datos o si es simplemente una capa sobre el plano de administración (lo que cambiaría ligeramente nuestro diagrama pero por lo demás no afectaría la interacción entre planos y componentes). Muchos dispositivos tradicionales ya admiten este plano emergente al proporcionar extensiones que se integran con entornos de contenedores y realizan cambios a través del plano de administración. Este es un buen ejemplo de refactorización de arquitecturas tradicionales para ampliar la funcionalidad en entornos modernos. Pero en última instancia puede que no sea la solución ideal.
¿POR QUÉ ES IMPORTANTE?
Al principio puede parecer que la introducción de un cuarto plano para infraestructura no tiene importancia. Después de todo, su función es quitarle a los operadores parte de la responsabilidad de las tareas tediosas. Eso no puede ser malo
No está mal, pero es importante entender que este paso de la configuración estática a la dinámica tiene consecuencias para algunas de las funciones más importantes del plano de control. La criticidad del descubrimiento de servicios llega a ser tal que su disponibilidad y seguridad deberían ser un imperativo. Se convierte, de hecho, en el único punto de fallo sobre el que se apoya toda la infraestructura de aplicaciones .
Los registros de servicio se basan en las mismas premisas que la mayoría de las aplicações modernas: están diseñados para manejar fallas. Puede terminar en una situación en la que la dirección IP que acaba de descubrir desaparezca antes de que pueda reenviar tráfico a su instancia. La mayoría de la infraestructura es capaz de retransmitir en ese momento, pero el proceso lleva tiempo. Los microsegundos importan en la economía digital, por lo que las opciones tradicionales, como los tiempos de espera y los intervalos de descubrimiento, marcarán una diferencia en las arquitecturas modernas que dependen del descubrimiento. El monitoreo también se vuelve mucho más crítico, ya que la capacidad de determinar la salud y la disponibilidad lo más rápido posible puede marcar la diferencia entre que un usuario esté satisfecho o que se desvincule. Ambas son preocupaciones de nivel empresarial que todos en una organización moderna deberían conocer y tener en cuenta en 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 en su proceso de toma de decisiones con respecto a qué tecnología utilizar. Considere cuidadosamente sus elecciones, ya que afectan tanto la disponibilidad como el rendimiento de las aplicações entregadas a través de arquitecturas basadas en contenedores.