Au cœur de la disponibilité se trouve la surveillance. Chaque équilibreur de charge, avant de choisir une ressource cible, doit savoir si cette ressource est réellement disponible ou non. Sinon, à quoi ça sert ?
Dans les environnements où les ressources ont une durée de vie qui peut être mesurée en minutes plutôt qu'en heures ou en jours, il devient encore plus critique de connaître l'état des ressources avant de prendre la décision de leur envoyer une demande.
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 ?
Traditionnellement, la surveillance de la santé est réalisée par un proxy de deux manières :
Vous pouvez imaginer que la surveillance active par chaque proxy direct de chaque service va augmenter considérablement le trafic sur le réseau local et consommer inutilement des ressources. Une surveillance utile se produit au moins au niveau des couches TCP et idéalement au niveau des couches HTTP. Après tout, la connectivité réseau n’est pas un indicateur de l’état ou de la disponibilité du service. La consommation de connexions TCP et le besoin de traitement HTTP vont rapidement peser sur les conteneurs à mesure que le nombre de nœuds (et donc de proxys de transfert) augmente. Vous ne voulez pas avoir à passer à l’échelle supérieure car les conteneurs sont submergés par la surveillance.
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.
Les deux modèles imposent également une charge au proxy lui-même, exigeant que les ressources soient dédiées à la simple surveillance de l’environnement plutôt qu’à la tâche pour laquelle elles sont destinées : la mise à l’échelle des services.
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 :
La surveillance environnementale est souvent associée au registre de service, qui suit les conteneurs lorsqu’ils entrent et sortent du système. Cela signifie qu’il s’agit souvent de la source la plus fiable en matière de disponibilité des conteneurs dans le système. Les proxys peuvent également s'abonner aux événements déclenchés par la création et la destruction de conteneurs afin de suivre ces ressources elles-mêmes (en agissant en fait comme un registre eux-mêmes).
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.