Pods
Dans Kubernetes, les pods sont les seules unités déployables. Si une application doit être déployée, elle doit être déployée dans un pod en tant que conteneur. Bien que les applications s’exécutent dans des conteneurs, les conteneurs doivent faire partie du pod. La spécification Pod a des conteneurs d’attributs où les spécifications de conteneur sont déclarées. L’attribut est au pluriel. Cela signifie que nous pouvons déclarer plusieurs conteneurs dans une spécification de pod.
Considération de conception multi-conteneurs
Mais les administrateurs Kubernetes choisissent toujours un pod conteneur plutôt que des pods multi-conteneurs. Un conteneur par pod est une pratique non écrite dans l’ensemble de l’industrie. Voyons quel est l’avantage d’un pod multi-conteneurs.
Le Pod a une IP. Tous les conteneurs du Pod partagent la même IP. Si un volume est créé pour le pod, tous les conteneurs qui font partie du pod peuvent le monter. Ainsi, les conteneurs peuvent partager le stockage. Ils peuvent également communiquer entre eux via localhost.
Dans ce cas, pourquoi les pods One Container sont toujours préférés. Prenons le cas d’utilisation d’une application Web dotée de niveaux d’interface utilisateur, de backend, de base de données et de messagerie. Nous déploierons les quatre niveaux sous forme de quatre conteneurs dans un seul pod. Les exigences en matière de ressources, de configuration et de fonctionnement sont différentes pour les quatre conteneurs. Le backend et le frontend sont orientés client. S’il y avait une exigence pour les mettre à l’échelle aux niveaux, cela ne peut pas être fait séparément, car nous ne pouvons pas mettre à l’échelle des conteneurs mais des pods. Ainsi, si nous augmentons le pod, plusieurs instances de base de données et de niveau de messagerie seront également créées, bien que cela ne soit pas nécessaire.
Par conséquent, il est préférable de les déployer séparément, car il serait préférable de les gérer et de les mettre à l’échelle en tant que pods individuels. 
Dans quel cas pourrait-on alors utiliser plusieurs conteneurs dans le même Pod ?
Cas 1 – Si le cycle de vie des conteneurs est le même.
Cas 2 – Si deux conteneurs sont très fortement couplés
Cas 3 – Si nous devons rendre notre application déployable sur Kubernetes sans aucun changement de code. Ce serait dans de tels cas où le code de l’application manque de quelque chose pour tirer parti des fonctionnalités de Kubernetes. Dans ce cas, nous pouvons apporter un conteneur secondaire avec notre conteneur d’application qui brisera une telle barrière.
Modèles de conception multi-conteneurs
Modèle d’adaptateur
Nos maisons sont alimentées en courant alternatif tandis que les ordinateurs portables que nous utilisons consomment en courant continu. Dans ce cas, nous utilisons des adaptateurs secteur qui tirent le courant des prises secteur, puis le convertissent en courant continu et alimentent l’ordinateur portable. Sans changer le mode d’alimentation chez nous, nous pourrions recharger nos ordinateurs portables à l’aide d’un adaptateur.
Comment pouvons-nous le relier à Kubernetes ? Par exemple, si nous avons installé un outil de surveillance centralisé dans le cluster Kubernetes, qui nécessite que tous les journaux d’applications soient imprimés au format « APP-NAME – HOSTNAME – DATE – SEVERITY ». Mais le cluster pourrait avoir de nombreuses applications écrites dans une variété de langues imprimant des journaux dans une variété de formats. Dans ce cas, il ne serait pas judicieux que toutes les applications modifient leur format de journalisation comme si l’outil changeait à l’avenir et que le format devait changer à nouveau. Pour résoudre ce problème, nous pouvons générer un deuxième conteneur qui lit les journaux du conteneur principal de l’application, les traite dans le format souhaité par l’outil de surveillance. Problème résolu.
Modèle Ambassadeur
Un ambassadeur est un émissaire qui représente son pays à l’extérieur. Comment peut-il nous aider dans Kubernetes Pod ?
Prenons un exemple. Vous avez une application héritée où l’URL de la base de données est codée en dur dans l’application en tant que localhost. Il est difficile de modifier les applications héritées car cela entraîne des changements dans de nombreux autres endroits. Si vous devez le rendre déployable dans le cluster Kubernetes, vous devez modifier le code. Vous pouvez le faire sans changement de code en utilisant un modèle Ambassador. Un conteneur ambassadeur co-localise un conteneur d’applications dans le même pod. Il fonctionne comme un proxy. Il se connecte à la bonne base de données en fonction de l’environnement Dev, QA ou Stage.
L’application principale peut se connecter à des URL externes telles que localhost via le conteneur ambassadeur. Le modèle ambassadeur trouve l’URL correcte et la fournit au conteneur d’application sur localhost. Le conteneur principal de l’application n’a pas à se soucier de l’URL correcte. Celui-ci est affecté au conteneur ambassadeur.
Modèle de side-car
Un side-car est attaché à une moto. Il ajoute un siège ou deux à la moto sans aucune modification. Il ne fait pas partie intégrante du vélo, mais il améliore les capacités du vélo. Un conteneur side-car se comporte également de la même manière. Il améliore la capacité du conteneur principal déployé avec lui, sans apporter de modifications au conteneur principal. Par exemple, si vous avez une application qui génère des fichiers journaux dans un certain dossier.
Si votre outil de surveillance des applications dans le cluster Kubernetes a besoin que les journaux soient stockés dans un stockage externe pour toutes les applications déployées sur le cluster, cela ne peut tout simplement pas être fait au niveau de l’application. Nous pourrions plutôt utiliser un conteneur side-car qui stockera facilement les fichiers journaux dans le stockage requis sans modifier le code au niveau de l’application principale.
Conclusion
Tous ces modèles sont très utiles pour effectuer des travaux transversaux sans modifier l’application principale. Ils prennent en charge le conteneur principal et doivent être déployés en tant que conteneurs secondaires. Ces charges de travail doivent être écrites de manière à pouvoir être réutilisables dans différents pods.
Pour expliquer cette approche, le modèle d’adaptateur a été utilisé où nous devons convertir ou traiter la sortie du conteneur principal dans un format standard. Le modèle Ambassador est utilisé pour fournir un proxy réseau. Le modèle Sidecar est utilisé pour fournir des services d’assistance/utilitaire au conteneur principal.
Essayez d’utiliser ces modèles pour tirer le meilleur parti de votre cluster Kubernetes.