La mise à l’échelle des conteneurs ne se résume pas simplement à placer un proxy devant un service et à s’en aller. La mise à l’échelle ne se limite pas à la distribution. Dans le monde en constante évolution des conteneurs, cinq capacités distinctes sont nécessaires pour garantir la mise à l’échelle : les nouvelles tentatives, les disjoncteurs, la découverte, la distribution et la surveillance.
Dans cet article sur l’art de mettre à l’échelle les conteneurs, nous allons approfondir la découverte.
Les modèles traditionnels d’échelle ont une configuration assez rigide. Les proxys d’équilibrage de charge s’appuient sur un algorithme pour choisir une ressource dans un pool de ressources plutôt statique. La sélection de la ressource (répartition) se fait en temps réel et prend en compte des variables immédiates comme la charge et les temps de réponse, mais l’environnement global reste statique. Vous ajoutez ou retirez des ressources selon des processus définis par l’entreprise qui régulent l’augmentation ou la réduction de la capacité.
Les modèles modernes d'échelle sont naturellement volatils et dynamiques. L’échelle dans les systèmes modernes repose sur l’automatisation de tout. L’auto-échelle, concrétisée par le cloud, impose d’ajuster automatiquement les pools de ressources selon la demande. Pourtant, cela reste un pas partiel par rapport aux modèles traditionnels. Vous trouvez toujours un pool « central » de ressources où un algorithme d’équilibrage de charge opère sa sélection. Ce pool peut s’agrandir ou se réduire dynamiquement, mais il reste limité par le modèle assez traditionnel dans lequel il s'inscrit.
Les conteneurs – notamment dans les environnements d’orchestration – rompent totalement avec ce modèle. Le concept de point de terminaison (l’ingress) reste l’un des rares éléments « fixes » à l’échelle des conteneurs, tandis que tout le reste, des règles de routage aux ressources du pool de support, varie largement. En théorie, un conteneur peut n’exister que quelques secondes. En pratique, ils durent généralement plusieurs jours. Face aux modèles traditionnels où les ressources restent en place des mois, voire des années, cette durée de vie impose une pression aux opérateurs que seule l’automatisation peut soulager.
La découverte joue un rôle clé pour faire évoluer les conteneurs. Vous devez permettre aux proxys d’équilibrage de charge de choisir une ressource dans un pool qui peut varier d’un instant à l’autre. C’est pourquoi la plupart des environnements d’orchestration de conteneurs intègrent un « registre » des ressources pour aider les proxys à les découvrir en temps réel et assurer la montée en charge.
Ce processus exige que les proxys s’intègrent pleinement à l’écosystème d’orchestration de conteneurs et utilisent la langue commune à ces environnements : les fichiers de configuration déclarative (fichiers de ressources) et les métadonnées permettent aux proxys d’identifier les ressources liées aux services qu’ils mettent à l’échelle. Ainsi, les proxys ajustent automatiquement leurs « pools » de ressources en temps réel, évitant de sélectionner une ressource déjà arrêtée, ce qui serait contre-productif.
Sans découverte, un proxy d’équilibrage de charge ne peut pas faire évoluer efficacement les applications et services dans un environnement de conteneurs. Vous ne pourriez suivre le rythme des changements dans un tel environnement qu’avec beaucoup de difficultés si vous utilisiez des méthodes de configuration manuelles. Gérer simplement quelles ressources sont actives et liées à chaque service vous prendrait presque tout votre temps, vous laissant peu de marge pour appliquer les modifications nécessaires.
Discovery offre aux composants d’un environnement d’orchestration de conteneurs la capacité de fonctionner en temps réel, et permet aux proxys d’équilibrage de charge de faire évoluer vos applications et services en leur fournissant les informations nécessaires pour sélectionner les ressources à la demande.