Cómo los entornos de orquestación de contenedores impactan la monitorización del estado

En el corazón de la disponibilidad está la monitorización. Cada balanceador de carga, antes de elegir un recurso de destino, debe saber si ese recurso está realmente disponible o no. De lo contrario, ¿qué sentido tendría?

En entornos donde los recursos tienen una vida útil que puede medirse en minutos en lugar de horas o días, se vuelve aún más crítico conocer el estado de los recursos antes de tomar la decisión de enviarles una solicitud.

La monitorización de la salud es parte integral de los balanceadores de carga y los servidores proxy. Esto también es cierto (o debería ser cierto) en entornos de contenedores. A medida que estos entornos continúan madurando (rápidamente), vemos surgir nuevos modelos de monitoreo para combatir los desafíos un tanto singulares asociados con estos sistemas distribuidos y altamente volátiles.

El monitoreo de salud tradicional ciertamente es parte de la ecuación, pero algunos modelos de disponibilidad y escala dentro de entornos de contenedores generan presiones en el monitoreo de salud tradicional que deben abordarse. Por ejemplo, se espera que los servidores proxy implementados en un modelo de servidor proxy directo puedan seleccionar un objetivo saludable (disponible) entre todos los servicios posibles. Mientras que un proxy inverso (un balanceador de carga tradicional, por así decirlo) solo es responsable de rastrear el estado de un conjunto muy específico de servicios para una sola aplicação, un proxy directo es responsable de conocer el estado de cada servicio para cada aplicação en el entorno. Porque enviar una solicitud a un contenedor que ya está fuera de servicio sería malo, ¿de acuerdo?

Monitoreo de la salud tradicional

Tradicionalmente, el seguimiento de la salud se realiza mediante un proxy de dos maneras:

• Monitoreo activo: Enviar sondas o solicitudes de verificación de estado a los contenedores y evaluar sus respuestas.
• Monitoreo pasivo: Observar las solicitudes naturales de los clientes y sus respuestas.

Se puede imaginar que la monitorización activa por parte de cada proxy de avance de cada servicio va a aumentar drásticamente el tráfico en la red local y consumir recursos innecesariamente. Una monitorización útil se produce al menos en las capas TCP y, idealmente, en las HTTP. Después de todo, la conectividad de la red no es un indicador de la salud o disponibilidad del servicio. El consumo de conexiones TCP y la exigencia de procesamiento HTTP rápidamente impondrán cargas sobre los contenedores a medida que aumenta el número de nodos (y, por tanto, de servidores proxy de reenvío). No desea tener que ampliar la escala porque los contenedores están sobrecargados por la supervisión.

El monitoreo pasivo es una mejor opción en este caso, ya que no supone una carga para el sistema que se está monitoreando, pero tiene sus limitaciones en algunos entornos de contenedores. Muchos se basan en principios de redes superpuestas que dificultan garantizar que cada proxy pueda ver cada respuesta del servicio y rastrearla. No es imposible, pero sí desafiante en la capa de red.

Ambos modelos también suponen una carga para el propio proxy, ya que requieren que los recursos se dediquen únicamente a supervisar el entorno en lugar de a la tarea que están diseñados para realizar: escalar los servicios.

Monitoreo de salud en contenedores 

Los entornos de contenedores no son ajenos a estos desafíos. En respuesta, estamos viendo surgir dos nuevos modelos que seguramente ayudarán a garantizar la disponibilidad en arquitecturas que emplean servidores proxy de avance para disponibilidad y escala.

Estos dos modelos son:

• Monitoreo ambiental: Los servidores proxy conocen el estado y la disponibilidad gracias a la información del entorno de orquestación de contenedores (COE) sobre el estado del contenedor.
• Monitoreo compartido: Dado que es probable que haya muchos servidores proxy en un entorno, el trabajo de monitoreo se puede dividir entre ellos y compartir los resultados.

El monitoreo ambiental a menudo se asocia con el registro de servicios, que rastrea los contenedores a medida que entran y salen del sistema. Eso significa que a menudo es la fuente más confiable de disponibilidad de contenedores en el sistema. Los servidores proxy también pueden suscribirse a eventos desencadenados por la creación y destrucción de contenedores para realizar un seguimiento de esos recursos (en efecto, actuando como un registro ellos mismos).

Por ejemplo, si el monitoreo de salud está habilitado para una aplicación en Marathon, un proxy puede usar el campo 'healthCheckResults'. En Kubernetes, los proxies pueden usar comprobaciones de actividad y/o preparación. Los controles de salud ambiental permiten que los servidores proxy comiencen a seleccionar puntos finales más saludables antes de que el sistema de orquestación reinicie uno que no lo esté.

La monitorización compartida tiene mucho sentido en sistemas que emplean modelos de proxy directo, especialmente aquellos con una base de malla de servicios como Istio . El proxy asociado con el nodo ciertamente puede monitorear la salud y disponibilidad de aquellos contenedores para los cuales envía solicitudes (de la misma manera en que podría realizar un seguimiento de los servicios en un modelo de proxy inverso). Pero ciertamente no quieres que cada proxy investigue activamente cada punto final en un sistema de este tipo. De este modo, al compartir información sanitaria local con otros servidores proxy (o con el entorno, mejor aún), todos los servidores proxy pueden obtener el estado completo conocido del sistema sin necesidad de realizar comprobaciones de salud excesivas en cada servicio.

Se están produciendo muchos cambios en “la red” con respecto a los servicios de aplicaciones, como el equilibrio de carga y cómo interactúan para satisfacer las necesidades y requisitos de nuevos modelos como la contenerización. Estos requisitos presionan constantemente a los representantes para que se adapten. Esto se debe a que los servidores proxy son una de las tecnologías más flexibles que se han desarrollado en los últimos veinte años y siguen siendo una base importante sobre la que se diseñan, desarrollan e implementan los servicios de aplicaciones.