Pourquoi K8s abandonne Docker
Dans le processus d'apprentissage de la technologie des conteneurs récemment, j'ai vu quelque chose à propos de Kubernetes "abandonnant Docker", et je me demandais si l'apprentissage de Docker était toujours utile maintenant et si je devais passer à Containerd ou à d'autres runtimes maintenant.
Avec une compréhension plus profonde, ces doutes ont une part de vérité. Il y a trois ans, lorsque Kubernetes a publié la nouvelle "d'abandonner Docker", cela a vraiment provoqué un "trouble" dans la communauté Kubernetes, et l'impact s'est même propagé à l'extérieur de la communauté, ce qui a également amené Kubernetes à écrire plusieurs blogs à répéter. Expliquez pourquoi vous l'avez fait il. Trois ans se sont écoulés, et bien que Kubernetes 1.24 ait atteint l'objectif de "dépréciation", il n'y a toujours pas de compréhension claire de cette question, alors enregistrez toute l'histoire de cet incident.
Contexte : L'évolution de Kubernetes
Pour comprendre pourquoi les K8 "ont abandonné Docker", nous devons revoir l'historique du développement des K8.
Kubernetes est un framework open source d'orchestration d'infrastructure de conteneurs publié par Google dès 2014. Cette technologie a une base théorique, à savoir : Borg. Borg fait partie de l'ensemble du système d'infrastructure de Google. Borg fait partie de l'ensemble du système d'infrastructure de Google. Google a également publié un certain nombre d'articles sur Borg comme support théorique. Il porte de nombreuses technologies de pointe dans l'industrie telles que MapReduce et BigTable. Par conséquent, le système Borg a toujours été salué comme "l'arme secrète" la plus puissante au sein de Google, et c'est aussi le projet open source le moins probable de Google, et Kubernetes est développé sur cette base théorique. La figure ci-dessous est la pile d'infrastructures publiques de Google décrite dans l'article de Google Omega.
L'architecture du projet Kubernetes (comme le montre la figure ci-dessous) est très similaire à son projet prototype Borg, qui se compose de deux nœuds, Master et Node, qui correspondent respectivement aux nœuds de contrôle et aux nœuds de calcul.
-
Le nœud maître est également le nœud de contrôle. Il est le centre de l'ensemble du cluster et est avec état. Il est responsable de la maintenance de l'état de l'ensemble du cluster Kubernetes. Il se compose de trois composants indépendants : kube-apiserver pour les services d'API, kube-scheduler pour la planification et kube-controller-manager pour l'orchestration des conteneurs. Les données persistantes de l'ensemble du cluster sont traitées par kube-api-server et stockées dans Etcd. Afin d'assurer une responsabilité unique, le nœud Master ne déploie généralement pas de conteneurs.
Les conseils de Borg à Kubernetes se reflètent dans le nœud maître Bien que les détails de mise en œuvre des nœuds maîtres de Borg et de Kubernetes puissent être différents, leur point de départ est le même, c'est-à-dire comment organiser, gérer et planifier les tâches soumises par les utilisateurs.
-
Le nœud Node est également le nœud de calcul, où le conteneur déployé s'exécute réellement. Le cœur de celui-ci est le composant kubelet (il y aura également un composant kubelet sur le nœud maître). Kubelet est principalement responsable de la gestion de l'exécution du conteneur (comme le projet Docker) et utilise l'interface d'appel à distance de CRI (Container Interface d'exécution). Cette interface définit les opérations principales de l'environnement d'exécution du conteneur, telles que tous les paramètres requis pour démarrer un conteneur. C'est pourquoi le projet Kubernetes ne se soucie pas de l'environnement d'exécution du conteneur que vous utilisez. Tant que l'environnement d'exécution du conteneur peut exécuter des images de conteneur standard, il peut être connecté au projet Kubernetes en implémentant CRI.
Des environnements d'exécution de conteneur spécifiques, tels que le projet Docker, interagissent généralement avec le système d'exploitation Linux sous-jacent via la spécification d'exécution de conteneur OCI, c'est-à-dire qu'ils traduisent les requêtes CRI en appels vers le système d'exploitation Linux, tels que l'appel de Namespace et de Cgroups.
De plus, kubelet interagit également avec Device Plugin via le protocole gRPC. Ce plug-in est le composant principal utilisé par Kubernetes pour gérer les périphériques hôtes physiques tels que les GPU. C'est également une fonction à laquelle il faut prêter attention pour la formation en machine learning et un support de travail performant basé sur des projets Kubernetes.
Kubelet peut également appeler des plug-ins réseau et des plug-ins de stockage pour configurer le réseau et le stockage persistant pour les conteneurs via les interfaces CNI (Container Networking Interface) et CSI (Container Storage Interface) respectivement.
Le nom kubelet vient du composant apparenté Borglet dans le projet Borg. Cependant, le projet Borg ne prend pas en charge la technologie des conteneurs, mais utilise simplement Linux Cgroups pour limiter le processus. Cela signifie que les "images de conteneurs" comme Docker n'existent pas dans Borg, il n'est donc pas nécessaire de gérer les images de conteneurs, mais Google utilise en interne un outil de gestion de packages appelé Midas Package Manager (MPM), il peut remplacer partiellement le rôle du Image Docker. De plus, les composants Borglet n'ont pas besoin de se demander comment interagir avec Docker, ni de prendre en charge de nombreuses interfaces de technologie de conteneur telles que CRI, CNI et CSI. On peut dire que kubelet est un composant réimplémenté pour réaliser les capacités de gestion de conteneurs de Kubernetes, et n'a aucune relation d'héritage directe avec Borg.
Le projet Kubernetes n'a pas utilisé Docker comme cœur de toute l'architecture comme divers projets de "cloud de conteneurs" en même temps, mais l'a seulement implémenté comme environnement d'exécution de conteneur de niveau le plus bas. Cela équivaut à considérer Docker comme une nouvelle méthode de packaging d'applications, de sorte que l'expérience passée de Borg dans la gestion et l'orchestration des tâches à grande échelle peut être directement appliquée au projet Kubernetes.
IRC
Et en 2014, Docker était à son apogée, K8s venait de naître, et même s'il avait le soutien de Google et Borg, il était encore relativement nouveau.
Par conséquent, K8s a d'abord choisi de prendre en charge Docker.
Avance rapide jusqu'en 2016, un an après la création de la CNCF, et K8s a également publié la version 1.0, qui peut être officiellement utilisée dans les environnements de production. Tout cela montre que K8s a grandi.
Il a donc annoncé rejoindre la CNCF et est devenu le premier projet d'hébergement de la CNCF. Elle veut utiliser la puissance de la fondation pour s'unir avec d'autres constructeurs afin de "vaincre" Docker.
En version 1.5 fin 2016, K8s a introduit un nouveau standard d'interface : CRI : Container Runtime Interface container runtime interface.
CRI utilise ProtoBuffer et gPRC pour spécifier comment le kubelet doit appeler le runtime du conteneur pour gérer les conteneurs et les images, mais il s'agit d'un nouvel ensemble d'interfaces totalement incompatibles avec les appels Docker précédents.
Évidemment, il ne veut plus être lié à Docker, et permet l'accès à d'autres technologies de conteneur (telles que rkt, kata, etc.) au niveau inférieur, et peut "lancer" Docker à tout moment.
Mais à ce moment Docker est très mature, et l'inertie du marché est également très forte. Il est impossible pour les principaux fournisseurs de cloud de remplacer Docker en une seule fois.
Par conséquent, K8s ne peut fournir qu'une solution de "compromis" en même temps, en ajoutant un "adaptateur" entre kubelet et Docker pour convertir l'interface de Docker en une interface compatible CRI :
Parce que cet "adaptateur" est pris en sandwich entre kubeletDocker et Docker, il est appelé à juste titre "shim", ce qui signifie "shim".
Avec CRI et shim, bien que K8s utilise toujours Docker comme runtime sous-jacent, il a également les conditions pour se découpler de Docker, ouvrant ainsi le rideau de "l'abandon de Docker".
Conteneur
Face au défi, Docker a adopté la stratégie de "survivre avec un bras cassé" pour promouvoir sa propre reconstruction, divisant le Docker Engine original à architecture unique en plusieurs modules, dont la partie démon Docker a été donnée à la CNCF, et containerd a été formé.
En tant que projet hébergé par la CNCF, containerd doit être conforme au CRI. Cependant, pour de nombreuses raisons, Docker n'est appelé que par containerd dans Docker Engine, et l'interface externe reste inchangée, c'est-à-dire qu'elle n'est pas compatible avec CRI.
En raison de "l'entêtement" de Docker, il existe actuellement deux chaînes d'appels dans les K8 :
- Utilisez l'interface CRI pour appeler dockershim, puis dockershim appelle Docker, et Docker va à containerd
pour faire fonctionner le conteneur. - Utilisez l'interface CRI pour appeler directement containerd afin d'exploiter le conteneur.
Évidemment, parce que containerd est utilisé pour gérer les conteneurs, l'effet final des deux chaînes d'appel est exactement le même, mais la deuxième méthode supprime les deux liens de dockershim et Docker Engine, qui est plus concis et clair, et a de meilleures performances.
Lorsque Kubernetes 1.10 est sorti en 2018, containerd a également été mis à jour vers la version 1.1, officiellement intégrée à Kubernetes, et a publié un [article de blog](https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration -gos-ga / "blog post") pour afficher des données de test de performance :
À partir de ces données, on peut voir que par rapport à Docker 18.03 à l'époque, le délai de démarrage du containerd1.1Pod a été réduit d'environ 20 %, l'utilisation du processeur a été réduite de 68 % et l'utilisation de la mémoire a été réduite de 12 %. % Une telle amélioration considérable des performances est bénéfique pour les fournisseurs de cloud. On dit qu'elle est très tentante.
Déprécier Docker
En 2020, K8s 1.20 "déclare enfin officiellement la guerre" à Docker : kubelet rendra obsolète le support de Docker et sera complètement supprimé dans les futures versions.
Mais depuis que Docker est devenu presque synonyme de technologie de conteneur, et que K8s utilise Docker depuis des années, l'annonce a rapidement "senté" au fur et à mesure de sa diffusion, avec "kubelet obsolètera le support Docker" réduit à quelque chose de plus accrocheur "K8s sera obsolète" Docker".
Cela a naturellement provoqué la panique dans l'industrie informatique, et "les gens qui ne connaissaient pas la vérité" ont exprimé leur choc :
Docker, qui a été utilisé pendant si longtemps, ne peut plus être utilisé.
Pourquoi K8s traite-t-il Docker de la sorte ?
L'investissement précédent dans Docker sera-t-il réduit à zéro ? Qu'en est-il du grand nombre d'images existantes ?
En fait, si vous comprenez les deux projets CRI et containerd cités plus haut, vous saurez que ce déménagement de K8s n'a rien d'étonnant, tout est "naturel" : en fait, c'est juste "abandonner dockershim", c'est-à-dire dockershim de kubelet n'est pas un produit logiciel qui "abandonne Docker".
Par conséquent, "l'abandon de Docker" a peu d'impact sur les K8 et Docker, car ils ont changé la couche inférieure en conteneur open source, et les images et conteneurs Docker d'origine peuvent toujours fonctionner normalement. Le seul changement est que K8s contourne Docker et appelle directement containerd à l'intérieur de Docker.
Cependant, il y aura toujours un certain impact. Si K8s utilise directement containerd pour faire fonctionner les conteneurs, alors il s'agit d'un environnement de travail indépendant de Docker, et aucun des deux ne peut accéder aux conteneurs et aux images gérés par l'autre. En d'autres termes, l'utilisation de la commande docker ps ne verra pas les conteneurs s'exécuter dans K8s.
Il faudra peut-être un peu de temps à certaines personnes pour s'habituer et utiliser le nouvel outil crictl, mais les sous-commandes pour afficher les conteneurs et les images sont toujours les mêmes, telles que ps, images, etc., et il n'est pas difficile de s'adapter (si vous avez utilisé kubectl Manage K8s, cela n'a aucun effet).
K8s avait initialement prévu d'achever le travail de "dépréciation de docker" en un an, mais il a vraiment sous-estimé la fondation de Docker. La version 1.23 n'a toujours pas réussi à supprimer dockershim, elle a donc dû être reportée de six mois. Enfin, la version 1.24 a supprimé le code dockershim du kubelet.
Depuis lors, Kubernetes et Docker se sont complètement "séparés".
Conclusion : l'avenir de Docker
Alors, que réserve l'avenir à Docker ? N'y a-t-il pas de place pour cela à l'ère du cloud natif ? La réponse à cette question est évidemment non.
En tant que fondateur de la technologie des conteneurs, personne ne peut remettre en cause le statut historique de Docker. Bien que K8s ne soit plus lié à Docker par défaut, Docker peut toujours coexister sous d'autres formes de K8s.
Tout d'abord, le format d'image du conteneur ayant été standardisé (spécification OCI, Open Container Initiative), l'image Docker peut toujours être utilisée normalement dans les K8, et il n'est pas nécessaire de modifier le test de développement d'origine et le processus CI/CD. Nous pouvons toujours extraire Docker Hub ou écrire un Dockerfile pour empaqueter l'application.
Deuxièmement, Docker est une gamme complète de produits logiciels, pas seulement conteneurisée, elle comprend également de nombreux services tels que la création d'images, la distribution, les tests, et même K8s est intégré à Docker Desktop.
En termes de commodité de développement de conteneurs, Docker est encore difficile à remplacer pour le moment. La plupart des développeurs cloud natifs peuvent continuer à travailler dans cet environnement familier, en utilisant Docker pour développer des applications qui s'exécutent en K8.
De plus, bien que K8s n'inclue plus dockershim, Docker a repris cette partie du code et a construit un projet appelé cri-dockerd, qui fonctionne également, adaptant le moteur Docker à l'interface CRI afin que le kubelet puisse le passer à nouveau Operate Docker as si cela n'est jamais arrivé.
En général, bien que Docker ait été vaincu dans la guerre de l'orchestration des conteneurs et poussé au coin par les K8, il a toujours une forte vitalité. De nombreux utilisateurs fidèles et un grand nombre d'images d'applications accumulées au fil des ans constituent son principal capital et son soutien. De quoi l'épauler sur un autre chemin qui ne va pas en tête-à-tête avec les K8.
Pour les débutants, Docker est simple d'utilisation, dispose d'une chaîne d'outils complète, d'une interface conviviale, il est difficile de trouver des logiciels comparables sur le marché. Il faut dire que c'est le "meilleur choix" pour la technologie de conteneur d'apprentissage d'entrée de gamme et le cloud natif.
référence
[Pourquoi K8s abandonne Docker ? 】https://mp.weixin.qq.com/s/qEKyEseD370xWI-2yIyUzg
【Le grief entre Docker et k8s】https://www.cnblogs.com/powertoolsteam/p/14980851.html
【Pourquoi k8s abandonne docker 】 https://boilingfrog.github.io/2023/01/07/why do k8s abandonne docker/
C'est la fin du partage d'aujourd'hui
