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.
Nous intégrons les fonctions d'équilibrage de charge nativement aux pods/nœuds via des services légers fonctionnant en tâche de fond. Bien que limitées (un peu plus avancées qu’un simple équilibrage de charge réseau), elles accomplissent parfaitement leur rôle. Vous pouvez brancher ces services, ce qui laisse la porte ouverte à d’autres projets (libres ou commerciaux) offrant des capacités plus poussées (et, espérons-le, des algorithmes plus performants).
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 applique les politiques décrites dans les fichiers de ressources pour déterminer comment la répartir. Il peut dispatcher uniformément, ou envoyer 75 % vers une version du service et 25 % vers une autre. Il offre une grande souplesse à cet égard. Le contrôleur d’entrée assure aussi la surveillance (santé et état) et veille attentivement à ne pas acheminer une requête vers 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 comprenez en quoi ils sont semblables, je tiens à vous assurer qu’il existe quelques différences. Notamment, un contrôleur d’ingress se configure de manière déclarative. Autrement dit, une description dans un fichier ressource, externe au contrôleur, détermine sa configuration. Il ne s’agit pas de proxys intelligents traditionnels qui contrôlent et dirigent le trafic d’ingress. Ces proxys traditionnels sont des sources faisant autorité dans l’environnement. Un contrôleur d’ingress ne l’est pas. Il puise cette information ailleurs, dans des fichiers servant de « couche d’abstraction » pour offrir de la flexibilité dans les mises en œuvre. Il doit alors lire, interpréter ces fichiers et créer la configuration correspondante à cette description, ou déléguer cela à un composant complémentaire. Il doit aussi maintenir cette configuration à jour. Même si la variabilité du contrôle d’ingress au sein d’un environnement conteneurisé est plus faible qu’au cœur du système, elle évolue et nécessite une surveillance constante.
En résumé, le contrôleur d’ingress gère le routage au niveau applicatif des requêtes externes vers la ressource adaptée au sein de l’environnement conteneurisé. C’est précisément ce que fait un équilibreur de charge intelligent.
Le nom a peut-être changé, mais les fonctions restent sensiblement les mêmes.