kata-deploy: un moyen rapide d’installer des Kata Containers sur son cluster Kubernetes. Rapide focus sur OpenStack Zun …

Image for post
Image for post

Je vais m’interesser ici aux Kata Containers. Intel et Hyper.sh ont décidé de réunir leurs technologies de sécurisation de containers respectives au sein d’un unique projet Open Source et d’en confier la gouvernance à la Fondation OpenStack. Kata Containers, nom de code de ce projet, devient ainsi le premier projet hors OpenStack pris en gérance par la fondation Open Source. Le support des spécifications OCI (Open Container Initiative) pour le support d’images Docker et CRI (container runtime interface) pour Kubernetes est intégré au sein des Kata Containers.

Image for post
Image for post
Image for post
Image for post

Je vais me baser sur Kata-Deploy pour déployer les Kata Containers dans un cluster kubernetes existant dans Azure via AKS :

Pour cela je vais utiliser les propriétés de la virtualisation imbriquée offerte par la gamme d’instances Ev3 dans Azure :

Image for post
Image for post

En effet, Les artefacts suivants sont inclus et utilisés sur le système hôte où Kata est installé :

kata-runtime : Le runtime conforme à l’Open Containers Initiative (OCI) qui est appelé par un orchestrateur de niveau supérieur (tel que Docker* ou un CRI-shim Kubernetes).

kata-proxy : Un binaire qui s’exécute sur l’hôte pour aider à multiplexer les messages dans et démultiplexer les messages de la machine virtuelle qui héberge les conteneurs compatibles Kata. Vous verrez une de ces exécutions par module.

kata-shim : Un binaire qui s’exécute sur l’hôte pour gérer le stdio et la signalisation pour les processus de conteneur. Ceux-ci sont présentés à l’orchestrateur de niveau supérieur. Vous verrez l’un de ces processus s’exécuter par conteneur.

qemu-system-x86_64 : Un QEMU statiquement construit qui est utilisé pour fournir une isolation matérielle virtualisée. En raison de sa liaison statique, ce QEMU peut fonctionner sans problème sur la plupart des distributions x86_64.

Et cette virtualisation imbriquée est nécessaire ici puisque kata-runtime crée une machine virtuelle QEMU*/KVM pour chaque conteneur ou pod, le moteur Docker ou le kubelet de Kubernetes. Le processus de conteneur est alors généré par l’agent, un processus d’agent s’exécutant comme un démon dans la machine virtuelle. kata-agent exécute un serveur gRPC dans le client en utilisant une interface série virtio que QEMU expose comme un périphérique série sur l’hôte. kata-runtime utilise un protocole gRPC pour communiquer avec l’agent. Ce protocole permet au runtime d’envoyer des commandes de gestion de conteneur à l’agent. Le protocole est également utilisé pour passer les flux d’E/S (stdout, stderr, stdin) entre l’invité et le moteur Docker.

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Pour un conteneur donné, le processus d’initialisation et toutes les commandes potentiellement exécutées dans ce conteneur, ainsi que leurs flux d’E/S associés, doivent passer par l’interface série virtio exportée par QEMU.

Image for post
Image for post

J’ai donc un cluster Kubernetes avec deux noeuds Ubuntu 16.04 64 bits en gamme E2s_v3 (processeurs Intel Xeon E5–2673 v4 ) :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Je commence donc par utiliser Kata-Deploy via le déploiement de deux manifests dans le cluster :

Image for post
Image for post

Un pour le RBAC :

Image for post
Image for post

et le second pour Kata-Deploy en lui même :

Image for post
Image for post

Je vérifie que les noeuds de mon cluster proposent les bons labels et kata-runtime :

Image for post
Image for post

Ensuite, je vais utiliser en test la dernière version du démonstrateur FranceConnect mise au point par la DINSIC que j’ai chargé sur mon dépôt github :

Image for post
Image for post

via ce manifest pour le déploiement :

Image for post
Image for post
Image for post
Image for post

avec ce résultat :

Image for post
Image for post

J’utilise l’adresse IP fournie par le LoadBalancer induit dans le cluster Kubernetes pour accéder au démonstrateur nouvelles version :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Et la visualisation des éléments de ce cluster peut être faite via le projet SPEKT8 qui est un nouvel outil de visualisation pour les clusters Kubernetes. Il construit automatiquement des topologies logiques de l’application et de l’infrastructure, ce qui permet par exemple à une équipe SRE et Ops de comprendre, surveiller et contrôler intuitivement une application conteneurisée :

Déploiement de SPEKT8 via ce manifest prenant en compte kata-runtime :

Image for post
Image for post

et ces lignes de commande :

Image for post
Image for post

On a donc les visualisations offertes par SPEKT8 :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Mais j’ai plus de détail sur les Kata Containers en exécution via Weave Cloud :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

avec la possibilité d’accéder à la console shell de ces dernières …

Image for post
Image for post
Image for post
Image for post

Il est également possible d’automatiser le déploiement des Kata Containers en mode automatique via Kata-Manager :

Test ici avec encore une fois une VM Ubuntu 18.04 LTS 64 Bits ayant les extensions virtualisations actives :

Image for post
Image for post
Image for post
Image for post

Je vais lancer cette ligne de commande qui va faire ce qui suit :

  • Installer les paquets Kata Containers
  • Installer Docker
  • Configurer Docker pour utiliser le runtime Kata OCI par défaut
Image for post
Image for post
Image for post
Image for post

Le moteur Docker est relié à Kata-runtime :

Image for post
Image for post
Image for post
Image for post

Lancement identique de cette nouvelle version du démonstrateur FranceConnect en fournisseur de services :

Image for post
Image for post

et c’est actif :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Je termine par un rapide Focus sur le projet OpenStack Zun, un service OpenStack pour les conteneurs. Il vise à fournir un service d’API pour exécuter des applications dans des conteneurs sans avoir besoin de gérer des serveurs ou des clusters :

Image for post
Image for post
Image for post
Image for post

Je vais donc m’intéresser à la manière de faire fonctionner les Kata Containers avec OpenStack Zun en utilisant DevStack sur une instance Ubuntu 16.04 (toujours en mode virtualisation imbriquée dans Azure). Je pars donc de cette dernière :

Image for post
Image for post

et je lance les commandes suivantes qui synchronisernt DevStack à partir de GitHub, créeront un fichier local.conf, assigneront l’adresse IP hôte à ce fichier, activera les Clear Containers, lancera DevStack, et mettra les variables d’environnement à utiliser pour OpenStack Zun sur la ligne de commande :

Image for post
Image for post

Il faut attendre un peu de temps (un peu plus de 45 minutes ici) pour que le tout aboutisse :

Image for post
Image for post
Image for post
Image for post

Le dashboard est disponible :

Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post
Image for post

Je lance un conteneur test via l’image Cirros par défaut avec la ligne de commande zun (ce sont pour le moment les Clear Containers qui sont actifs ici) :

Image for post
Image for post
Image for post
Image for post

J’installe donc au sein de ce cluster local, kata-runtime, kata-shim et kata-proxy en lieu et place des Clear Containers :

Image for post
Image for post
Image for post
Image for post

avec les ajustements nécessaires pour Docker :

Image for post
Image for post
Image for post
Image for post

Je réalise un autre test avec le déploiement du démonstrateur FranceConnect localement :

Image for post
Image for post
Image for post
Image for post

L’image du démonstrateur apparaît dans le dashboard OpenStack :

Image for post
Image for post

Je peux aussi tout simplement lancer le client Docker comme précedemment avec l’option kata-runtime :

Image for post
Image for post
Image for post
Image for post

Cette évolution autour des Kata Containers est à suivre dans le contexte de la sortie par AWS du projet Firecracker. Firecracker est une alternative à QEMU qui est spécialement conçue pour faire fonctionner les conteneurs de manière sûre et efficace, et rien de plus. Firecracker fournit un modèle de périphérique minimal requis au système d’exploitation invité tout en excluant les fonctionnalités non essentielles (il n’y a que 4 périphériques émulés : virtio-net, virtio-block, console série, et un contrôleur clavier à 1 bouton utilisé uniquement pour arrêter le microVM). Ceci, ainsi qu’un processus rationalisé de chargement du noyau permet un temps de démarrage inférieur à 125 ms et une empreinte mémoire réduite. Le processus Firecracker fournit également une API de contrôle RESTful, gère la limitation du débit des ressources pour les microVM et fournit un service de métadonnées microVM pour permettre le partage des données de configuration entre l’hôte et le client :

Image for post
Image for post

Quelques éléments sur ce sujet :

Above the clouds, the sky is always blue ...

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store