Kubernetes dans son architecture utilise les pods comme couche d’abstraction pour représenter un service. Et un pod peut contenir un ou plusieurs conteneurs.
En effet, parfois un service a besoin d’autres services(initiation, synchronisation de données, etc) pour pouvoir être totalement fonctionnel. Par exemple pour protéger l’accès a un service http, on peut avoir besoin d’y intégrer un service proxy d’authentification qui va jouer le role de barrière afin de ne laisser l’accès que pour les requêtes autorisées. Ces uses cases nécessitent généralement l’utilisation des design patterns de type multi-conteneurs.
Nous présentons donc ci dessous ceux les plus populaires et quelques cas d’utilisation dans le cadre des application cloud natives.
Le pattern SideCar
Ce pattern est utilisé pour étendre les fonctionnalités d’un conteneur principal, en y ajoutant une fonctionnalité secondaire qui est complètement différente du rôle primaire de ce conteneur.
En fait, les conteneurs ont par définition doivent remplir une seule tâche et la faire correctement. Donc pour respecter cette règle fondamentale, au lieu d’implémenter dans un service un module qui ne cadre pas avec sa fonction de base, on peut utiliser un conteneur secondaire appelé sidecar. Ce dernier va donc implémenter tout autre fonctionnalité nécessaire à une intégration et un fonctionnement efficace de votre application. Le besoin de sidecar intervient dans la majeur partie des cas pour des soucis d’intégration avec les plateformes existantes, et d’homogénéité.
Quelques cas d’utilisation
- Service de synchronisation
Ce service sidecar peut être mis en place pour synchroniser des fichier/dossier d’un dossier distant vers un dossier local pour qu’ils soient consommés par votre conteneur applicatif. A chaque instantiation de l’application, le sidecar va donc aller télécharger les fichiers et les mettre à disposition.
- Gestionnaires de variables d’environnements
Certaines applications ne sont pas facilement configurables écrire leurs logs sur les sorties stdout ou stderr. Vu que ces applications écrivent leur données sur des fichiers distincts du disque, vous pouvez donc les configurer à écrire sur un disque partagé entre conteneurs (emptyDir) et mettre sur pied un sidecar qui va lire dans ces fichiers et envoyer les journaux vers votre système central de logs.
Le pattern Ambassador
L’Ambassador est un conteneur qui permet de connecter le service (conteneur) principal vers le monde extérieur.
Une application se veut d’être robuste, résiliente et tolérante aux pannes relatives aux problèmes réseaux ou d’accès aux services extérieur. Pour cette raison, il faut implémenter certaines routines qui permettent une détection de pannes ou perturbations liées au réseau, une correction ou remédiation de ces problèmes. Ce par le biais des techniques telles que le circuit breaking, le retry, le routage dynamique, les contrôles, …
Comme mentionné précédemment, toutes ces techniques ne sauraient être implémentés sur le conteneur de base, car il ne s’agit pas là du rôle principale du service. En plus il faudrait avoir la possibilité de modifier les librairies ou configuration du routage sans avoir besoin de modifier le service principal et même de courir des risques de régression. De même, avoir la possibilité de donner la responsabilité à une autre équipe de s’occuper des fonctionnalités de routage, de sécurité, communication avec l’extérieur, etc.
L’ambassadeur vient donc dans cet optique jouer le rôle de proxy, entre le service principal et le monde extérieur.
Quelques cas d’utilisation :
- Un ambassador peut permettre l’accès à plusieurs serveurs memcached. Le client va tout le temps se connecter au memcache sur le localhost et l’ambassador va s’occuper de requêter l’un des shards afin de lire ou d’écrire la donnée.
- La communication avec un service distant requérant du mutual tls pour l’authentification. L’ambassadeur va donc ici implémenter le tls, assurer la liaison avec l’autre service.
Le pattern Adapter
Il est courant de nos jour d’avoir diverses équipes travaillant sur un projet, et développants leurs services en utilisants des langages et technologies différentes. Cette hétérogénéité peut souvent être un soucis lorsque les applications doivent être traités de façon unifiée par un composant central de l’infrastructure. Si ce composant doit “comprendre” le langage de chacune de ces applications pour par exemple collecter des informations, cela va rapidement devenir ingérable. L’adaptateur permet de palier à cela en fournissant pour chaque service une interface permettant d’y accéder de la même façon afin de collecter les informations telles que les métriques ou toute autre donnée nécessaire pour les analyses. L’adaptateur va donc masquer la complexité de chaque application, et il sera possible grâce à un seul moyen et protocole de communication d’avoir acces aux donnees de tous les services..
Le cas d’utilisation le plus courant est la collecte des données des applications par l’outil de monitoring. Afin de permettre une collecte simple et uniforme des données, il faudrait qu’elles puissent être formatées de la même façon, d’où le besoin d’utiliser un conteneur de type adapter, qui aura pour rôle de récupérer les metrics exposées par le conteneur principal et les présenter à toute platform externe en utilisant un format commun
