Runtimes de conteneurs | Kubernetes

Les informations contenues dans ce document peuvent être obsolètes
Ce document a une date de mise à jour antérieure à celle de l'original, les informations qu'il contient peuvent donc être obsolètes. Si vous comprenez l'anglais, consultez la version anglaise pour obtenir les informations les plus récentes : Container Runtimes
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.37 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.37, 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 :
Vérifiez que net.ipv4.ip_forward est défini sur 1 avec :
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 :
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.37, 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é.
Si 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’in