Noter. trad.: Cet article, rédigé par un ingénieur SRE de LinkedIn, détaille la magie interne de Kubernetes - plus précisément, l'interaction de CRI, CNI et kube-apiserver - qui se produit lorsque le pod suivant doit se voir attribuer une adresse IP.
Une des exigences fondamentales est que chaque pod doit avoir sa propre adresse IP et que tout autre pod du cluster doit pouvoir le contacter à cette adresse. Il existe de nombreux « fournisseurs » de réseaux (Flannel, Calico, Canal, etc.) qui contribuent à mettre en œuvre ce modèle de réseau.
Lorsque j’ai commencé à travailler avec Kubernetes, je ne savais pas exactement comment les pods obtenaient leurs adresses IP. Même en comprenant le fonctionnement de chaque composant, il était difficile de les imaginer fonctionner ensemble. Par exemple, je savais à quoi servaient les plugins CNI, mais je ne savais pas exactement comment ils s'appelaient. Par conséquent, j'ai décidé d'écrire cet article pour partager des connaissances sur les différents composants réseau et sur la façon dont ils fonctionnent ensemble dans un cluster Kubernetes, ce qui permet à chaque pod d'obtenir sa propre adresse IP unique.
Il existe différentes manières d'organiser la mise en réseau dans Kubernetes, tout comme il existe différentes options d'exécution pour les conteneurs. Cette publication utilisera pour organiser un réseau en cluster, et en tant qu'environnement exécutable - . Je suppose également que vous savez comment fonctionne la mise en réseau entre les conteneurs. Je vais donc y revenir brièvement, juste pour le contexte.
Quelques notions de base
Conteneurs et réseau : un bref aperçu
Il existe de nombreuses excellentes publications sur Internet qui expliquent comment les conteneurs communiquent entre eux sur le réseau. Par conséquent, je ne donnerai qu'un aperçu général des concepts de base et me limiterai à une seule approche, qui consiste à créer un pont Linux et à encapsuler des packages. Les détails sont omis, car le sujet de la mise en réseau de conteneurs lui-même mérite un article séparé. Des liens vers des publications particulièrement instructives et éducatives seront fournis ci-dessous.
Conteneurs sur un hôte
Une façon d'organiser la communication via des adresses IP entre des conteneurs exécutés sur le même hôte consiste à créer un pont Linux. À cet effet, des appareils virtuels sont créés dans Kubernetes (et Docker) . Une extrémité du périphérique Veth se connecte à l'espace de noms réseau du conteneur, l'autre à sur le réseau hôte.
Tous les conteneurs sur le même hôte ont une extrémité du veth connectée à un pont à travers lequel ils peuvent communiquer entre eux via des adresses IP. Le pont Linux possède également une adresse IP et agit comme une passerelle pour le trafic de sortie des pods destinés à d'autres nœuds.
Conteneurs sur différents hôtes
L'encapsulation de paquets est une méthode qui permet aux conteneurs sur différents nœuds de communiquer entre eux à l'aide d'adresses IP. Chez Flannel, la technologie est responsable de cette opportunité. , qui « conditionne » le paquet d'origine dans un paquet UDP puis l'envoie à sa destination.
Dans un cluster Kubernetes, Flannel crée un périphérique vxlan et met à jour la table de routage sur chaque nœud en conséquence. Chaque paquet destiné à un conteneur sur un hôte différent passe par le périphérique vxlan et est encapsulé dans un paquet UDP. À destination, le paquet imbriqué est extrait et transmis au pod souhaité.
Remarque : Il ne s'agit que d'une façon parmi d'autres d'organiser la communication réseau entre les conteneurs.
Qu’est-ce que l’IRC ?
est un plugin qui permet à kubelet d'utiliser différents environnements d'exécution de conteneurs. L'API CRI est intégrée à différents environnements d'exécution, afin que les utilisateurs puissent choisir celui de leur choix.
Qu’est-ce que le CNI ?
elle représente pour organiser une solution réseau universelle pour les conteneurs Linux. De plus, il comprend , responsable de diverses fonctions lors de la mise en place d'un réseau de pods. Le plugin CNI est un fichier exécutable conforme à la spécification (nous aborderons certains plugins ci-dessous).
Allocation de sous-réseaux aux nœuds pour attribuer des adresses IP aux pods
Puisque chaque pod d’un cluster doit avoir une adresse IP, il est important de s’assurer que cette adresse est unique. Ceci est réalisé en attribuant à chaque nœud un sous-réseau unique, à partir duquel les pods de ce nœud se voient ensuite attribuer des adresses IP.
Contrôleur IPAM de nœud
Quand nodeipam passé en paramètre d'indicateur --controllers , il alloue un sous-réseau distinct (podCIDR) à chaque nœud du CIDR du cluster (c'est-à-dire la plage d'adresses IP du réseau du cluster). Étant donné que ces podCIDR ne se chevauchent pas, il devient possible que chaque pod se voie attribuer une adresse IP unique.
Un nœud Kubernetes se voit attribuer un podCIDR lors de son enregistrement initial auprès du cluster. Pour modifier le podCIDR des nœuds, vous devez les désenregistrer, puis les réenregistrer, en apportant les modifications appropriées à la configuration de la couche de contrôle Kubernetes entre les deux. Vous pouvez afficher le podCIDR d'un nœud à l'aide de la commande suivante :
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, runtime de conteneur et plugins CNI : comment tout cela fonctionne
La planification d'un pod par nœud implique de nombreuses étapes préparatoires. Dans cette section, je me concentrerai uniquement sur ceux qui sont directement liés à la mise en place d'un réseau de pods.
La planification d'un pod sur un certain nœud déclenche la chaîne d'événements suivante :
Information: .
Interaction entre le runtime du conteneur et les plugins CNI
Chaque fournisseur de réseau possède son propre plugin CNI. Le moteur d'exécution du conteneur l'exécute pour configurer le réseau du pod lors de son démarrage. Dans le cas de containersd, le plugin CNI est lancé par le plugin .
De plus, chaque prestataire dispose de son propre agent. Il est installé sur tous les nœuds Kubernetes et est responsable de la configuration réseau des pods. Cet agent est soit inclus avec la configuration CNI, soit le crée indépendamment sur le nœud. La configuration aide le plugin CRI à définir le plugin CNI à appeler.
L'emplacement de la configuration CNI peut être personnalisé ; par défaut, c'est dans /etc/cni/net.d/<config-file>. Les administrateurs de cluster sont également responsables de l'installation des plugins CNI sur chaque nœud du cluster. Leur emplacement est également personnalisable ; répertoire par défaut - /opt/cni/bin.
Lors de l'utilisation de containersd, les chemins de la configuration du plugin et des binaires peuvent être définis dans la section [plugins.«io.containerd.grpc.v1.cri».cni] в .
Puisque nous utilisons Flannel comme fournisseur de réseau, parlons un peu de sa configuration :
- Flanneld (le démon de Flannel) est généralement installé dans un cluster en tant que DaemonSet avec
install-cnicomme . Install-cnicrée (/etc/cni/net.d/10-flannel.conflist) sur chaque nœud.- Flanneld crée un périphérique vxlan, récupère les métadonnées réseau du serveur API et surveille les mises à jour des pods. Au fur et à mesure de leur création, il distribue les routes à tous les pods du cluster.
- Ces routes permettent aux pods de communiquer entre eux via des adresses IP.
Pour des informations plus détaillées sur le travail de Flannel, je vous recommande d'utiliser les liens à la fin de l'article.
Voici un schéma de l'interaction entre le plugin Containerd CRI et les plugins CNI :
Comme vous pouvez le voir ci-dessus, le kubelet appelle le plugin Containerd CRI pour créer le pod, qui appelle ensuite le plugin CNI pour configurer le réseau du pod. Ce faisant, le plugin CNI du fournisseur de réseau appelle d'autres plugins CNI principaux pour configurer divers aspects du réseau.
Interaction entre les plugins CNI
Il existe différents plugins CNI dont le travail consiste à aider à configurer la communication réseau entre les conteneurs sur l'hôte. Cet article en abordera trois.
Plugin CNI Flanelle
Lorsque vous utilisez Flannel comme fournisseur de réseau, le composant Containerd CRI appelle en utilisant le fichier de configuration CNI /etc/cni/net.d/10-flannel.conflist.
$ cat /etc/cni/net.d/10-flannel.conflist
{
"name": "cni0",
"plugins": [
{
"type": "flannel",
"delegate": {
"ipMasq": false,
"hairpinMode": true,
"isDefaultGateway": true
}
}
]
}
Le plugin Flannel CNI fonctionne en conjonction avec Flanneld. Au démarrage, Flanneld récupère le podCIDR et d'autres détails liés au réseau à partir du serveur API et les enregistre dans un fichier. /run/flannel/subnet.env.
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
Le plugin Flannel CNI utilise les données de /run/flannel/subnet.env pour configurer et appeler le plugin pont CNI.
Pont du plugin CNI
Ce plugin est appelé avec la configuration suivante :
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
Lorsqu'il est appelé pour la première fois, il crée un pont Linux avec «name»: «cni0», ce qui est indiqué dans la configuration. Ensuite, une paire Veth est créée pour chaque pod. Une extrémité est connectée à l’espace de noms réseau du conteneur, l’autre est incluse dans le pont Linux sur le réseau hôte. connecte tous les conteneurs hôtes à un pont Linux sur le réseau hôte.
Après avoir terminé la configuration de la paire veth, le plugin Bridge appelle le plugin IPAM CNI local de l'hôte. Le type de plugin IPAM peut être configuré dans la configuration CNI que le plugin CRI utilise pour appeler le plugin Flannel CNI.
Plugins IPAM CNI locaux sur l'hôte
Ponter les appels CNI avec la configuration suivante :
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Plugin IPAM local de l'hôte (IP ADRESSE Mgestion - gestion des adresses IP) renvoie l'adresse IP du conteneur du sous-réseau et stocke l'adresse IP allouée sur l'hôte dans le répertoire spécifié dans la section dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Ce fichier contient l'ID du conteneur auquel cette adresse IP est attribuée.
Lors de l'appel du plug-in IPAM local de l'hôte, il renvoie les données suivantes :
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Résumé
Kube-controller-manager attribue un podCIDR à chaque nœud. Les pods de chaque nœud reçoivent les adresses IP de l'espace d'adressage dans la plage podCIDR allouée. Étant donné que les podCIDR des nœuds ne se chevauchent pas, tous les pods reçoivent des adresses IP uniques.
L'administrateur du cluster Kubernetes configure et installe le kubelet, le runtime du conteneur, l'agent du fournisseur de réseau et copie les plugins CNI sur chaque nœud. Lors du démarrage, l'agent du fournisseur de réseau génère une configuration CNI. Lorsqu'un pod est planifié sur un nœud, le kubelet appelle le plugin CRI pour le créer. Ensuite, si containersd est utilisé, le plugin Containerd CRI appelle le plugin CNI spécifié dans la configuration CNI pour configurer le réseau du pod. En conséquence, le pod reçoit une adresse IP.
Il m'a fallu du temps pour comprendre toutes les subtilités et nuances de toutes ces interactions. J'espère que cette expérience vous aidera à mieux comprendre le fonctionnement de Kubernetes. Si je me trompe sur quoi que ce soit, veuillez me contacter au ou à l'adresse . N'hésitez pas à nous contacter si vous souhaitez discuter des aspects de cet article ou de toute autre chose. J'aimerais discuter avec vous !
références
Conteneurs et réseau
Comment fonctionne la flanelle ?
CRI et CNI
PS du traducteur
A lire aussi sur notre blog :
- «";
- "Un guide illustré de la mise en réseau dans Kubernetes" : , ;
- «».
Source: habr.com