Cet article a été initialement publié sur TheNewStack.

Par Matt Zand et Jim Sullivan

Kubernetes est une solution conteneurisée. Il fournit des environnements d’exécution virtualisés appelés Pods, qui hébergent un ou plusieurs conteneurs pour fournir un environnement d’exécution virtuel. Un aspect important de Kubernetes est la communication des conteneurs au sein du pod. De plus, un domaine important de la gestion du réseau Kubernetes est de transférer les ports de conteneurs en interne et en externe pour s’assurer que les conteneurs d’un pod communiquent correctement entre eux. Pour gérer ces communications, Kubernetes propose les quatre modèles de mise en réseau suivants:

• Communications de conteneur à conteneur
• Communications de pod à pod
• Communications pod-à-service
• Communications externes à internes

Dans cet article, nous nous intéressons aux communications de conteneur à conteneur, en vous montrant comment les conteneurs d’un pod peuvent se mettre en réseau et communiquer.

Communication entre les conteneurs dans un pod

Le fait de disposer de plusieurs conteneurs dans un seul pod permet de communiquer facilement entre eux. Ils peuvent le faire en utilisant plusieurs méthodes différentes. Dans cet article, nous discutons plus en détail de deux méthodes: i- Volumes partagés et ii-Communications inter-processus.

I- Volumes partagés dans un pod Kubernetes

Dans Kubernetes, vous pouvez utiliser un volume Kubernetes partagé comme moyen simple et efficace de partager des données entre les conteneurs d’un pod. Dans la plupart des cas, il suffit d’utiliser un répertoire sur l’hôte qui est partagé avec tous les conteneurs d’un pod.

Les volumes Kubernetes permettent aux données de survivre aux redémarrages du conteneur, mais ces volumes ont la même durée de vie que le pod. Cela signifie que le volume (et les données qu’il contient) existe exactement aussi longtemps que ce pod existe. Si ce pod est supprimé pour une raison quelconque, même si un remplacement identique est créé, le volume partagé est également détruit et créé à partir de zéro.

Un cas d’utilisation standard pour un pod multiconteneur avec un volume partagé est lorsqu’un conteneur écrit des journaux ou d’autres fichiers dans le répertoire partagé, et l’autre conteneur lit à partir du répertoire partagé. Par exemple, nous pouvons créer un Pod comme ceci:

Dans cet exemple, nous définissons un volume nommé html. Son type est emptyDir, ce qui signifie que le volume est créé pour la première fois lorsqu’un pod est affecté à un nœud et existe tant que ce pod est exécuté sur ce nœud; comme son nom l’indique, il est initialement vide. Le premier conteneur exécute le serveur Nginx et a le volume partagé monté dans le répertoire / usr / share / nginx / html. Le deuxième conteneur utilise l’image Debian et a le volume partagé monté dans le répertoire / html. Toutes les secondes, le deuxième conteneur ajoute la date et l’heure actuelles dans le fichier index.html, qui se trouve dans le volume partagé. Lorsque l’utilisateur envoie une requête HTTP au pod, le serveur Nginx lit ce fichier et le transfère à l’utilisateur en réponse à la requête. Ici est un bon article pour en savoir plus sur des sujets Kubernetes similaires.

Vous pouvez vérifier que le pod fonctionne soit en exposant le port nginx et en y accédant à l’aide de votre navigateur, soit en vérifiant le répertoire partagé directement dans les conteneurs:

II- Communications Inter-Process (IPC)

Les conteneurs d’un pod partagent le même espace de noms IPC, ce qui signifie qu’ils peuvent également communiquer entre eux à l’aide de communications inter-processus standard telles que les sémaphores SystemV ou la mémoire partagée POSIX. Les conteneurs utilisent la stratégie du nom d’hôte localhost pour la communication au sein d’un pod.

Dans l’exemple suivant, nous définissons un pod avec deux conteneurs. Nous utilisons la même image Docker pour les deux. Le premier conteneur est un producteur qui crée une file d’attente de messages Linux standard, écrit un certain nombre de messages aléatoires, puis écrit un message de sortie spécial. Le deuxième conteneur est un consommateur qui ouvre cette même file d’attente de messages pour la lecture et lit les messages jusqu’à ce qu’il reçoive le message de sortie. Nous avons également défini la politique de redémarrage sur «Jamais», de sorte que le pod s’arrête après l’arrêt des deux conteneurs.

Pour vérifier cela, créez le pod à l’aide de kubectl create et observez l’état du pod:

Vous pouvez maintenant vérifier les journaux de chaque conteneur et vérifier que le deuxième conteneur a reçu tous les messages du premier conteneur, y compris le message de sortie:

Cependant, il y a un problème majeur avec ce pod, et il a à voir avec le démarrage des conteneurs.

Conclusion

La principale raison pour laquelle les pods peuvent avoir plusieurs conteneurs est de prendre en charge les applications d’assistance qui aident une application principale. Des exemples typiques d’applications d’assistance sont les extracteurs de données, les pousseurs de données et les proxies. Un exemple de ce modèle est un serveur Web avec un programme d’assistance qui interroge un référentiel git pour les nouvelles mises à jour.

Le volume de cet exercice permet aux conteneurs de communiquer pendant la durée de vie du pod. Si le pod est supprimé et recréé, toutes les données stockées dans le volume partagé sont perdues. Dans cet article, nous avons également abordé le concept de communications inter-processus entre les conteneurs d’un pod, qui est une alternative aux concepts de volume partagé. Maintenant que vous découvrez comment les conteneurs à l’intérieur d’un pod peuvent communiquer et échanger des données, vous pouvez passer à d’autres modèles de mise en réseau Kubernetes, tels que les communications pod-à-pod ou pod-à-service. Ici est un bon article pour apprendre des sujets plus avancés sur le développement Kubernetes.

à propos des auteurs

La poste Examen des communications de conteneur à conteneur dans Kubernetes est apparu en premier le Linux Foundation – Formation.