Kubernetes 044 – What is containerd ? kubeadm

TL;DR

containerd est un runtime de conteneurs utilise par Kubernetes via la CRI. kubelet ne lance pas directement les conteneurs: il dialogue avec un runtime compatible. Avec kubeadm, installer et configurer correctement containerd est une etape indispensable avant kubeadm init ou kubeadm join.

La video de reference

Video: https://www.youtube.com/watch?v=alS339Vp1nY

Elle explique la place de containerd dans la sequence d’installation kubeadm.

Le role du runtime

Kubernetes planifie des pods, mais il lui faut un composant local pour tirer les images, creer les conteneurs, connecter les namespaces et suivre leur etat.

Ce composant est le runtime de conteneurs. containerd est aujourd’hui un choix courant et robuste.

CRI en quelques mots

La CRI, Container Runtime Interface, est l’interface entre kubelet et le runtime. Elle evite que kubelet depende d’un moteur specifique.

Kubelet envoie des demandes: creer un sandbox pod, tirer une image, lancer un conteneur, lire son etat. Le runtime execute ces actions.

Installation type de containerd

Les commandes exactes dependent de la distribution Linux. Le principe reste:

sudo apt-get update
sudo apt-get install -y containerd
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
sudo systemctl restart containerd
sudo systemctl enable containerd

Il faut ensuite verifier la configuration systemd cgroup selon la version et les recommandations Kubernetes.

SystemdCgroup

Dans beaucoup d’installations kubeadm, on configure containerd pour utiliser systemd comme gestionnaire de cgroups:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
  SystemdCgroup = true

Cette coherence avec kubelet evite des problemes de gestion de ressources.

Verifier le service

systemctl status containerd
sudo crictl info
sudo crictl ps
sudo crictl images

crictl est tres utile pour diagnostiquer le runtime cote noeud, surtout quand Kubernetes ne demarre pas encore correctement.

Difference avec Docker

Docker est une plateforme complete pour developpeurs et operateurs. containerd est le runtime bas niveau utilise pour gerer les conteneurs.

Kubernetes n’a plus besoin du dockershim historique. Il utilise directement des runtimes compatibles CRI, comme containerd ou CRI-O.

Configuration kubelet

kubeadm detecte generalement le socket CRI, mais on peut etre amene a le specifier:

sudo kubeadm init --cri-socket unix:///run/containerd/containerd.sock

Le meme principe existe pour kubeadm join.

Images Kubernetes

kubeadm peut pre-tirer les images necessaires au control plane:

sudo kubeadm config images pull --cri-socket unix:///run/containerd/containerd.sock

Cela permet de separer les problemes d’acces registry des problemes d’initialisation.

Liens utiles

• Video: https://www.youtube.com/watch?v=alS339Vp1nY
• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Container runtimes: https://kubernetes.io/docs/setup/production-environment/container-runtimes/
• containerd: https://containerd.io/

FAQ

Kubernetes utilise-t-il encore Docker ?

Pas directement via dockershim. Il utilise un runtime CRI comme containerd.

Pourquoi crictl au lieu de docker ps ?

Parce que crictl parle CRI et montre ce que kubelet voit cote runtime.

containerd suffit-il pour installer Kubernetes ?

Non. Il faut aussi kubelet, kubeadm, kubectl et un CNI.

Erreurs frequentes

• Oublier de redemarrer containerd apres modification de config.
• Avoir une configuration cgroup incoherente.
• Diagnostiquer avec docker alors que Kubernetes utilise containerd.
• Ne pas installer crictl pour le debug bas niveau.

Pour pratiquer

Installez containerd sur une VM, configurez SystemdCgroup, puis lancez crictl info. Ensuite utilisez kubeadm config images pull avant l’init du cluster.

Notions et definitions

• Control plane: ensemble des composants qui exposent l’API et prennent les decisions.
• Worker node: machine qui execute les pods applicatifs.
• Runtime et kubelet: briques locales responsables du lancement et du suivi des conteneurs.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Dans un cluster kubeadm, l’API Server recoit les manifests, le scheduler choisit un noeud, puis le kubelet demande au runtime de lancer les conteneurs.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Verifier les prerequis systeme: swap, modules kernel, runtime, reseau.
• Initialiser ou rejoindre le cluster selon le role du noeud.
• Installer un CNI avant d’attendre des pods applicatifs fonctionnels.
• Valider CoreDNS, nodes Ready et un deploiement de test.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser les composants d’un cluster, leur installation et les responsabilites entre control plane, workers et runtime. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get nodes -o wide
• kubectl -n kube-system get pods -o wide
• sudo crictl ps ou sudo systemctl status containerd kubelet sur les noeuds

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• confondre installation reussie et cluster exploitable dans la duree
• ne pas verifier DNS, CNI, certificats et horloge apres l’installation
• oublier que la haute disponibilite depend aussi du load balancer et du reseau

Exercice conseille

Preparez une checklist post-installation: nodes Ready, CoreDNS fonctionnel, CNI actif, pod de test joignable et redemarrage d’un composant kube-system observe.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 045 – Cluster initialization et premier master avec kubeadm.

Conclusion

containerd est une brique invisible quand tout fonctionne, mais centrale dans l’installation kubeadm. Le comprendre facilite enormement le debug des noeuds Kubernetes.