Remarque perev. : Nous avons écrit plus d'une fois à propos de containerd et d' autres runtimes pour Kubernetes. La nouvelle publication est une traduction de l'annonce récente d'une étape importante dans le développement de containerd, publiée sur le blog officiel du projet Kubernetes. Le texte a été écrit par des employés de Google et d'IBM, qui (bien sûr, avec Docker Inc) contribuent de manière significative à l'amélioration de containerd.Plus tôt dans le blog - dans la note
Containerd apporte plus d'options d'exécution de conteneurs pour Kubernetes - nous avons présenté une version alpha de l'intégration de containerd avec Kubernetes. Les 6 prochains mois de développement ont conduit au fait que l'intégration est devenue publique! Cela signifie que vous pouvez désormais utiliser
containerd 1.1 comme environnement d'exécution pour les conteneurs des clusters Kubernetes en production.
Containerd 1.1 fonctionne avec Kubernetes version 1.10 et supérieure, prend en charge toutes les fonctionnalités de Kubernetes. Dans l'infrastructure de test de Kubernetes, la couverture des tests d'intégration containerd sur Google Cloud Platform est devenue la même que l'intégration avec Docker (voir
tableau de bord de test ).
«Nous sommes ravis de voir Container atteindre rapidement cette étape importante. Chez Alibaba Cloud, nous avons commencé à utiliser activement containerd dès ses débuts et, grâce à l'accent mis sur la simplicité et la fiabilité, nous avons fait de containerd le moteur de conteneur par défaut dans son produit Serverless Kubernetes, qui impose des exigences élevées en termes de performances et de stabilité. Containerd sera sans aucun doute le principal moteur de l'ère des conteneurs et conduira au développement de l'innovation. » - Xinwei, ingénieur à temps plein d'Alibaba Cloud
Améliorations architecturales
L'architecture d'intégration de containerd avec Kubernetes a changé deux fois. Chacune de ses étapes évolutives s'est stabilisée et a amélioré l'efficacité de la pile.
Containerd 1.0 - CRI-Containerd (a cessé d'exister)
Dans containerd 1.0, le démon cri-containerd était requis pour l'interaction entre
Kubelet et containerd
(nous en avons parlé à la fin de cet article - environ Transl. ) . Ce démon a envoyé des requêtes à l'
interface d'exécution de conteneur (CRI) de
Kubelet et utilisé containerd pour gérer correctement les conteneurs et les images de conteneur. Cette approche a éliminé un lien supplémentaire dans la pile par rapport à l'implémentation Docker CRI (
dockershim ) -
voir l'illustration ci-dessus .
Cependant, cri-containerd et containerd 1.0 étaient deux démons distincts interagissant sur GRPC. Un démon supplémentaire dans cet ensemble a rendu la vie difficile aux utilisateurs à la fois pour comprendre l'appareil et pendant le déploiement, et a également généré des frais généraux inutiles pour l'interaction.
Containerd 1.1 - Plugin CRI (version actuelle)
Dans containerd 1.1, le démon cri-containerd a été refait dans le plugin CRI containerd. Ce plugin est intégré à containerd 1.1 et est activé par défaut. Contrairement à cri-containerd, le plugin interagit avec containerd en invoquant directement les fonctions nécessaires. La nouvelle architecture a rendu l'intégration plus stable et productive, éliminant un autre lien (GRPC) de la pile. Maintenant containerd 1.1 peut être utilisé directement dans Kubernetes, et le démon cri-containerd n'est plus requis.
Performances
L'un des principaux objectifs de containerd 1.1 était d'améliorer les performances. Des optimisations ont été réalisées au niveau du temps de démarrage et des ressources utilisées par le démon.
Les résultats suivants sont une comparaison de containerd 1.1 et Docker 18.03 CE. Intégration containerd 1.1 utilise le plug-in CRI intégré et l'intégration pour Docker 18.03 CE fonctionne avec dockershim. Les résultats ont été générés à l'aide du test de performances des nœuds Kubernetes, qui fait partie des
tests e2e pour les nœuds K8s . La plupart des données de comparaison sont accessibles au public sur le
tableau de bord des performances du
nœud .
Retard de démarrage du foyer
Les résultats du
benchmark de démarrage par lots de 105 pods montrent que l'intégration de containerd 1.1 a moins de retard dans le démarrage d'un pod que Docker 18.03 CE avec dockershim (le plus petit est le mieux).
CPU et mémoire
Dans un état inactif, l'intégration containerd 1.1 avec 105 foyers consomme moins de processeur et de mémoire que l'intégration Docker 18.03 CE avec dockershim. Les résultats peuvent varier en fonction du nombre de foyers lancés sur le nœud - le nombre de 105 foyers est sélectionné, car la valeur par défaut est désormais la valeur maximale pour les foyers personnalisés sur le nœud.
Comme le montrent les graphiques ci-dessous, l'intégration de containerd 1.1 avec
Kubelet consomme 30,89% de CPU en moins et 11,30% de mémoire RSS en moins (taille de l'ensemble résident), ainsi que 12,78% de mémoire RSS en moins consommée par le runtime du conteneur .
Ajout du traducteur
Il convient de noter qu'une autre solution alternative, CRI-O , continue de se développer. En particulier, lors d'un Open Source Summit Japan 2018 ces jours-ci, un employé de NTT a présenté un rapport avec une comparaison approfondie des environnements exécutables existants pour les conteneurs. Et voici une de ses diapositives comparant leurs performances:
crictl
L'interface de console Container Runtime (CLI) est un outil utile pour identifier les problèmes dans le système et l'application. Lors de l'utilisation de Docker comme environnement de conteneur dans Kubernetes, les administrateurs système se rendent parfois sur le site de Kubernetes pour exécuter des commandes Docker et collecter des informations sur le système et / ou l'application. Par exemple, ils peuvent utiliser
docker ps et
docker inspect pour vérifier l'état du processus, les
docker images pour obtenir une liste d'images sur le nœud, les
docker info pour obtenir la configuration du runtime pour les conteneurs, etc.
Pour containerd et tous les autres environnements compatibles CRI tels que dockershim, nous vous recommandons d'utiliser
crictl comme alternative CLI aux commandes de la console Docker pour analyser les problèmes sur les pods, les conteneurs et les images de conteneurs hébergés sur les nœuds Kubernetes.
crictl est un utilitaire qui offre des fonctionnalités similaires à la Docker CLI et fonctionne aussi bien pour tous les environnements d'exécution pour les conteneurs compatibles avec CRI. Il peut être trouvé dans le
référentiel kubernetes-incubator / cri-tools ; la version actuelle est
cri-tools v1.11.0 (la version a été corrigée pour la version actuelle il y a 3 jours au lieu de v1.0.0-beta.1 , indiquée dans l'article original, approximativement traduit ) . Bien que l'utilitaire
crictl soit conçu pour être similaire à la Docker CLI, offrant une transition simple pour les utilisateurs, il n'en est pas une copie complète. Quelques différences importantes sont décrites ci-dessous.
Utilisation limitée: crictl est un outil de dépannage
crictl ne remplace
kubectl docker ou
kubectl - son utilisation est limitée à la portée de l'identification et de l'analyse des problèmes. L'interface de la console Docker offre un riche ensemble de commandes, ce qui en fait un outil de développement très utile. Cependant, ce n'est pas la meilleure option pour le dépannage sur les nœuds Kubernetes. Certaines commandes Docker (par exemple, le
docker network Docker et la
docker build Docker) sont inutiles pour Kubernetes, et certaines (par exemple, Docker Rename) peuvent tout casser. Le but de
crictl est de fournir suffisamment de commandes pour identifier les problèmes sur les nœuds qui sont sûrs à utiliser dans les environnements de production.
Focus sur Kubernetes
crictl offre une vue des conteneurs plus compréhensible dans le monde Kubernetes. L'interface de la console Docker ne fonctionne pas avec les concepts de base de Kubernetes, tels que under (pod) et namespace (
namespace ), ce qui empêche la représentation visuelle des conteneurs et des foyers
(l'importance de ce problème est vraie, déjà dans le contexte de surveillance, dont nous avons récemment parlé dans ce rapport - note . perev. ) . Un tel exemple est
docker ps montrant des noms longs et obscurs pour les conteneurs Docker et une liste de conteneurs de pause avec les conteneurs d'application:
Cependant, les
conteneurs de pause font partie de la mise en œuvre du foyer, où un tel conteneur est utilisé pour chaque foyer; ils ne doivent pas être affichés lors de l'affichage de conteneurs faisant partie du foyer.
crictl , en revanche, a été créé pour Kubernetes. L'utilitaire fournit différents ensembles de commandes pour les foyers et les conteneurs. Par exemple,
crictl pods affiche des informations sur les
crictl pods et
crictl ps affiche uniquement des informations sur les conteneurs d'application. Toutes les données sont formatées dans une vue tabulaire:
Un autre exemple - dans les
crictl pods il y a un argument
--namespace , qui permet de filtrer les pods par les espaces de noms définis dans Kubernetes:
Pour plus d'informations sur l'utilisation de crictl avec containerd, voir ici:
Mais qu'en est-il du Docker Engine?
Nous entendons souvent la question suivante: «Est-ce que le passage à containerd signifie que je ne peux plus utiliser le Docker Engine?», Et la réponse courte est «NON».
Docker Engine est basé sur containerd. La prochaine version de Docker Community Edition (Docker CE) utilisera containerd version 1.1. En conséquence, il aura un plug-in CRI intégré et activé par défaut. Cela signifie que les utilisateurs auront la possibilité de continuer à travailler avec le moteur Docker pour d'autres scénarios typiques, ainsi que la possibilité de configurer Kubernetes pour utiliser le conteneur sous-jacent fourni avec le moteur Docker et qui est simultanément utilisé par le moteur Docker sur le même hôte. Jetez un œil au schéma architectural ci-dessous montrant comment le même containerd est utilisé par le Docker Engine et
Kubelet :
Étant donné que containerd est utilisé à la fois par
Kubelet et le Docker Engine, les utilisateurs qui choisissent de s'intégrer à containerd obtiendront non seulement toutes les nouvelles fonctionnalités de Kubernetes, des améliorations des performances et de la stabilité, mais aussi la possibilité d'utiliser le Docker Engine, comme auparavant, pour d'autres besoins.
Le mécanisme d'
espace de noms dans containerd garantit que
Kubelet et le moteur Docker n'auront pas accès aux conteneurs et aux images qu'ils n'ont pas créés. Cela signifie qu'ils n'interféreront pas les uns avec les autres, ainsi que:
- Les utilisateurs entrant la
docker ps ne verront pas les conteneurs créés dans Kubernetes. Utilisez crictl ps pour cela. Inversement, les utilisateurs ne verront pas les conteneurs créés dans la Docker CLI sur Kubernetes ou la commande crictl ps . Les commandes crictl create et crictl run sont uniquement destinées au dépannage. Il n'est pas recommandé d'exécuter manuellement des foyers ou des conteneurs à l'aide de crictl sur les nœuds de production. - Les utilisateurs saisissant la
docker images ne verront pas les images de Kubernetes. Pour ce faire, utilisez la commande crictl images . À l'inverse, Kubernetes ne verra pas les images créées par les commandes Puller Docker Load et Docker Build. Pour ce faire, utilisez la commande crictl pull , ainsi que ctr cri load , si vous souhaitez charger l'image.
Résumé
- Containerd 1.1 a un support CRI natif. Il peut être utilisé directement par Kubernetes.
- Containerd 1.1 est prêt pour la production.
- Containerd 1.1 a de bonnes performances en termes de temps de démarrage du pod et d'utilisation des ressources système.
- crictl est un utilitaire de console (CLI) pour communiquer avec containerd 1.1 et d'autres environnements d'exécution pour les conteneurs qui sont conformes à CRI afin d'identifier les problèmes sur le nœud.
- Containerd 1.1 sera inclus dans la prochaine version stable de Docker CE. Les utilisateurs auront la possibilité de continuer à travailler avec Docker dans les cas non-Kubernetes et de configurer Kubernetes pour utiliser le containerd sous-jacent qui fait partie de Docker.
Nous tenons à remercier tous ceux de Google, IBM, Docker, ZTE, ZJU et les développeurs individuels qui ont contribué et rendu tout cela possible!
Pour une liste détaillée des modifications apportées à containerd 1.1, consultez les
notes de publication .
Comment essayer
Instructions pour configurer un cluster Kubernetes pour utiliser containerd comme runtime par défaut:
- pour un cluster sur GCE, levé en utilisant
kube-up.sh , - ici ; - pour installer un cluster de nombreux nœuds en utilisant Ansible et kubeadm - ici ;
- pour créer un cluster à partir de zéro dans Google Cloud - voir " Kubernetes the Hard Way ";
- pour une installation manuelle à partir des archives tarball - ici ;
- pour l'installation à l'aide de LinuxKit sur une machine virtuelle locale - ici .
Comment contribuer
Plugin CRI Containerd - Un projet open source sur GitHub, qui fait partie de containerd:
https://github.com/containerd/cri . Toutes les modifications proposées sont les bienvenues sous forme d'idées, de tickets, de corrections. Ce
guide de démarrage pour les développeurs est un bon point de départ pour apporter des modifications.
PS du traducteur
Lisez aussi dans notre blog: