Contrôleurs d'entrée : Nouveau nom, fonction familière
Expressions familières. Ce sont des mots et des expressions qui ont une signification locale unique qui peut dérouter ceux qui ne sont pas originaires de la région. Par exemple, lorsque je suis en déplacement et que j’ai soif, je cherche un abreuvoir. Vous cherchez probablement (en supposant que vous n'êtes pas un « Sconnie ») une fontaine à eau. Dans le Wisconsin, nous mesurons les distances en temps et non en kilomètres. Les feux de circulation sont des feux « stop n' go ». Parce que c’est ce que tu fais.
La phrase préférée de mon mari (il n’est pas natif) pour rire est « Viens une fois ». Je n’essaierai pas de l’expliquer au-delà de ce qui a du sens pour moi et pour les enfants sur lesquels je l’utilise. Et nous comprenons intrinsèquement que « Up North » n’est pas une direction, mais un endroit dont l’emplacement peut être spécifique à l’orateur mais qui porte une connotation commune à tous les natifs du Wisconsin décrivant « cet endroit où nous allons pour échapper à tout ».
Vous avez probablement votre propre liste, ayant grandi ailleurs. Mais c'est mon blog, donc je peux utiliser le mien.
Mais le but aujourd’hui n’est pas de donner une leçon de sémantique en soi, mais plutôt de discuter de son applicabilité à un phénomène plus localisé, juste dans votre propre jardin. Si votre jardin était votre organisation, au moins.
L’essor des conteneurs et de leurs systèmes de contrôle de clustering automatisés, tout à fait nécessaires (souvent appelés orchestration), a eu pour conséquence inattendue de forcer les expressions familières d’un côté à l’autre de la frontière étatique. C'est du développement d'applications intégré à l'informatique proprement dite, soit dit en passant.
Le cas curieux des expressions familières utilisées dans les conteneurs
De nombreuses fonctions requises pour atteindre la flexibilité et la fiabilité d'échelle requises ont nécessité la migration de certains services auparavant réservés à la production vers « l'environnement » du conteneur. Ces fonctions sont désormais apparemment « intégrées » à cet environnement, en utilisant une intégration légère (API et mise en file d’attente de messages) pour réaliser ce qui jusqu’à présent ne pouvait être réalisé qu’à partir d’un environnement de cloud computing entièrement implémenté : des applications à mise à l’échelle automatique et hautement disponibles.
Ce faisant, les fonctions d’équilibrage de charge sont natives des pods/nœuds via de petits services de type démon. Bien qu’ils ne soient pas très avancés (nous parlons à peine de capacités supérieures à l’équilibrage de la charge réseau), ils font le travail pour lequel ils ont été conçus. Ces services peuvent être (et sont) enfichables, si vous voulez, permettant à d'autres projets (open source et fournis par des fournisseurs) de débloquer des capacités plus avancées (et, espérons-le, des algorithmes).
Mais en soi, ces fonctions d’équilibrage de charge ne permettent pas l’évolutivité et la haute disponibilité que nous recherchons en fin de compte (et dont nous avons besoin dans les environnements de production). Ils ne sont pas non plus capables de router les API, qui nécessitent des connaissances HTTP (L7). Nous en avons besoin si nous voulons faire évoluer efficacement des applications modernes soutenues par des microservices et dotées de façades API. Nous avons besoin d’une solution plus robuste.
C'est là que les contrôleurs d'entrée entrent en jeu. Il s’agit des « équilibreurs de charge » qui analysent et dirigent le trafic entrant en fonction des URI et des en-têtes HTTP pour permettre le routage et l’évolutivité de la couche applicative.
Ce qui s'est passé, c'est que les développeurs qui ont créé (et utilisent par la suite) les contrôleurs d'entrée ont essentiellement recréé ce que nous (dans les réseaux) appellerions la gestion du trafic, la distribution d'applications ou la commutation/le routage de contenu. Nous avons utilisé de nombreux termes différents au fil des années dans les réseaux, tout comme dans dev(ops). Le routage des applications et le routage des pages sont également des termes utilisés par les développeurs pour décrire le routage L7. Le concept n’est inconnu à aucun des deux groupes. Mais les termes – les expressions familières – le sont.
Un contrôleur d'entrée est chargé d'acheminer les requêtes vers le service (virtuel) approprié au sein du cluster de conteneurs. Ce service peut être un autre proxy d’équilibrage de charge ou une construction spécifique au système de conteneur. Dans les deux cas, le rôle du contrôleur d’entrée est d’acheminer le trafic en fonction des valeurs de couche 7 (HTTP) dans les en-têtes HTTP d’une requête HTTP. Il s'agit généralement de l'URI, mais il peut s'agir du nom de l'hôte ou d'une autre valeur personnalisée (comme un numéro de version ou une clé API).
Une fois que le contrôleur d’entrée a extrait la valeur de l’en-tête, il utilise les politiques décrites par les fichiers de ressources pour déterminer comment la distribuer. Il peut être distribué de manière égale, ou envoyer 75 % à une version du service et 25 % à une autre. C'est assez flexible de cette façon. Le contrôleur d'entrée a également des responsabilités de surveillance (santé et état) et doit faire très attention à ne pas distribuer une demande à un service « mort ».
Cela vous semble familier, netops ? Cela devrait, car ce sont essentiellement les fonctions d’un proxy intelligent (compatible L7) (comme BIG-IP).
Maintenant que vous savez en quoi ils sont identiques, laissez-moi vous assurer qu'il existe quelques différences. Notamment, un contrôleur d’entrée est configuré de manière déclarative. Autrement dit, sa configuration est déterminée par une description dans un fichier de ressources extérieur au contrôleur lui-même. Cela ne ressemble pas aux proxys intelligents traditionnels qui contrôlent et dirigent le trafic entrant. Les proxys intelligents traditionnels sont des sources faisant autorité sur l’environnement. Un contrôleur d’entrée ne l’est pas. Il cherche cela ailleurs, dans des fichiers qui agissent comme une sorte de « couche d’abstraction » qui permet une flexibilité dans les implémentations. Cela signifie qu'il (ou un composant complémentaire) doit le lire, l'interpréter et créer la configuration appropriée à cette description. Et il faut le maintenir à jour. Bien que la variabilité au niveau du contrôle d'entrée d'un environnement conteneurisé soit moindre que celle au niveau plus profond du système, elle évolue néanmoins et doit être surveillée.
En fin de compte, le contrôleur d’entrée est responsable du routage de la couche d’application des requêtes de l’extérieur vers la ressource appropriée à l’intérieur de l’environnement conteneurisé. Ce qui correspond à peu près à la définition d’un équilibreur de charge intelligent.
Le nom a peut-être changé, mais les fonctions restent sensiblement les mêmes.