🥇Comment un pod dans Kubernetes obtient une adresse IP

Note de traduction.: Cet article, rédigé par un ingénieur SRE de LinkedIn, détaille la « magie interne » de Kubernetes — plus précisément, l'interaction entre CRI, CNI et kube-apiserver — ce qui se passe lorsqu'un pod doit se voir attribuer une adresse IP.

Une des exigences fondamentales du modèle réseau de Kubernetes est que chaque pod doit avoir sa propre adresse IP et que tout autre pod dans le cluster doit pouvoir communiquer avec lui via cette adresse. Il existe de nombreux « fournisseurs » réseau (Flannel, Calico, Canal, etc.) qui aident à réaliser ce modèle réseau.

Lorsque j'ai commencé à travailler avec Kubernetes, je ne comprenais pas très bien comment les pods obtenaient leurs adresses IP. Même en comprenant comment fonctionnent les différents composants, il était difficile d'imaginer leur travail en synergie. Par exemple, je savais à quoi servaient les plugins CNI, mais je ne savais pas exactement comment ils étaient appelés. J'ai donc décidé d'écrire cet article pour partager mes connaissances sur les différents composants réseau et leur collaboration dans un cluster Kubernetes, qui permettent à chaque pod d'obtenir son adresse IP unique.

Il existe différentes façons d'organiser la communication réseau dans Kubernetes, tout comme il existe différentes options d'environnements d'exécution (runtime) pour les conteneurs. Dans cette publication, je vais utiliser Flannel pour organiser le réseau dans le cluster, et comme environnement d'exécution — Containerd. Je pars également du principe que vous savez comment fonctionne la communication réseau entre les conteneurs, donc je vais en aborder brièvement les points essentiels, uniquement pour le contexte.

Quelques concepts de base

Conteneurs et réseau : un aperçu rapide

Il existe de nombreuses publications excellentes sur Internet expliquant comment les conteneurs se connectent entre eux via le réseau. Je vais donc donner un aperçu général des concepts de base et me limiter à une approche, impliquant la création d'un pont Linux et l'encapsulation des paquets. Les détails sont laissés de côté, car le sujet de la communication réseau des conteneurs mérite un article à part. Des liens vers quelques publications particulièrement enrichissantes et instructives seront fournis ci-dessous.

Conteneurs sur un même hôte

L'un des moyens d'organiser la communication par adresses IP entre des conteneurs fonctionnant sur le même hôte est de créer un pont Linux. À cette fin, des dispositifs virtuels sont créés dans Kubernetes (et Docker) veth (ethernet virtuel). Une extrémité du dispositif veth est connectée à l'espace de noms réseau du conteneur, l'autre à un pont Linux dans le réseau de l'hôte.

Tous les conteneurs sur un même hôte ont une extrémité du veth connectée au pont, par lequel ils peuvent communiquer entre eux par adresses IP. Le pont Linux dispose également d'une adresse IP et sert de passerelle pour le trafic sortant (egress) des pods vers d'autres nœuds.

Conteneurs sur différents hôtes

L'encapsulation de paquets est l'un des moyens permettant aux conteneurs sur différents nœuds de communiquer par adresses IP. Dans Flannel, cette capacité est gérée par la technologie vxlan, qui « encapsule » le paquet d'origine dans un paquet UDP avant de l'envoyer à destination.

Dans un cluster Kubernetes, Flannel crée un dispositif vxlan et complète la table de routage sur chacun des nœuds en conséquence. Chaque paquet destiné à un conteneur sur un autre hôte passe par le dispositif vxlan et est encapsulé dans un paquet UDP. À la destination, le paquet imbriqué est extrait et redirigé vers le pod souhaité.

Remarque : C'est seulement l'un des moyens d'organiser l'interaction réseau entre des conteneurs.

Qu'est-ce que CRI ?

CRI (Container Runtime Interface) est un plugin permettant au kubelet d'utiliser différents environnements d'exécution de conteneurs. L'API CRI est intégrée à divers environnements d'exécution, permettant aux utilisateurs de choisir l'exécution selon leurs besoins.

Qu'est-ce que CNI ?

Le projet CNI est un la spécification vise à fournir une solution réseau universelle pour les conteneurs Linux. De plus, il inclut plugins, qui sont responsables de différentes fonctions lors de la configuration du réseau du pod. Un plugin CNI est un fichier exécutable conforme aux spécifications (certains plugins seront discutés ci-dessous).

Attribution de sous-réseaux aux nœuds pour l'attribution d'adresses IP aux pods

Puisque chaque pod dans le cluster doit disposer d'une adresse IP, il est crucial de s'assurer que cette adresse soit unique. Cela est accompli en attribuant à chaque nœud un sous-réseau unique à partir duquel des adresses IP seront ensuite attribuées aux pods sur ce nœud.

Contrôleur IPAM du nœud

Lorsque nodeipam est passé en tant que paramètre d'option --controllers du kube-controller-manager., il attribue à chaque nœud un sous-réseau distinct (podCIDR) à partir du CIDR du cluster (c'est-à-dire une plage d'adresses IP pour le réseau du cluster). Étant donné que ces podCIDR ne se chevauchent pas, il devient possible d'attribuer une adresse IP unique à chaque pod.

Un podCIDR est attribué à un nœud Kubernetes au moment de son enregistrement initial dans le cluster. Pour modifier le podCIDR des nœuds, il est nécessaire de les désenregistrer, puis de les réenregistrer, en apportant les modifications nécessaires à la configuration de la couche de contrôle Kubernetes. Vous pouvez afficher le podCIDR d'un nœud avec la commande suivante :

$ kubectl get no  -o json | jq '.spec.podCIDR'
10.244.0.0/24

Kubelet, environnement d'exécution des conteneurs et plugins CNI : comment tout cela fonctionne

La planification d'un pod sur un nœud est liée à l'exécution de plusieurs actions préparatoires. Dans cette section, je vais me concentrer uniquement sur celles qui sont directement liées à la configuration du réseau du pod.

La planification d'un pod sur un nœud déclenche la chaîne d'événements suivante :

Aide : Architecture des plugins CRI de Containerd.

Interaction entre l'environnement d'exécution des conteneurs et les plugins CNI

Chaque fournisseur de réseau a son propre plugin CNI. L'environnement d'exécution des conteneurs le lance pour configurer le réseau pour le pod pendant son démarrage. Dans le cas de containerd, le plugin CNI est géré par le plugin Containerd CRI.

Chaque fournisseur dispose également 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 fourni avec la configuration CNI, soit crée celle-ci lui-même sur le nœud. La configuration aide le plugin CRI à déterminer quel plugin CNI appeler.

L'emplacement de la configuration CNI peut être configuré ; par défaut, elle se trouve 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 configurable ; le répertoire par défaut est /opt/cni/bin.

Lors de l'utilisation de containerd, les chemins pour la configuration et les binaires du plugin peuvent être définis dans la section [plugins."io.containerd.grpc.v1.cri".cni] dans du fichier de configuration de containerd.

Étant donné que 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 le cluster en tant que DaemonSet avec install-cni comme init-container.
Install-cni crée un fichier de configuration CNI (/etc/cni/net.d/10-flannel.conflist) sur chaque nœud.
Flanneld crée un dispositif vxlan, extrait les métadonnées réseau depuis l'API du serveur et suit les mises à jour des pods. Au fur et à mesure de leur création, il diffuse des routes pour tous les pods à travers le cluster.
Ces routes permettent aux pods de communiquer entre eux via des adresses IP.

Pour plus d'informations sur le fonctionnement de Flannel, je recommande de consulter les liens à la fin de l'article.

Voici un schéma de l'interaction entre le plugin Containerd CRI et les plugins CNI :

Comme le montre l'exemple ci-dessus, kubelet appelle le plugin Containerd CRI pour créer un pod, et ce dernier appelle le plugin CNI pour configurer le réseau du pod. Le plugin CNI du fournisseur de réseau appelle d'autres plugins de base CNI pour configurer les différents aspects du réseau.

Interaction entre les plugins CNI

Il existe différents plugins CNI dont le but est d'aider à configurer l'interaction réseau entre les conteneurs sur l'hôte. Cet article se concentrera sur trois d'entre eux.

Plugin CNI Flannel

Lors de l'utilisation de Flannel en tant que fournisseur de réseau, le composant Containerd CRI appelle Plugin CNI Flannel, 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 CNI Flannel fonctionne en tandem avec Flanneld. Lors du démarrage, Flanneld extrait le podCIDR et d'autres détails de réseau liés depuis l'API du serveur 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 CNI Flannel utilise les données de /run/flannel/subnet.env pour configurer et appeler le plugin CNI pont (bridge).

Plugin CNI Bridge

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"
  }
}

Lors de son premier appel, il crée un pont Linux avec "name": "cni0", ce qui est spécifié dans la configuration. Ensuite, pour chaque pod, une paire de veth est créée. Une extrémité est connectée à l'espace de noms réseau du conteneur, l'autre entre dans le pont Linux dans le réseau hôte. Plugin CNI Bridge connecte tous les conteneurs de l'hôte au pont Linux dans le réseau hôte.

Après avoir terminé la configuration de la paire de veth, le plugin Bridge appelle le plugin IPAM local à l'hôte (host-local) CNI. Le type de plugin IPAM peut être configuré dans le fichier de configuration CNI que le plugin CRI utilise pour appeler le plugin CNI Flannel.

Les plugins IPAM CNI locaux pour l'hôte

Bridge CNI appelle le plugin IPAM CNI local à l'hôte avec la configuration suivante :

{
  "name": "cni0",
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24",
    "dataDir": "/var/lib/cni/networks"
  }
}

Plugin IPAM local-hôte (IP Aadresse Mgestion — gestion des adresses IP) renvoie une adresse IP pour le conteneur depuis le sous-réseau et conserve l'adresse IP attribué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.

Lorsqu'il est appelé, le plugin IPAM local-hôte renvoie les données suivantes :

{
  "ip4": {
    "ip": "10.244.4.2",
    "gateway": "10.244.4.3"
  },
  "dns": {}
}

Résumé

Le kube-controller-manager attribue un podCIDR à chaque nœud. Les pods de chaque nœud obtiennent des adresses IP à partir de l'espace d'adresses dans la plage de podCIDR attribuée. Comme 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 kubelet, l'environnement d'exécution des conteneurs, l'agent du fournisseur de réseau, puis copie les plugins CNI sur chaque nœud. Lors du démarrage, l'agent fournisseur de réseau génère la configuration CNI. Lorsque le pod est planifié sur un nœud, kubelet appelle le plugin CRI pour le créer. Ensuite, si containerd 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 un certain temps pour comprendre toutes les subtilités et les nuances de ces interactions. J'espère que cette expérience vous aidera également à mieux comprendre comment Kubernetes fonctionne. Si je fais une erreur, n'hésitez pas à me contacter à Twitter ou à l'adresse hello@ronaknathani.com. N'hésitez pas à me contacter si vous souhaitez discuter des aspects de cet article ou d'autre chose. Je serais ravi de converser avec vous !

Liens

Conteneurs et réseau

Comment Flannel fonctionne

CRI et CNI

P.S. de l'auteur

Lisez aussi dans notre blog :

«Calico pour le réseau dans Kubernetes : introduction et quelques expériences»;
« Guide illustré sur la mise en réseau dans Kubernetes » : parties 1 et 2 (modèle réseau, réseaux superposés), partie 3 (services et traitement du trafic);
«L'Interface de Réseau de Conteneurs (CNI) — interface réseau et norme pour les conteneurs Linux».

Source : habr.com