Depuis quelques années, les microservices et les solutions d’orchestration de conteneurs sont au cœur des projets de développement informatiques. En entreprise, les équipes tech maitrisent désormais le déploiement de Kubernetes pour assurer le bon fonctionnement des microservices. On peut aujourd’hui parler de maturité pour cet outil d’orchestration de conteneurs et force est de constater que cela a ouvert la voie à de nombreux standards, notamment open source.
Pourquoi de nouveaux standards pour Kubernetes ?
De plus en plus de professionnels se ruent vers les standards ouverts pour compléter les systèmes comme Kubernetes. Ces standards open source définissent les meilleures pratiques pour la mise en place et l’usage de Kubernetes. On peut remercier la communauté open source de Kubernetes pour leur contribution. Cela permet d’éviter le vendor lock-in pour les entreprises. Aujourd’hui, les entreprises de toutes les tailles préfèrent se tourner vers les solutions open source pour accélérer le développement de leurs produits et pour innover.
Cloud Native Computing Foundation a lancé une version open source de l’outil, comprenant les composants formant l’ossature de Kubernetes pour l’orchestration de conteneurs. Cela étant dit, l’usage de ce type d’outil expose les professionnels à quelques risques. Sont couramment évoqués les problèmes liés aux bugs, les problèmes de fonctionnement, le manque de sécurité, le manque d’interopérabilité et la difficulté à résoudre des problèmes techniques.
Bien qu’il soit question d’outils Open Source, certains observateurs redoutent que des entreprises fournissent des versions modifiées de Kubernetes à leurs clients en s’assurant de créer une certaine dépendance. Ce qui va à l’encontre des principes de l’Open Source.
Les principaux standards de Kubernetes
Docker et CRI sont sans doute les plus connus mais une multitude de standards ont émergés au fil du temps. Zoom sur les principaux standards de K8s.
Docker
Sans avoir été réellement conçu pour l’orchestration de conteneurs, Docker a été un standard depuis longtemps grâce au composant dockershim. Il reste le premier choix pour des millions de développeurs qui travaillent sur les applications conteneurisées. Cela étant dit, l’usage de Docker en tant que runtime pour Kubernetes a été remis en question Docker n’a plus été de la partie depuis Kubernetes 1.23.
CRI (Container Runtime Interface)
Disponible depuis la sortie de Kubernetes 1.5 (en alpha), CRI est une interface qui permet à Kubernetes et les plugins de communiquer entre eux. C’est au niveau des nœuds du cluster que le plugin CRI est installé dans la mesure où ils sont amenés à gérer le bas niveau des conteneurs. Le plugin implémente deux services : « RuntimeService » et « ImageService ».
OCI (Open Container Initiative)
Encouragé par la Linux Foundation, OCI est une structure légère conçue pour devenir un standard concernant notamment les formats de conteneurs et les runtimes. Lancé par un consortium formé par les grands noms du milieu, comme Docker ou encore CoreOS, OCI comprend trois spécifications, à savoir « runtime-spec », « image-spec » et « distribution spec ».
CNI (Container Network Interface)
Initiée par CoreOS et supportée par de nombreux projets comme Red Hat, Cloud Foundry, RKT et bien sur Kubernetes, CNI propose des plugins pour la configuration des interfaces réseaux dans les containers.
CSI (Container Storage Interface)
Ce plugin pour Kubernetes permet aux applications conteneurisées de consommer les baies de stockage en tant que stockage persistant. Cette initiative combine l’interface des systèmes d’orchestration de conteneurs, en l’occurrence Kubernetes aux fournisseurs de stockage.
SMI (Service Mesh Interface)
Un SMI offre une interface standard pour le service mesh ou maillage de service sur K8s. La spécification SMI couvre les fonctionnalités des service mesh les plus courantes comme la gestion du trafic, la télémétrie ou encore le chiffrement et le déplacement à travers les services.
