Kubernetes coupe officiellement le cordon avec Docker Engine

Avec Kubernetes 1.24, c’en est officiellement terminé de la prise en charge de Docker Engine. Quels changements cela suppose-t-il ?

Préemption des pods, redimensionnement des volumes, publication d’API… Autant d’aspects sur lesquels il y a du nouveau avec Kubernetes 1.24. Mais le « gros morceau », c’est la fin de la prise en charge de Docker Engine.

Ce runtime – composant qui gère le tirage et l’exécution des images de conteneurs – était sur la sellette depuis plusieurs années. La raison : son incompatibilité avec la CRI (Container Runtime Interface). C’est-à-dire l’interface devenue le standard pour la connexion de ces briques, comme la CSI l’est devenue pour le stockage et la CNI pour le réseau.

Pour que Docker Engine continue à fonctionner, on avait intégré du code provisoire (un shim) dans Kubernetes. Il faisait office de couche d’abstraction, permettant d’utiliser le runtime comme si celui-ci était compatible CRI. Mais il ne ne donnait pas accès à certaines fonctionnalités « modernes » comme la v2 de cgroups (isolation de processus). Et impliquait un processus de maintenance complexe, en plus de poser quelques problèmes (par exemple de journalisation).

Ce changement n’affecte pas les environnements de développement. Il concerne les clusters qui utilisent le runtime. Quant aux images construites avec Docker, elles continueront à fonctionner avec les équivalents CRI.

Certains éléments ne marcheront en revanche plus tels quels, comme l’imbrication de conteneurs via le socket Docker. Le projet Kubernetes liste des options alternatives dans son guide de migration. Tout en appelant à surveiller :

– Les agents de télémétrie qui dépendent de Docker Engine
– L’éventuelle utilisation de registres privés, dont il faudra généralement reconfigurer les paramètres
– Les scripts et applications sur des nœuds hors de l’infrastructure Kubernetes

La cible de migration la plus évidente ? containerd, sur lequel s’appuie Docker Engine. Pour qui souhaiterait continuer à utiliser ce dernier, il y a une solution : cri-dockerd, une extension que maintient Mirantis (détenteur des activités B2B de Docker).

Les Kubernetes managés ont préparé le terrain

Qu’en est-il sur les Kubernetes managés des grands fournisseurs cloud ? Chez AWS, containerd deviendra le runtime par défaut à partir des images machine (AMI) basées sur Kubernetes 1.23 (sortie en août 2022).
Les AMI basées sur Kubernetes 1.17 à 1.22 utilisent Docker Engine par défaut, mais disposent d’une option pour activer containerd.

Sur Azure, pour les nœuds Linux, c’est containerd par défaut depuis Kubernetes 1.19. Pour les nœuds Windows Server, c’est depuis Kubernetes 1.23. Sur les plus anciens, on peut paramétrer containerd pour qu’il soit prêt à activer.

Sur GKE, l’offre managée de Google Cloud, la fin de la prise en charge des images de nœuds utilisant Docker interviendra avec Kubernetes 1.24. containerd est déjà l’environnement d’exécution par défaut pour tous les nouveaux nœuds depuis la version 1.19 sous Linux et la 1.21 sous Windows.

Avec la version 1.23 de GKE, certains éléments ne sont déjà plus possibles.