introduction
Kubernetes est un puissant système d'orchestration de conteneur capable de gérer le déploiement et le fonctionnement d'applications conteneurisées sur des grappes de serveurs. Outre la coordination des charges de travail de conteneur, Kubernetes fournit l'infrastructure et les outils nécessaires pour maintenir une connectivité réseau fiable entre vos applications et vos services.
LeKubernetes cluster networking documentation indique que les exigences de base d'un réseau Kubernetes sont:
tous les conteneurs peuvent communiquer avec tous les autres conteneurs sans NAT
tous les nœuds peuvent communiquer avec tous les conteneurs (et vice-versa) sans NAT
l'adresse IP qu'un conteneur se voit comme est la même adresse IP que d'autres le voient comme
Dans cet article, nous verrons comment Kubernetes satisfait à ces exigences de réseau au sein d'un cluster: comment les données se déplacent-elles dans un pod, entre des pods et entre des nœuds.
Nous montrerons également comment un KubernetesService peut fournir une seule adresse IP statique et une seule entrée DNS pour une application, facilitant la communication avec des services qui peuvent être distribués entre plusieurs pods en constante évolution et évolution.
Si vous n'êtes pas familier avec la terminologie de Kubernetespods etnodes ou d'autres bases, notre articleAn Introduction to Kubernetes couvre l'architecture générale et les composants impliqués.
Voyons d’abord la situation de la mise en réseau au sein d’un seul module.
Réseau de pod
Dans Kubernetes, unpod est l'unité d'organisation la plus basique: un groupe de conteneurs étroitement couplés qui sont tous étroitement liés et exécutent une seule fonction ou un seul service.
En termes de réseau, Kubernetes traite les pods de la même manière qu'une machine virtuelle traditionnelle ou un seul hôte bare-metal: chaque pod reçoit une seule adresse IP unique, et tous les conteneurs du pod partagent cette adresse et communiquent entre eux via lelo interface de bouclage utilisant le nom d'hôte delocalhost. Ceci est réalisé en affectant tous les conteneurs du pod à la même pile réseau.
Cette situation devrait sembler familière à quiconque a déployé plusieurs services sur un seul hôte avant la conteneurisation. Tous les services doivent utiliser un port unique pour écouter, mais sinon, la communication n’est pas compliquée et entraîne une surcharge de temps.
Réseau de pod à pod
La plupart des clusters Kubernetes devront déployer plusieurs pods par nœud. La communication de pod à pod peut avoir lieu entre deux pods du même nœud ou entre deux nœuds différents.
Communication entre pods sur un nœud
Sur un seul nœud, vous pouvez avoir plusieurs modules qui doivent communiquer directement entre eux. Avant de tracer la route d’un paquet entre les pods, examinons la configuration réseau d’un nœud. Le diagramme suivant donne un aperçu que nous allons parcourir en détail:
Chaque nœud a une interface réseau -eth0 dans cet exemple - attachée au réseau du cluster Kubernetes. Cette interface se trouve dans l’espace de noms réseau du nœudroot. Il s'agit de l'espace de noms par défaut pour les périphériques réseau sous Linux.
Tout comme les espaces de noms de processus permettent aux conteneurs d'isoler les applications en cours d'exécution, les espaces de nom de réseau isolent les périphériques réseau tels que les interfaces et les ponts. Chaque pod d'un nœud se voit attribuer son propre espace de noms de réseau isolé.
Les espaces de noms de pod sont connectés à nouveau à l'espace de nomsroot avec unvirtual ethernet pair, essentiellement un tube entre les deux espaces de noms avec une interface à chaque extrémité (ici nous utilisonsveth1 dans leroot) s eteth0 dans le pod).
Enfin, les pods sont connectés les uns aux autres et à l’interfaceeth0 du nœud via un pont,br0 (votre nœud peut utiliser quelque chose commecbr0 oudocker0). Un pont fonctionne essentiellement comme un commutateur Ethernet physique, utilisant soit un protocole de résolution d'adresse (ARP), soit un routage basé sur IP pour rechercher d'autres interfaces locales vers lesquelles diriger le trafic.
Trouvons maintenant un paquet depod1 àpod2:
-
pod1 crée un paquet avec l'adresse IP depod2 comme destination
-
Le paquet voyage sur la paire Ethernet virtuelle vers l'espace de noms du réseau racine.
-
Le paquet continue vers le pontbr0
-
Le pod de destination étant sur le même nœud, le pont envoie le paquet à la paire Ethernet virtuelle depod2
-
le paquet voyage à travers la paire Ethernet virtuelle, dans l’espace de noms réseau depod2 et dans l’interface réseau du podeth0
Maintenant que nous avons tracé un paquet de pod en pod dans un nœud, voyons comment le trafic de pod passe entre les nœuds.
Communication pod à pod entre deux nœuds
Étant donné que chaque pod d'un cluster a une adresse IP unique et que chaque pod peut communiquer directement avec tous les autres pods, un paquet se déplaçant entre des pods situés sur deux nœuds différents est très similaire au scénario précédent.
Trouvons un paquet depod1 àpod3, qui se trouve sur un nœud différent:
-
pod1 crée un paquet avec l'adresse IP depod3 comme destination
-
Le paquet voyage sur la paire Ethernet virtuelle vers l'espace de noms du réseau racine.
-
Le paquet continue vers le pontbr0
-
Le pont ne trouve aucune interface locale vers laquelle acheminer, le paquet est donc envoyé par la route par défaut verseth0
-
Optional: si votre cluster nécessite une superposition réseau pour acheminer correctement les paquets vers les nœuds, le paquet peut être encapsulé dans un paquet VXLAN (ou une autre technique de virtualisation de réseau) avant de se diriger vers le réseau. Alternativement, le réseau lui-même peut être configuré avec les routes statiques appropriées, auquel cas le paquet est acheminé vers eth0 et sort du réseau sans modification.
-
Le paquet entre dans le réseau du cluster et est routé vers le nœud approprié.
-
Le paquet entre dans le nœud de destination leeth0
-
Optional: si votre paquet a été encapsulé, il sera désencapsulé à ce stade
-
Le paquet continue vers le pontbr0
-
Le pont achemine le paquet vers la paire Ethernet virtuelle du pod de destination.
-
Le paquet passe par la paire Ethernet virtuelle à l’interfaceeth0 du pod
Maintenant que nous savons comment les paquets sont acheminés via les adresses IP des pods, jetons un œil à Kubernetesservices et à la manière dont ils se construisent au-dessus de cette infrastructure.
Pod to Service Networking
Il serait difficile d'envoyer du trafic vers une application particulière en utilisant uniquement les adresses IP des pods, car la nature dynamique d'un cluster Kubernetes signifie que les pods peuvent être déplacés, redémarrés, mis à niveau ou mis à l'échelle. De plus, certains services auront de nombreuses répliques, nous avons donc besoin d’un moyen d’équilibrer la charge entre eux.
Kubernetes résout ce problème avecServices. Un service est un objet API qui mappe une adresse IP virtuelle unique (VIP) à un ensemble d'adresses IP de pods. De plus, Kubernetes fournit une entrée DNS pour le nom et l’adresse IP virtuelle de chaque service, afin que les services puissent être facilement adressés par nom.
Le mappage des adresses IP virtuelles aux adresses IP de pod au sein du cluster est coordonné par le processuskube-proxy sur chaque nœud. Ce processus configureiptables ou IPVS pour traduire automatiquement les VIP en adresses IP de pod avant d'envoyer le paquet vers le réseau du cluster. Les connexions individuelles sont suivies afin que les paquets puissent être correctement dé-traduits lors de leur retour. IPVS et iptables peuvent à la fois équilibrer la charge d'une adresse IP virtuelle de service unique en plusieurs IP de pod, bien qu'IPVS offre une plus grande flexibilité dans les algorithmes d'équilibrage de charge qu'il peut utiliser.
[.note] #Note: ces processus de traduction et de suivi de connexion se déroulent entièrement dans le noyau Linux. kube-proxy lit depuis l'API Kubernetes et met à jour iptables ip IPVS, mais il ne se trouve pas dans le chemin de données des paquets individuels. C'est plus efficace et plus performant que les versions précédentes de kube-proxy, qui fonctionnait comme un proxy utilisateur.
#
Suivons la route empruntée par un paquet depuis un pod,pod1 encore, vers un service,service1:
-
pod1 crée un paquet avec l'adresse IP deservice1 comme destination
-
Le paquet voyage sur la paire Ethernet virtuelle vers l'espace de noms du réseau racine.
-
Le paquet continue vers le pontbr0
-
Le pont ne trouve aucune interface locale vers laquelle acheminer le paquet, donc le paquet est envoyé par la route par défaut verseth0
-
Iptables ou IPVS, configurés par
kube-proxy, correspondent à l'adresse IP de destination du paquet et le traduisent d'une adresse IP virtuelle à l'une des adresses IP de pod du service, en utilisant les algorithmes d'équilibrage de charge disponibles ou spécifiés -
Optional: votre paquet peut être encapsulé à ce stade, comme indiqué dans la section précédente
-
Le paquet entre dans le réseau du cluster et est routé vers le nœud approprié.
-
Le paquet entre dans le nœud de destination leeth0
-
Optional: si votre paquet a été encapsulé, il sera désencapsulé à ce stade
-
Le paquet continue vers le pontbr0
-
Le paquet est envoyé à la paire Ethernet virtuelle viaveth1
-
Le paquet passe par la paire Ethernet virtuelle et entre dans l'espace de noms réseau du pod via son interface réseaueth0
Lorsque le paquet revient ànode1, la traduction IP VIP vers pod sera inversée et le paquet reviendra via le pont et l'interface virtuelle vers le pod correct.
Conclusion
Dans cet article, nous avons examiné l’infrastructure de réseau interne d’un cluster Kubernetes. Nous avons discuté des éléments constitutifs du réseau et détaillé le parcours des paquets, saut par saut, dans différents scénarios.
Pour plus d'informations sur Kubernetes, jetez un œil àour Kubernetes tutorials tag etthe official Kubernetes documentation.