Dernière modification le 10 août 2021
Lorsqu’il s’agit d’installer un environnement système et applicatif pour le NetDevOps, la question qui consiste à choisir entre Docker et Kubernetes ne pose plus vraiment de dilemne.
Pendant un certain temps, la réponse la plus adaptée était qu’ils étaient complémentaires, mais ce n’est plus le cas. Depuis début 2021, Kubernetes ne supporte plus Docker en tant qu’environnement d’exécution de conteneur.
Kubernetes fonctionne avec tous les environnements d’exécution de conteneur qui implémentent une norme connue sous le nom de CRI (Container Runtime Interface). Il s’agit essentiellement d’un moyen standard de communication entre Kubernetes et l’environnement d’exécution du conteneur, et tout environnement d’exécution prenant en charge cette norme fonctionne automatiquement avec Kubernetes.
Docker n’implémente pas l’interface d’exécution de conteneur (CRI). Dans le passé, il n’y avait pas autant d’options pour les environnements d’exécution de conteneurs, et Kubernetes avait implémenté le Shim Docker, une couche supplémentaire servant d’interface entre Kubernetes et Docker. Maintenant, cependant, il existe de nombreux runtimes disponibles qui implémentent le CRI, et il n’est plus logique que Kubernetes maintienne un support spécial pour Docker.
Pour vraiment comprendre pourquoi il est logique que Kubernetes se détache de Docker, il faut comprendre que Docker n’est pas vraiment un environnement d’exécution de conteneur. C’est en fait une collection d’outils qui se trouve au-dessus d’un environnement d’exécution de conteneur appelé containerd. Docker n’exécute pas directement les conteneurs. Il crée simplement une interface plus accessible et plus riche en fonctionnalités en plus d’un environnement d’exécution de conteneur sous-jacent séparé. Lorsqu’il est utilisé comme environnement d’exécution de conteneur pour Kubernetes, Docker n’est qu’un intermédiaire entre Kubernetes et containerd. Or, Kubernetes peut utiliser containerd directement comme environnement d’exécution de conteneur, ce qui signifie que Docker n’est plus nécessaire dans ce rôle d’intermédiaire.
Fin 2019, Docker Enterprise a été racheté par Mirantis, et si on étudie l’activité de cette société dans le domaine Kubernetes, il est facile de déduire que Docker Swarm n’a probablement plus beaucoup d’avenir. Fin 2020, Mirantis a proposé une distribution Kubernetes Open Source appelée K0s. Elle tire son nom de l’expression « Zero Friction, Zero Deps and Zero Cost ». Son packaging n’est pas sans rappeler celui de K3s poussé par Rancher et devenu un projet CNCF (Cloud Native Computing Foundation) en juin 2020, un programme unique écrit en Golang et ne nécessitant que peu de ressources pour fonctionner.
Rancher Labs a été racheté par SUSE en juillet 2020, donnant un élan supplémentaire à K3s et à son écosystème (K3OS, K3d, K3c…).
K0s et K3s sont tous les deux considérés comme d’un niveau production et il n’est pas question ici de se lancer dans une bataille pour savoir lequel est le meilleur, le plus simple ou le plus performant. Il est surtout intéressant de voir la richesse des choix de distributions Kubernetes prêtes pour la production en Edge Computing.
Pour administrer un noeud ou un cluster Kubernetes, Portainer (> 2.0) est un choix intéressant de part le fait que l’outil d’administration est embarqué dans le cluster sous forme de conteneur avec un accès web distant. Toute solution a ses avantages et ses inconvénients et il est intéressant de voir que Mirantis a fait un autre choix en rachetant Lens en août 2020. Lens est un IDE Kubernetes qui se présente sous la forme d’un client lourd installable sur Windows, Linux ou macOS.
MicroK8s est un packaging Kubernetes de niveau production développé par Canonical et c’est un environnement très apprécié des développeurs. Cette distribution ne se concentre pas sur la réduction des ressources utilisées comme K3s ou K0s, mais focalise plutôt sur la simplicité de déploiement apportée par l’outil Snap qui permet d’isoler les applications.
Comme chacune des distribution évoquée plus haut, MicroK8s a ses propres particularités. Son packaging est bien fini avec une orientation « localhost » et Ubuntu par défaut, tout en bénéficiant de l’écosystème Canonical (MAAS, LXD, MicroK8s et Ceph sur Ubuntu).
