À partir de la v1.20, Kubernetes abandonne Docker en tant queruntime deconteneur.
Mais ne paniquez pas. Tout n'est pas aussi mauvais qu'il y paraît à première vue.
TL et DR. Kubernetes abandonne Docker au profit des environnements d' exécution Container Runtime Interface (CRI) spécialement conçus pour Kubernetes. Les images Docker continueront de fonctionner comme d'habitude dans tous les environnements d'exécution.
Pour les utilisateurs finaux de Kubernetes, peu de choses changeront. Tout cela ne signifie pas que Docker «mourra» ou qu'il ne devrait / ne devrait plus être utilisé pour le développement. Docker continuera à être un excellent outil pour créer des conteneurs, et les images
docker build
créées avec lui continueront de fonctionner sur le cluster K8s.
Si vous utilisez des services Kubernetes gérés tels que GKE ou EKS, vous devez vous assurer que vos nœuds de calcul utilisent une version prise en charge du runtime et le faire avant que la prise en charge de Docker ne soit supprimée dans une future version de K8. Si vos nœuds ont des configurations spécifiques, vous devrez probablement effectuer une mise à niveau pour répondre aux exigences d'environnement et d'exécution appropriées. Nous vous recommandons de contacter votre fournisseur de services et de discuter de tous les problèmes de planification des tests et des mises à niveau.
Si vous déployez vous-même les clusters, vous devrez également apporter les modifications appropriées pour éviter les problèmes. Lors de la mise à niveau vers la v1.20, vous recevrez un avertissement d'obsolescence de Docker. Les développeurs envisagent d'abandonner complètement Docker dans la version 1.23, dont la sortie est prévue pour la fin de 2021. Avec sa sortie, vous devrez basculer vers l'un des environnements exécutables compatibles - par exemple, containerd ou CRI-O. Assurez-vous simplement que l'environnement que vous choisissez prend en charge les configurations du démon Docker que vous utilisez (par exemple, la journalisation).
Sur quoi porte toute cette confusion et pourquoi tout le monde est-il si inquiet?
En fait, nous parlons de deux environnements complètement différents, et cela crée de la confusion. À l'intérieur du cluster Kubernetes, il y a un soi-disant environnement d' exécution de conteneur , qui est responsable du chargement et de l'exécution des images de conteneur. Et Docker est très populaire en tant qu'outil d'organisation de cet environnement (containerd et CRI-O sont également largement connus). Cependant, Docker n'a pas été conçu pour être intégré à Kubernetes, ce qui pose un certain nombre de problèmes.
"Docker" n'est pas un outil séparé, mais une pile technologique entière, et l'un de ses composants s'appelle "containerd" (nous en avons parlé plus en détail ici - environ Transl.)et agit comme un runtime de haut niveau pour les conteneurs. Docker est populaire et pratique en raison du grand nombre de modules complémentaires pour les utilisateurs qui simplifient considérablement le processus d'interaction avec cet outil pendant le développement. Cependant, toutes ces améliorations UX sont inutiles pour Kubernetes, car il n'est pas humain.
Ce niveau d'abstraction convivial oblige le cluster Kubernetes à utiliser un autre outil, Dockershim, pour atteindre ce dont il a vraiment besoin: containerd. Et c'est mauvais, car une telle couche supplémentaire doit être entretenue et elle peut également «se casser». En réalité, il s'avère ce qui suit: dans Kubernetes v1.23, Dockershim sera supprimé de Kubelet - en conséquence, Docker perdra le support en tant que conteneur d'exécution. La question se pose: si containerd est déjà inclus dans la pile Docker, pourquoi Kubernetes a-t-il besoin de Dockershim?
Le fait est que Docker n'est pas compatible avec Container Runtime Interface.(CRI). S'il était compatible, nous n'aurions pas besoin d'une couche supplémentaire et tout irait bien. Cependant, ce n'est pas la fin du monde et pas un motif de panique. Remplacez simplement le runtime Docker par un autre pris en charge.
Veuillez noter que si vous utilisez le socket Docker (
/var/run/docker.sock
) dans le cadre d'un flux de travail normal, vous ne pourrez plus travailler avec celui-ci après avoir basculé vers un autre environnement. Ce modèle est souvent appelé «Docker dans Docker». Il existe de nombreux outils différents pour contourner ce problème, notamment kaniko , img et buildah .
Comment ce changement affectera-t-il les développeurs? Allons-nous toujours écrire des fichiers Dockerfiles? Devons-nous créer des images à l'aide de Docker?
Ce changement dont on parle beaucoup concerne un environnement complètement différent de celui que la plupart des gens utilisent pour interagir avec Docker. L'installation de Docker pour le développement n'a rien à voir avec le runtime à l'intérieur du cluster Kubernetes. Oui, c'est déroutant, je sais ...
Même après l'innovation, Docker restera le même outil utile pour les développeurs. Les images générées par Docker peuvent fonctionner avec plus que simplement Docker. Ce sont des images OCI complètes. Toute image compatible OCI aura la même apparence sur Kubernetes, quel que soit l'outil avec lequel elle a été créée. containerd et CRI-O sont excellents pour récupérer ces images et les exécuter. C'est pourquoi la norme de conteneur a été créée.
Donc, des changements sont à venir. Certaines personnes se heurteront, bien entendu, à certains problèmes. Mais il n'y a rien à regretter ou à s'inquiéter, car le progrès est une chose cool. Selon la façon dont vous utilisez Kubernetes, cela peut signifier une inaction totale ou un minimum d'effort pour vous. À long terme, une telle innovation ne fera que faciliter les choses.
Si les changements à venir vous déroutent toujours, alors tout va bien. Il existe de nombreuses pièces mobiles dans Kubernetes, et personne n'en est à 100% expert. N'hésitez pas à poser des questions, quel que soit le niveau d'expérience ou la difficulté! Notre objectif est de préparer au maximum tout le monde aux changements à venir. <3 Nous espérons que cet article a répondu à la plupart de vos questions et dissipé toutes les préoccupations et préoccupations!
Besoin de plus de réponses? Consultez la FAQ sur l'abandon de Dockershim .
PS du traducteur
Vous pouvez également trouver une réponse détaillée de Tim Hockin , l'un des développeurs Kubernetes, dans la discussion sur ce sujet sur Reddit .
Lisez aussi sur notre blog:
- "Un runtime mature pour les conteneurs: containerd est devenu " diplômé "de la CNCF ;
- « Of Red Hat remplace Docker sur Podman »;
- "L' intégration de containerd avec Kubernetes, en remplacement de Docker, est prête pour la production ";
- « CRI-O - Alternative Docker pour fonctionner dans des conteneurs Kubernetes ».