Impact des environnements d'orchestration de conteneurs sur la surveillance de l'état de santé

La surveillance constitue le fondement de la disponibilité. Avant de sélectionner une ressource, chaque équilibreur de charge vérifie sa disponibilité réelle. Sinon, quel intérêt ?

Dans les environnements où les ressources vivent seulement quelques minutes, pas des heures ou des jours, vous devez absolument connaître leur état avant d’envoyer une requête.

La surveillance de la santé fait partie intégrante des équilibreurs de charge et des proxys. C’est également vrai (ou devrait l’être) dans les environnements conteneurisés. À mesure que ces environnements continuent de mûrir (rapidement), nous voyons de nouveaux modèles de surveillance émerger pour lutter contre les défis quelque peu uniques associés à ces systèmes distribués extrêmement volatils.

La surveillance de santé traditionnelle fait certainement partie de l’équation, mais certains modèles de disponibilité et d’échelle au sein des environnements de conteneurs exercent des pressions sur la surveillance de santé traditionnelle qui doivent être traitées. Par exemple, les proxys déployés dans un modèle de proxy direct sont censés pouvoir sélectionner une cible saine (disponible) parmi tous les services possibles. Alors qu'un proxy inverse (un équilibreur de charge traditionnel, si vous voulez) est uniquement responsable du suivi de l'état d'un ensemble très spécifique de services pour une seule application, un proxy direct est chargé de connaître l'état de chaque service pour chaque application de l'environnement. Parce qu'envoyer une requête à un conteneur déjà hors service serait une mauvaise chose, d'accord ?

Surveillance traditionnelle de la santé

Traditionnellement, la surveillance de la santé est réalisée par un proxy de deux manières :

• Surveillance active : Envoi de sondes ou de demandes de contrôle de santé aux conteneurs et évaluation de leurs réponses.
• Surveillance passive : Observer les demandes naturelles des clients et leurs réponses.

Vous imaginez qu’une surveillance active par chaque proxy de transfert pour chaque service augmenterait considérablement le trafic sur le réseau local et utiliserait des ressources inutilement. La surveillance utile se fait au minimum aux couches TCP et, idéalement, HTTP. La connectivité réseau ne garantit pas la santé ni la disponibilité d’un service. Gérer les connexions TCP et traiter le HTTP alourdit rapidement les conteneurs, surtout quand le nombre de nœuds (et donc de proxies de transfert) augmente. Vous ne voulez pas devoir monter en capacité parce que la surveillance surcharge vos conteneurs.

La surveillance passive est une meilleure option dans ce cas, dans la mesure où elle n’impose pas de charge au système surveillé, mais elle présente ses limites dans certains environnements de conteneurs. Beaucoup d’entre eux sont construits sur des principes de réseau superposé qui rendent difficile de garantir que chaque proxy peut voir chaque réponse de service et la suivre. Ce n’est pas impossible, mais cela représente un défi au niveau du réseau.

Ces deux modèles sollicitent aussi le proxy lui-même, ce qui oblige à consacrer des ressources uniquement à la surveillance de l’environnement au lieu de se concentrer sur la mise à l’échelle des services qu’il doit assurer.

Surveillance de la santé conteneurisée 

Les environnements de conteneurs ne sont pas ignorants de ces défis. En réponse, nous voyons émerger deux nouveaux modèles qui contribueront certainement à garantir la disponibilité dans les architectures utilisant des proxys de transfert pour la disponibilité et l’évolutivité.

Ces deux modèles sont :

• Surveillance environnementale : Les proxys sont informés de l'état de santé/disponibilité grâce aux informations de l'environnement d'orchestration des conteneurs (COE) sur l'état de santé des conteneurs.
• Surveillance partagée : Comme il est probable qu’il y ait de nombreux proxys dans un environnement, le travail de surveillance peut être divisé entre les proxys et les résultats partagés.

La surveillance de l’environnement s’appuie souvent sur le registre des services, qui suit les conteneurs dès leur arrivée et jusqu’à leur départ du système. Cela en fait souvent la source la plus fiable pour connaître la disponibilité des conteneurs dans le système. Les proxys peuvent aussi s’abonner aux événements liés à la création et à la suppression des conteneurs pour gérer eux-mêmes ces ressources, jouant ainsi le rôle de registres.

Par exemple, si la surveillance de la santé est activée pour une application dans Marathon, un proxy peut utiliser le champ « healthCheckResults ». Dans Kubernetes, les proxys peuvent utiliser des contrôles de vivacité et/ou de préparation. Les contrôles de santé environnementaux permettent aux proxys de commencer à sélectionner des points de terminaison plus sains avant que le système d'orchestration ne redémarre un point de terminaison non sain.

La surveillance partagée est très judicieuse dans les systèmes utilisant des modèles de proxy direct, notamment ceux dotés d'une base de service mesh comme Istio . Le proxy associé au nœud peut certainement gérer la santé et la disponibilité des conteneurs pour lesquels il transmet les demandes (de la même manière qu'il pourrait suivre les services dans un modèle de proxy inverse). Mais vous ne voulez certainement pas que chaque proxy sonde activement chaque point de terminaison dans un tel système. Ainsi, en partageant les informations de santé locales avec d’autres proxys (ou avec l’environnement, mieux encore), l’intégralité de l’état connu du système peut être obtenue par tous les proxys sans nécessiter de contrôles de santé excessifs sur chaque service.

De nombreux changements sont en cours dans « le réseau » en ce qui concerne les services d’application tels que l’équilibrage de charge et la manière dont ils interagissent pour répondre aux besoins et aux exigences de nouveaux modèles comme la conteneurisation. Ces exigences exercent une pression constante sur les mandataires pour qu’ils s’adaptent. C’est parce que les proxys sont l’une des technologies les plus flexibles à avoir été développées au cours des vingt dernières années et continuent d’être une base importante sur laquelle les services d’application sont conçus, développés et déployés.