Vous devez installer un runtime de conteneur sur chaque nœud du cluster afin que les Pods puissent y être exécutés. Cette page décrit ce qui est nécessaire et présente les tâches liées à la configuration des nœuds.
Kubernetes 1.36 exige l’utilisation d’un runtime conforme à la Container Runtime Interface (CRI).
Voir Support des versions de la CRI pour plus d’informations.
Cette page donne un aperçu de l’utilisation de plusieurs runtimes de conteneurs courants avec Kubernetes.
Les versions de Kubernetes antérieures à la v1.24 incluaient une intégration directe avec Docker Engine, via un composant nommé dockershim. Cette intégration directe ne fait plus partie de Kubernetes (cette suppression a été annoncée lors de la version v1.20).
Vous pouvez lire Vérifier si la suppression de Dockershim vous affecte pour comprendre si cette suppression vous concerne. Pour apprendre à migrer depuis dockershim, voir Migrer depuis dockershim.
Si vous utilisez une version de Kubernetes différente de v1.36, consultez la documentation correspondant à cette version.
Par défaut, le noyau Linux n’autorise pas le routage des paquets IPv4 entre les interfaces. La plupart des implémentations réseau des clusters Kubernetes modifient ce paramètre (si nécessaire), mais certaines peuvent exiger que l’administrateur le fasse lui-même. (Certaines peuvent aussi exiger d’autres paramètres sysctl, le chargement de modules du noyau, etc. Consultez la documentation de votre solution réseau spécifique.)
Pour activer manuellement le transfert IPv4 :
# paramètres sysctl requis par la configuration, persistants après redémarrage
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF
# appliquer les paramètres sysctl sans redémarrer
sudo sysctl --system
Vérifiez que net.ipv4.ip_forward est défini sur 1 avec :
sysctl net.ipv4.ip_forward
Sous Linux, les groupes de contrôle sont utilisés pour limiter les ressources allouées aux processus.
Le kubelet et le
runtime de conteneur sous-jacent doivent tous deux interagir avec les cgroups afin d’appliquer la
gestion des ressources pour les pods et les conteneurs
et de définir des ressources telles que les demandes (requests) et limites (limits) CPU/mémoire.
Pour interagir avec les cgroups, le kubelet et le runtime de conteneur doivent utiliser un pilote de cgroup.
Il est essentiel que le kubelet et le runtime de conteneur utilisent le même pilote de cgroup
et soient configurés de la même manière.
Deux pilotes de cgroup sont disponibles :
Le pilote cgroupfs est le pilote de cgroup par défaut du kubelet.
Lorsque le pilote cgroupfs est utilisé, le kubelet et le runtime de conteneur interagissent directement avec
le système de fichiers cgroup pour configurer les cgroups.
Le pilote cgroupfs n’est pas recommandé lorsque
systemd est le système d’initialisation (init system),
car systemd s’attend à ce qu’un seul gestionnaire de cgroups soit utilisé sur le système.
De plus, si vous utilisez cgroup v2, il est recommandé d’utiliser le pilote systemd
plutôt que cgroupfs.
Lorsque systemd est utilisé comme système d’initialisation
d’une distribution Linux, le processus init crée et utilise un cgroup racine
(cgroup) et agit comme gestionnaire de cgroups.
systemd a une intégration étroite avec les cgroups et alloue un cgroup par unité systemd.
Par conséquent, si vous utilisez systemd comme système d’initialisation avec le pilote cgroupfs,
le système dispose alors de deux gestionnaires de cgroups différents.
Deux gestionnaires de cgroups entraînent deux vues différentes des ressources disponibles et utilisées sur le système.
Dans certains cas, les nœuds configurés avec cgroupfs pour le kubelet et le runtime de conteneur,
mais utilisant systemd pour les autres processus, peuvent devenir instables en cas de forte pression sur les ressources.
Pour éviter cette instabilité, il est recommandé d’utiliser systemd comme pilote de cgroup pour
le kubelet et le runtime de conteneur lorsque systemd est le système d’initialisation choisi.
Pour définir systemd comme pilote de cgroup, modifiez l’option
KubeletConfiguration
cgroupDriver et définissez-la sur systemd. Par exemple :
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd
cgroupDriver dans KubeletConfiguration, kubeadm utilise par défaut systemd.Si vous configurez systemd comme pilote de cgroup pour le kubelet, vous devez également
configurer systemd comme pilote de cgroup pour le runtime de conteneur. Consultez
la documentation de votre runtime de conteneur pour les instructions. Par exemple :
Dans Kubernetes 1.36, avec le
feature gate
KubeletCgroupDriverFromCRI activé et un runtime de conteneur prenant en charge l’appel CRI RuntimeConfig,
le kubelet détecte automatiquement le pilote de cgroup approprié à partir du runtime
et ignore la configuration cgroupDriver du kubelet.
Cependant, les anciennes versions des runtimes de conteneurs (en particulier
containerd 1.y et versions inférieures) ne prennent pas en charge l’appel CRI RuntimeConfig,
et peuvent ne pas répondre correctement à cette requête. Dans ce cas, le kubelet revient à utiliser
la valeur définie dans son propre paramètre --cgroup-driver.
Dans Kubernetes 1.37, ce comportement de repli sera supprimé, et les anciennes versions de containerd ne fonctionneront pas avec les versions plus récentes du kubelet.
Changer le pilote de cgroup d’un nœud déjà intégré à un cluster est une opération sensible. Si le kubelet a créé des Pods avec les conventions d’un pilote de cgroup donné, changer le runtime de conteneur vers un autre pilote peut provoquer des erreurs lors de la recréation du sandbox de ces Pods existants. Redémarrer le kubelet peut ne pas corriger ces erreurs.
Si vous disposez d’une automatisation adaptée, remplacez le nœud par un autre avec la configuration mise à jour, ou réinstallez-le via un système automatisé.
systemd dans les clusters gérés par kubeadmSi vous souhaitez migrer vers le pilote de cgroup systemd dans des clusters kubeadm existants,
suivez la procédure configuration d’un pilote de cgroup.
Votre runtime de conteneur doit prendre en charge la version v1 de l’interface CRI.
Kubernetes à partir de la version v1.26 fonctionne uniquement avec la version v1 de l’API CRI. Si un runtime de conteneur ne prend pas en charge l’API v1, le kubelet ne s’enregistrera pas en tant que nœud.
Cette section décrit les étapes nécessaires pour utiliser containerd comme runtime CRI.
Pour installer containerd sur votre système, suivez les instructions de
getting started with containerd.
Revenez à cette étape une fois que vous avez créé un fichier de configuration config.toml valide.
Vous pouvez trouver ce fichier dans le chemin /etc/containerd/config.toml.
Vous pouvez trouver ce fichier dans le chemin C:\Program Files\containerd\config.toml.
Sous Linux, le socket CRI par défaut pour containerd est /run/containerd/containerd.sock.
Sous Windows, le point de terminaison CRI par défaut est npipe://./pipe/containerd-containerd.
systemdPour utiliser le pilote de cgroup systemd dans /etc/containerd/config.toml avec runc,
définissez la configuration suivante en fonction de votre version de containerd
Versions 1.x de Containerd :
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
Versions 2.x de Containerd :
[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc]
...
[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc.options]
SystemdCgroup = true
Le pilote de cgroup systemd est recommandé si vous utilisez cgroup v2.
Si vous avez installé containerd à partir d’un paquet (par exemple RPM ou .deb), il est possible que
le plugin d’intégration CRI soit désactivé par défaut.
Vous devez activer le support CRI pour utiliser containerd avec Kubernetes. Assurez-vous que cri
n’est pas inclus dans la liste disabled_plugins dans /etc/containerd/config.toml.
Si vous modifiez ce fichier, redémarrez également containerd.
Si vous observez des boucles de crash des conteneurs après l’installation initiale du cluster ou après l’installation d’un CNI, la configuration de containerd fournie par le paquet peut contenir des paramètres incompatibles. Dans ce cas, envisagez de réinitialiser la configuration de containerd avec :
containerd config default > /etc/containerd/config.toml
comme indiqué dans getting-started.md, puis ajustez les paramètres de configuration mentionnés ci-dessus en conséquence.
Si vous appliquez cette modification, assurez-vous de redémarrer containerd :
sudo systemctl restart containerd
Lorsque vous utilisez kubeadm, configurez manuellement le pilote de cgroup pour le kubelet.
Dans Kubernetes v1.28, vous pouvez activer la détection automatique du pilote de cgroup en tant que fonctionnalité alpha. Voir pilote de cgroup systemd pour plus de détails.
Dans votre configuration containerd, vous pouvez remplacer l’image sandbox en définissant la configuration suivante :
[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "registry.k8s.io/pause:3.10"
Vous devrez peut-être aussi redémarrer containerd après avoir modifié le fichier de configuration :
systemctl restart containerd.
Cette section contient les étapes nécessaires pour installer CRI-O comme runtime de conteneur.
Pour installer CRI-O, suivez les instructions d’installation de CRI-O.
CRI-O utilise par défaut le pilote de cgroup systemd, ce qui devrait généralement fonctionner correctement.
Pour passer au pilote de cgroup cgroupfs, vous pouvez soit modifier le fichier /etc/crio/crio.conf, soit ajouter une configuration de type drop-in dans
/etc/crio/crio.conf.d/02-cgroup-manager.conf, par exemple :
[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"
Vous devez également noter le changement de conmon_cgroup, qui doit être défini sur la valeur pod lorsque vous utilisez CRI-O avec cgroupfs. Il est généralement nécessaire de garder
la configuration du pilote de cgroup du kubelet (souvent effectuée via kubeadm) et celle de CRI-O synchronisées.
Dans Kubernetes v1.28, vous pouvez activer la détection automatique du pilote de cgroup comme fonctionnalité alpha. Voir pilote de cgroup systemd pour plus de détails.
Pour CRI-O, le socket CRI est /var/run/crio/crio.sock par défaut.
Dans votre configuration CRI-O, vous pouvez définir la valeur suivante :
[crio.image]
pause_image="registry.k8s.io/pause:3.10"
Cette option de configuration prend en charge le rechargement de configuration à chaud pour appliquer ce changement : systemctl reload crio ou en envoyant un signal SIGHUP au processus crio.
cri-dockerd pour intégrer Docker Engine à Kubernetes.Sur chacun de vos nœuds, installez Docker pour votre distribution Linux comme indiqué dans Installer Docker Engine.
Installez cri-dockerd, en suivant les instructions de la section d’installation de la documentation.
Pour cri-dockerd, le socket CRI est /run/cri-dockerd.sock par défaut.
Mirantis Container Runtime (MCR) est un runtime de conteneur disponible commercialement, anciennement connu sous le nom de Docker Enterprise Edition.
Vous pouvez utiliser Mirantis Container Runtime avec Kubernetes via le composant open source cri-dockerd, inclus dans MCR.
Pour en savoir plus sur l’installation de Mirantis Container Runtime, consultez le guide de déploiement MCR.
Vérifiez l’unité systemd nommée cri-docker.socket pour connaître le chemin du socket CRI.
L’adaptateur cri-dockerd accepte un argument en ligne de commande permettant de spécifier l’image de conteneur utilisée comme conteneur d’infrastructure de Pod (“pause image”).
L’argument à utiliser est --pod-infra-container-image.
En plus d’un runtime de conteneur, votre cluster aura besoin d’un plugin réseau fonctionnel plugin réseau.
Certains éléments sur cette page font référence à des produits ou projets tiers qui fournissent des fonctionnalités requises par Kubernetes. Les auteurs du projet Kubernetes ne sont pas responsables de ces produits ou projets tiers. Consultez les lignes directrices du site de la CNCF pour plus de détails.
Vous devriez lire le guide avant de proposer une modification qui ajoute un nouveau lien tiers.