fermer
Applications

Le support de Docker est déprécié sur Kubernetes, mais pas complètement

6846390 preview
Le support de Docker est déprécié sur Kubernetes, mais pas complètement

À partir de la version 1.20, Kubernetes ne supportera plus Docker de la même manière qu’auparavant. Mais si certains administrateurs ont rapidement paniqué, le changement n’est pas aussi drastique qu’il n’y paraît. Dans les notes de version de Kubernetes 1.20, on peut lire : « Le support de Docker dans le kubelet est maintenant obsolète et sera supprimé dans une prochaine version ».

Selon un rapport de The Register, l’ambassadeur de la CNCF, Ian Coldwater, est allé sur Twitter pour avertir les développeurs du changement, en disant « Le support de docker est déprécié dans Kubernetes. Vous devez y prêter attention et vous y préparer. CELA BRISERA VOS CLUSTERS ».

Le changement imposé par la société pourrait être un choc pour tous ceux qui ont été occupés à faire tourner des conteneurs et à ne pas prêter attention au développement de Kubernetes. Mais, ce n’est pas vraiment un problème. Dans les notes de version et dans un article de blog qui a suivi l’annonce, les développeurs de Kubernetes expliquent que tout ce qu’ils font est de déprécier Docker en tant que conteneur d’exécution après la v1.20 de Kubernetes.

En effet, il semble que l’histoire ne se limite pas à cela : « Le kubelet utilise un module appelé “dockershim” qui met en œuvre le support du CRI pour Docker et il a connu des problèmes de maintenance dans la communauté de Kubernetes. Nous vous encourageons à évaluer le passage à un container runtime qui soit une implémentation complète de CRI (v1alpha1 ou v1 compliant) dès qu’ils seront disponibles », peut-on lire dans les notes de publication.

Kelsey Hightower, membre du personnel de Google Cloud, s’est également penchée sur la question, précisant que Docker n’est pas uniquement destiné aux conteneurs. « Il y a des images de conteneurs. Docker peut les construire. Il y a des registres de conteneurs. Docker peut les pousser et les récupérer. Il y a des durées d’exécution des conteneurs. Docker est l’un d’entre eux. Il y a des processus de conteneur. Docker peut les créer, mais Linux est toujours le patron ».

Peu d’impact ?

Pour les utilisateurs finaux de Kubernetes, il ne devrait pas y avoir beaucoup de retombées de ce changement, comme l’expliquent les développeurs : « Les images produites par Docker continueront à fonctionner dans votre cluster avec tous les runtimes, comme elles l’ont toujours fait ». Cependant, si vous utilisez vos propres clusters, vous devrez vous assurer que vous n’utiliserez pas Docker comme un container runtime à l’avenir. Si vous le faites, vous recevrez un avertissement de dépréciation avec la version actuelle v1.20. Si vous ne voulez pas que vos clusters soient brisés, assurez-vous de passer à l’un des containers runtime conformes avant que le support d’exécution de Docker ne soit supprimé, ce qui est actuellement prévu pour la v1.22 prévue pour la fin 2021.

Tout compte fait, cette décision vise à faire appliquer les meilleures pratiques et bien d’autres choses encore. En d’autres termes, Docker peut faire beaucoup plus, et il continuera à le faire. Ce changement a été décrit en détail sur le dernier blog de Kubernetes, Don’t Panic : Kubernetes and Docker, que vous pouvez lire ici.

Tags : DockerKubernetes
Yohann Poiron

The author Yohann Poiron

J’ai fondé le BlogNT en 2010. Autodidacte en matière de développement de sites en PHP, j’ai toujours poussé ma curiosité sur les sujets et les actualités du Web. Je suis actuellement engagé en tant qu’architecte interopérabilité.