À propos des Pods
Les Pods sont la plus petite unité API dans Kubernetes. En termes plus techniques, les Pods sont l’unité de planification atomique dans Kubernetes. Mais pourquoi avons-nous besoin de Pods ? Pour répondre à cette question, nous devons d’abord comprendre l’essence d’un conteneur : un conteneur est essentiellement un processus. C’est exact. Les conteneurs sont des processus dans un système de cloud computing, et les images de conteneurs sont essentiellement des packages d’installation « .exe » pour ce système. Kubernetes, dans cette analogie, agit comme le système d’exploitation.
Processus et groupes de processus
Connectons-nous à une machine Linux et exécutons la commande suivante :
$ pstree -g
Cette commande affiche la structure arborescente des processus en cours d’exécution dans le système. Le résultat pourrait ressembler à ceci :
systemd(1)-+-accounts-daemon(1984)-+-{gdbus}(1984)
| `-{gmain}(1984)
|-acpid(2044)
...
|-lxcfs(1936)-+-{lxcfs}(1936)
| `-{lxcfs}(1936)
|-mdadm(2135)
|-ntpd(2358)
|-polkitd(2128)-+-{gdbus}(2128)
| `-{gmain}(2128)
|-rsyslogd(1632)-+-{in:imklog}(1632)
| |-{in:imuxsock) S 1(1632)
| `-{rs:main Q:Reg}(1632)
|-snapd(1942)-+-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
| |-{snapd}(1942)
Comme vous pouvez le voir, dans un vrai système d’exploitation, les processus ne s’exécutent pas isolément. Ils sont plutôt organisés en groupes de processus. Par exemple, le programme « rsyslogd » est responsable du traitement des logs sous Linux. Le programme principal de rsyslogd, « main », et le module de log du noyau « imklog » qu’il utilise appartiennent au groupe de processus 1632. Ces processus collaborent pour remplir les responsabilités du programme rsyslogd. Kubernetes mappe essentiellement ce concept de « groupes de processus » à la technologie des conteneurs et en fait un « citoyen de première classe » dans ce « système d’exploitation » de cloud computing. Kubernetes adopte cette approche car les ingénieurs de Google ont réalisé que les applications qu’ils déployaient présentaient souvent des relations similaires à celles des « processus et groupes de processus ». Plus précisément, ces applications nécessitaient une collaboration étroite, imposant leur déploiement sur la même machine. Gérer de telles relations opérationnelles sans le concept de « groupes » serait incroyablement difficile. Prenons l’exemple de rsyslogd. Il se compose de trois processus : un module imklog, un module imuxsock et le processus de la fonction principale de rsyslogd lui-même. Ces trois processus doivent s’exécuter sur la même machine ; sinon, leur communication basée sur les sockets et l’échange de fichiers rencontreraient des problèmes.
Communication entre conteneurs
Comme le montre le diagramme ci-dessus, ce Pod contient deux conteneurs utilisateur, A et B, et un conteneur Infra. Dans Kubernetes, le conteneur Infra est conçu pour consommer un minimum de ressources et utilise une image spéciale appelée « k8s.gcr.io/pause ». Cette image représente un conteneur, écrit en langage assembleur, qui reste perpétuellement dans un état « en pause », avec une taille non compressée de seulement 100 à 200 Ko. Une fois que le conteneur Infra « détient » l’espace de noms réseau, les conteneurs utilisateur peuvent rejoindre cet espace de noms. Par conséquent, si vous examinez les fichiers d’espace de noms de ces conteneurs sur la machine hôte (le chemin de ce fichier a été mentionné précédemment), ils pointeront vers exactement la même valeur. Cela signifie que pour les conteneurs A et B à l’intérieur du Pod, ils peuvent communiquer directement en utilisant « localhost ». Ils perçoivent les mêmes périphériques réseau que le conteneur Infra. Un Pod n’a qu’une seule adresse IP, qui est l’adresse IP associée à l’espace de noms réseau du Pod. Naturellement, toutes les autres ressources réseau sont allouées par Pod et partagées par tous les conteneurs de ce Pod. Le cycle de vie d’un Pod est uniquement lié au conteneur Infra et est indépendant des conteneurs A et B. De plus, pour tous les conteneurs utilisateur d’un même Pod, leur trafic entrant et sortant peut être considéré comme passant par le conteneur Infra. Cet aspect est crucial car si vous développez un plugin réseau pour Kubernetes à l’avenir, votre attention principale doit être la configuration de l’espace de noms réseau du Pod, et non la manière dont chaque conteneur utilisateur utilise votre configuration réseau. Ce dernier point est sans importance. Cela implique que si votre plugin réseau repose sur l’installation de paquets ou de configurations à l’intérieur du conteneur, ce n’est pas une solution viable. Le système de fichiers racine de l’image du conteneur Infra est pratiquement vide, ne vous laissant aucune marge de personnalisation. À l’inverse, cela signifie également que votre plugin réseau n’a pas besoin de se soucier de l’état de démarrage des conteneurs utilisateur, mais uniquement de configurer le Pod, c’est-à-dire l’espace de noms réseau du conteneur Infra. Avec cette conception, le partage de volumes devient beaucoup plus simple. Kubernetes peut définir toutes les configurations de volume au niveau du Pod. Par conséquent, un répertoire hôte correspondant à un volume est unique pour le Pod, et tout conteneur du Pod n’a qu’à déclarer le montage de ce répertoire. Cette philosophie de conception des Pods, favorisant une « relation super étroite » entre les conteneurs, vise à encourager les utilisateurs à se demander si les applications comportant plusieurs composants fonctionnellement indépendants dans un seul conteneur ne seraient pas mieux représentées par plusieurs conteneurs au sein d’un Pod. Pour saisir cet état d’esprit, essayez de l’appliquer à des scénarios difficiles à résoudre avec un seul conteneur. Par exemple, imaginez une application qui écrit continuellement des fichiers de log dans le répertoire « /var/log » du conteneur. Dans ce cas, vous pouvez monter un volume dans le Pod sur le répertoire « /var/log » du conteneur d’application. Ensuite, dans le même Pod, exécutez un conteneur sidecar qui déclare également le montage du même volume sur son répertoire « /var/log ». À partir de là, la seule tâche du conteneur sidecar est de lire continuellement les fichiers de log depuis son répertoire « /var/log » et de les transmettre à des solutions de stockage comme MongoDB ou Elasticsearch. Cette configuration établit un mécanisme de collecte de logs de base. Comme dans le premier exemple, la fonction principale du sidecar dans ce scénario tourne également autour de l’utilisation du volume partagé pour les opérations sur les fichiers. Cependant, ne négligez pas l’autre caractéristique cruciale des Pods : tous les conteneurs d’un Pod partagent le même espace de noms réseau. Cela permet de déléguer de nombreuses configurations et tâches de gestion liées au réseau du Pod au sidecar, sans jamais avoir à interférer avec les conteneurs utilisateur. Un excellent exemple de cela est le projet Istio service mesh.
Résumé
Dans cette discussion, nous avons approfondi les raisons pour lesquelles nous avons besoin de Pods. En substance, un Pod sert d’unité fondamentale dans un cluster Kubernetes, encapsulant un ou plusieurs conteneurs (généralement des conteneurs Docker). Ces conteneurs partagent des ressources réseau et de stockage. Du point de vue des processus et des groupes de processus, un Pod peut être considéré comme un groupe de processus léger. Il permet le déploiement, la mise à l’échelle et la gestion de plusieurs processus (conteneurs) collaborant étroitement en tant qu’unité cohérente, simplifiant ainsi le déploiement et l’exploitation d’applications complexes. Dans le prochain article, nous fournirons une explication plus approfondie des Pods.
Novita AI est la plateforme cloud tout-en-un qui donne vie à vos ambitions en IA. Avec des API intégrées de manière transparente, l’informatique sans serveur et l’accélération GPU, nous fournissons les outils rentables dont vous avez besoin pour créer et faire évoluer rapidement votre entreprise pilotée par l’IA. Éliminez les problèmes d’infrastructure et commencez gratuitement - Novita AI transforme vos rêves d’IA en réalité.
Lectures recommandées :
