Ce Durée – 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 le CRI (Container Runtime Interface). C’est-à-dire que l’interface est 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 cale) dans Kubernetes. Il faisait office de couche d’abstraction, permettant d’utiliser le Durée comme si celui-ci était compatible CRI. Mais il ne permet pas d’accéder à 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 Durée. 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 passant par 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 ? conteneurd, sur lequel s’appuie Docker Engine. Pour qui conserverait continuer à utiliser ce dernier, il y a une solution : cri-dockerd, une extension que conservera 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, le conteneur deviendra le Durée 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 le conteneur.
Sur Azure, pour les nœuds Linux, c’est conteneurisé 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 gérée de Google Cloud, la fin de la prise en charge des images de nœuds utilisant Docker interviendra avec Kubernetes 1.24. Le conteneur 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.
Illustration principale © Dmitry Kovalchuk – Adobe Stock
