Au cours des derniers mois, plusieurs changements ont eu lieu dans le raccordement traditionnel de Kubernetes à Docker et à Rkt en tant que conteneurs d'exécution. Kubernetes a publié son Container Runtime Interface (CRI) et une implémentation parallèle en cours appelée CRI-O tente de créer un pont entre Kubernetes et les OCI en runtimes compatibles, ouvrant la voie à Kubernetes d'utiliser tout conteneur d'exécution compatible OCI de manière standard.
Kubernetes s'appuie sur les conteneurs runtimes sous-jacents pour les opérations de contrôle du cycle de vie des conteneurs, telles que pull, create, delete etc. L'exécution est la mise en œuvre réelle du conteneur qui gère l'isolation de l'espace de noms et l'allocation des ressources au niveau du système d'exploitation. Plus tôt, Docker et Rkt étaient tous les deux étroitement intégrés dans le code source de Kubernetes via des API non publiques. L'ajout d'un autre conteneur d’exécution était encombrant et nécessitait un bricolage avec le code source sans garantie de stabilité. L'Interface d'exécution de conteneur (CRI), introduite en tant que fonctionnalité alpha dans Kubernetes 1.5, vise à modifier cela. Le CRI expose une interface commune qui permet aux conteneurs en runtime de se connecter au système Kubernetes, permettant aux utilisateurs d'exécuter Kubernetes pour organiser et étendre leur infrastructure non-Docker et non-rkt. Les runtimes peuvent également être des hyperviseurs à base de conteneurs comme runv.
L'Open Container Initiative (OCI), un forum de l'industrie formé pour normaliser les formats de conteneurs et les runtimes, a publié les runtime-spec en tant que norme pour les runtimes des conteneurs. Les implémentations actuelles incluent le runc, le runv de HyperHQ et un autre basé sur Clear Containers d'Intel. Le projet CRI-O, lancé par Le Projet Atomic/RedHat et d'autres contributeurs de l'industrie, met en œuvre l'API CRI de Kubernetes en utilisant des runtimes compatibles OCI. Cela signifie que n'importe quel runtime compatible OCI peut être branché sur Kubernetes via l'API CRI de ce dernier, au lieu d'avoir à implémenter un adaptateur CRI pour chacun d'eux.
À partir de maintenant, le CRI de Kubernetes a les implémentations suivantes :
- CRI-O - OCI conforme
- rktlet - Rkt container runtime
- Frakti - Conteneur basé sur l'hyperviseur
- Docker CRI shim - Prise en charge de Docker directement comme un adaptateur CRI
Source : http://blog.kubernetes.io/2016/12/container-runtime-interface-cri-in-kubernetes.html
Dans un déploiement de Kubernetes, le kubelet est l'agent local sur chaque hôte (ou le minion dans le jargon de Kubernetes) qui parle au conteneur en runtime. Avec CRI, le kubelet communiquerait avec un CRI-shim sur gRPC (un framework RPC open source), lequel front-ends appelle le runtime actuel. Le concept de Pod, la plus petite unité de déploiement de Kubernetes, a été étendu à un concept appelé PodSandbox, en maintenant une sémantique similaire. Cela pourrait se traduire par une machine virtuelle pour les runtimes basés sur l'hyperviseur et les espaces de noms Linux pour les runtimes comme Docker.