Réseaux Kubernetes: Pods

Le matériel, dont nous publions la traduction aujourd'hui, est consacré aux caractéristiques de l'interaction réseau des foyers Kubernetes. Il est destiné à ceux qui ont déjà une certaine expérience avec Kubernetes. Si vous n'êtes pas très familier avec Kubernetes, alors cela vaut probablement la peine de lire ce tutoriel Kubernetes avant de lire ce matériel, où travailler avec cette plate-forme est envisagé pour les débutants.

Pods

Qu'est-ce que sous (pod) Kubernetes? Sub est une entité qui se compose d'un ou plusieurs conteneurs hébergés sur le même hôte et configurés pour partager des ressources de pile réseau et d'autres ressources comme des volumes. Les pods sont les blocs de construction de base qui composent les applications qui s'exécutent sur la plate-forme Kubernetes. Les pods partagent une pile réseau. En pratique, cela signifie que tous les conteneurs qui composent le foyer peuvent communiquer entre eux via l' localhost . S'il y a un conteneur dans l'âtre qui exécute nginx, à l'écoute sur le port 80 et un autre conteneur qui exécute scrapyd, ce conteneur peut accéder au premier conteneur à http://localhost:80 . Ça n'a pas l'air si difficile. Demandons-nous maintenant comment cela fonctionne réellement. Jetons un coup d'œil à une situation typique lorsque le conteneur Docker est lancé sur la machine locale.


Conteneur Docker exécuté sur une machine locale

Si vous regardez ce schéma de haut en bas, il s'avère qu'il existe une interface réseau physique eth0 . Le pont docker0 est docker0 et l'interface réseau virtuelle docker0 est veth0 au pont. Notez que les veth0 docker0 et veth0 sont sur le même réseau, dans cet exemple, c'est 172.17.0.0/24 . Sur ce réseau, l'interface docker0 attribuer l'adresse IP 172.17.0.1 , cette interface est la passerelle par défaut pour l'interface veth0 , à laquelle est attribuée l'adresse 172.17.0.2 . En raison des particularités de la configuration des espaces de noms réseau lors du démarrage du conteneur, les processus à l'intérieur du conteneur ne voient que l'interface veth0 et interagissent avec le monde extérieur via les interfaces docker0 et eth0 . Exécutez maintenant le deuxième conteneur.


Deux conteneurs Docker exécutés sur la machine locale

Comme vous pouvez le voir dans le diagramme ci-dessus, la nouvelle interface réseau virtuelle veth1 est affectée au deuxième conteneur, qui est connecté au même pont que le premier conteneur - à docker0 . Il s'agit d'une description assez concise de ce qui se passe réellement. De plus, il convient de noter que la connexion entre le conteneur et le pont est établie grâce à une paire d'interfaces Ethernet virtuelles connectées, dont l'une se trouve dans l'espace de noms du conteneur et l'autre dans l'espace de noms du réseau racine. Des détails à ce sujet peuvent être trouvés ici .

Tout cela est bien, mais il ne décrit pas encore ce que nous, comme appliqué aux pods Kubernetes, appelons «pile réseau partagée». Heureusement, les espaces de noms sont très flexibles. Docker peut lancer un conteneur et au lieu de créer une nouvelle interface réseau virtuelle pour lui, faites-le utiliser l'interface existante avec d'autres conteneurs. Avec cette approche, nous devrons changer le schéma ci-dessus comme indiqué ci-dessous.


Les conteneurs utilisent une interface réseau commune

Maintenant, le deuxième conteneur interagit avec l'interface veth0 déjà existante, et non avec sa propre interface veth1 , comme c'était le cas dans l'exemple précédent. L'utilisation d'un tel schéma entraîne plusieurs conséquences. Pour commencer, nous pouvons maintenant dire que les deux conteneurs sont visibles extérieurement à la même adresse - 172.17.0.2 , et à l'intérieur de chacun d'eux peuvent accéder aux ports sur localhost ouvert par un autre conteneur. De plus, cela signifie que ces conteneurs ne peuvent pas ouvrir les mêmes ports. Il s'agit bien sûr d'une limitation, mais elle ne diffère pas d'une limitation similaire dans la situation où plusieurs processus ouvrent des ports sur le même hôte. Avec cette approche, un ensemble de processus obtient tous les avantages associés à l'exécution de ces processus dans des conteneurs, tels qu'une mauvaise connectivité et une mauvaise isolation, mais en même temps, les processus peuvent organiser la collaboration dans le plus simple des environnements réseau existants.

Kubernetes met en œuvre ce modèle en créant un conteneur spécial pour chaque foyer dont le seul but est de fournir une interface réseau pour d'autres conteneurs de foyer. Si vous vous connectez au nœud du cluster Kubernetes auquel un sous-programme spécifique est affecté par ssh et exécutez la docker ps , vous verrez au moins un conteneur s'exécuter avec la commande pause . Cette commande suspend le processus en cours jusqu'à ce qu'un signal SIGTERM arrive. De tels conteneurs ne font absolument rien, ils sont dans un état "endormi" et attendent ce signal. Bien que les conteneurs «suspendus» ne fassent rien, ils sont, pour ainsi dire, le «cœur» du foyer, fournissant à d'autres conteneurs une interface réseau virtuelle qu'ils peuvent utiliser pour interagir entre eux ou avec le monde extérieur. En conséquence, il s'avère que dans un environnement hypothétique ressemblant à ci-dessous, notre schéma précédent ressemblerait à celui illustré ci-dessous.


Conteneurs hypothétiques

Réseau de foyer

Un sous, plein de conteneurs, est la pierre angulaire d'un certain système, mais jusqu'à présent pas ce système lui-même. L'architecture Kubernetes repose sur l'exigence selon laquelle les pods doivent pouvoir interagir avec d'autres pods, qu'ils s'exécutent sur le même ordinateur ou sur des machines différentes. Afin d'apprendre comment tout cela fonctionne, nous devons aller à un niveau d'abstraction plus élevé et parler du fonctionnement des nœuds dans le cluster Kubernetes. Ici, nous aborderons le sujet du routage et des itinéraires réseau. Ce sujet est souvent évité dans des documents comme celui-ci, car il est trop complexe. Il n'est pas facile de trouver un guide compréhensible et pas trop long pour le routage IP, mais si vous voulez regarder un bref aperçu de ce problème, vous pouvez jeter un œil à ce matériel.

Le cluster Kubernetes comprend un ou plusieurs nœuds. Un nœud est un système hôte, physique ou virtuel, qui contient divers outils logiciels et leurs dépendances (principalement Docker), ainsi que plusieurs composants système Kubernetes. Le nœud est connecté au réseau, ce qui lui permet d'échanger des données avec d'autres nœuds du cluster. Voici à quoi pourrait ressembler un cluster à deux nœuds simple.


Un cluster simple à deux nœuds

Si le cluster en question s'exécute dans un environnement cloud comme GCP ou AWS, ce schéma transmet assez précisément l'essence de l'architecture de réseau par défaut pour les projets individuels. À des fins de démonstration, le réseau privé 10.100.0.0/24 utilisé dans cet exemple. Par conséquent, l'adresse 10.100.0.1 attribuée au 10.100.0.1 et les adresses 10.100.0.2 et 10.100.0.3 deux nœuds. En utilisant cette architecture, chacun des nœuds peut interagir avec l'autre en utilisant son interface réseau eth0 . Rappelons maintenant que under, exécuté sur l'hôte, n'est pas sur ce réseau privé. Il est connecté au pont dans un réseau complètement différent. Il s'agit d'un réseau virtuel qui n'existe que dans un nœud spécifique. Afin de le rendre plus clair, redessinons le schéma précédent, en y ajoutant ce que nous avons appelé un foyer hypothétique ci-dessus.


Pods et nœuds

L'hôte situé à gauche de ce diagramme a une interface eht0 avec l'adresse 10.100.0.2 , la passerelle par défaut pour laquelle est le routeur avec l'adresse 10.100.0.1 . Le pont docker0 avec l'adresse 172.17.0.1 connecté à cette interface, et à lui, via l'interface virtuelle veth0 avec l'adresse 172.17.0.2 , est connecté ce que nous appelons ici le foyer. L'interface veth0 été créée dans un conteneur suspendu. Il est visible dans les trois conteneurs via une pile réseau partagée. Étant donné que les règles de routage locales sont configurées lors de la création du pont, tout paquet arrivant à eth0 et ayant l'adresse de destination 172.17.0.2 sera redirigé vers le pont, qui le transmettra à l'interface virtuelle veth0 . Bien que tout cela semble assez décent. S'il est connu que l'hôte dont nous discutons a l'adresse 172.17.0.2 , nous pouvons ajouter une règle aux paramètres du routeur qui décrit que la prochaine transition pour cette adresse est 10.100.0.2 , après quoi les paquets à partir de là devraient être redirigés vers veth0 . Excellent. Voyons maintenant un autre hôte.

L'hôte montré dans le diagramme de droite a une interface physique eth0 avec l'adresse 10.100.0.3 . Il utilise la même passerelle par défaut - 10.100.0.1 , et, encore une fois, il est connecté au pont docker0 avec l'adresse 172.17.0.1 . On a le sentiment que tout ne va pas si bien. Cette adresse peut en effet différer de celle utilisée sur l'hôte situé à gauche. Les adresses des ponts ici sont identiques pour illustrer le pire scénario possible, qui, par exemple, peut se produire si vous venez d'installer Docker et de le laisser fonctionner comme vous le souhaitez. Mais même si les réseaux en question sont différents, notre exemple met en évidence un problème plus profond, à savoir que les nœuds ne savent généralement rien des adresses privées attribuées aux ponts situés sur d'autres nœuds. Et nous devons le savoir - pour pouvoir envoyer des paquets à ces ponts et être sûr qu'ils arriveront là où ils en ont besoin. Évidemment, ici nous avons besoin d'une sorte d'entité, ce qui nous permet d'assurer la configuration correcte des adresses dans différents nœuds.

La plate-forme Kubernetes nous donne une solution en deux étapes à ce problème. Tout d'abord, cette plate-forme attribue un espace d'adressage commun aux ponts dans chaque nœud, puis attribue aux ponts les adresses dans cet espace en fonction du nœud dans lequel se trouve le pont. Deuxièmement, Kubernetes ajoute des règles de routage à la passerelle située, dans notre cas, à 10.100.0.1 . Ces règles définissent les règles de routage des paquets destinés à chacun des ponts. C'est-à-dire qu'ils décrivent à travers quelle interface physique eth0 peut être mise en contact avec chacun des ponts. Cette combinaison d'interfaces de réseau virtuel, de ponts et de règles de routage est communément appelée réseau de superposition . En parlant de Kubernetes, j'appelle généralement ce réseau un «réseau de foyer», car il s'agit d'un réseau de superposition qui permet aux pods situés à différents nœuds de communiquer entre eux. Voici à quoi ressemblera le diagramme précédent une fois que les mécanismes Kubernetes seront opérationnels.


Réseau de foyer

Il attire immédiatement l'attention sur le fait que les noms de pont sont passés de docker0 à cbr0 . Kubernetes n'utilise pas de ponts Docker standard. Ce que nous avons appelé cbr est une abréviation de «pont personnalisé», c'est-à-dire que nous parlons de ponts spéciaux. Je ne suis pas prêt à donner une liste complète des différences entre le lancement de conteneurs Docker dans des pods et leur exécution sur des ordinateurs ordinaires, mais ce dont nous parlons ici est l'une des différences similaires importantes. De plus, vous devez faire attention au fait que l'espace d'adressage attribué aux ponts dans cet exemple est 10.0.0.0/14 . Cette adresse est extraite de l'un de nos clusters intermédiaires, qui sont déployés sur la plate-forme Google Cloud, ce qui précède est donc un exemple très réel d'un réseau de foyers. Votre cluster peut se voir attribuer une plage d'adresses complètement différente. Malheureusement, pour le moment, il n'y a aucun moyen d'obtenir des informations sur ces adresses à l'aide de l'utilitaire kubectl , mais, par exemple, si vous utilisez GCP, vous pouvez exécuter une commande comme les gcloud container clusters describe <cluster> et regardez la propriété clusterIpv4Cidr .

En général, on peut noter que vous n'avez généralement pas à penser au fonctionnement du réseau de foyers. Lorsqu'un sous-échange de données avec un autre foyer, cela se produit le plus souvent via les services Kubernetes. C'est un peu un proxy défini par logiciel. Mais les adresses réseau des foyers apparaissent dans les journaux. Dans certaines situations, en particulier pendant le débogage, vous devrez peut-être définir explicitement des règles de routage dans les réseaux de foyers. Par exemple, le trafic quittant Kubernetes lié à une adresse dans la plage 10.0.0.0/8 n'est pas traité par défaut à l'aide de NAT. Par conséquent, si vous interagissez avec des services situés sur un autre réseau privé qui a la même plage d'adresses, vous devrez peut-être configurer des règles de routage qui vous permettront d'organiser la livraison correcte des paquets.

Résumé

Aujourd'hui, nous avons parlé des modules Kubernetes et des fonctionnalités de leur mise en réseau. Nous espérons que ce matériel vous aidera à prendre les bonnes mesures pour mettre en œuvre des scénarios d'interaction de foyer complexes sur les réseaux Kubernetes.

Chers lecteurs! Cet article est le premier d'une série de réseaux Kubernetes. La deuxième partie de ce cycle a déjà été traduite . Nous réfléchissons à l'opportunité de traduire la troisième partie. Nous vous demandons de commenter cela dans les commentaires.