L'Open Infrastructure Summit de Denver se tenant sur 3 jours, voici notre dernier compte-rendu pour la journée du mercredi.

Bon courage aux développeurs qui restent à Denver jusqu'à la fin de la semaine pour le Project Team Gathering (PTG).

Sessions

Drivers ML2 dans Neutron

Une présentation consacrée aux différentes options possibles pour implémenter la couche niveau 2 de Neutron. On parle de ML2, pour Modular Layer 2. ML2 dans Neutron a remplacé (dès la version OpenStack Havana) le système de drivers monolithiques au profit de plus de flexibilité, et notamment la possibilité au sein d'un cloud d'utiliser différents drivers implémentant la couche niveau 2. On parle de drivers ML2. Par la même occasion, il a été possible grâce à ML2 de réduire la duplication inutile de code entre drivers.

Lorsqu'on rentre dans le détail de ML2, il faut distinguer les type drivers des mechanism drivers.

Parmi les type drivers, on trouve flat, vlan ou encore vxlan, c'est-à-dire les différents types possibles pour un réseau niveau 2 en terme de protocole.

Les mechanism drivers implémentent le réseau niveau 2, on retrouve : Linux Bridge, OpenVSwitch (OVS), SRIOV et d'autres encore.

Les orateurs font un compte-rendu des benchmarks qu'ils ont réalisés afin de comparer les performances des différents mechanism drivers. Ces tests se font bien entendu dans des environnements identiques par ailleurs. À chaque fois, les tests se font dans une instance connectée à 4 réseaux providers flats, respectivement de 10, 25, 40 et 100 Gbit/s. On prendra comme référence et point de comparaison les performances en bare metal.

Au-delà des traditionnels Linux Bridge et OVS, sont notamment testés : OVS avec DPDK, SRIOV - direct interface, SRIOV - indirect interface, OVS avec ASAP² (hardware offloading Melanox).

Parmi les éléments de conclusion, on peut noter que les différences de performances ne sont pas notables sur l'interface 10G. Autrement dit, la question du choix mechanism driver dans une optique de performances n'a de sens que pour des réseaux 25G et plus.

Très clairement, le choix de SRIOV - direct interface permet, y compris jusqu'à 100G, d'obtenir des performances très proches du bare metal.

Néanmoins les performances ne peuvent pas être un critère de choix unique, il est rappelé de prendre en compte d'autres critères comme : qualité du support upstream, taux d'adoption, couverture fonctionnelle (certains choix ne permettront pas de faire de live migration d'instances - par exemple), besoin éventuelle de compatibilité matérielle, etc.

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23525/pushing-packets-how-do-the-ml2-drivers-stack-up

StarlingX v2.0 : Edge virtualization platform

StarlingX est l'un des nouveaux projets chapotés par la Fondation OpenStack. Le but est de fournir facilement du Edge computing. StarlingX est basé sur CentOS et fournit une plateforme d'orchestration pour du bare metal, des VMs ainsi que des conteneurs.

Les cas d'usage sont multiples :

• vRAN (Virtual Radio Access Network) : pour la 5G par exemple
• Secteur médical (calculs, réalité virtuelle, etc.)
• MEC (Multiple Access Edge Computing) : voitures autonomes, IOT, etc.

La version 1.0 de StarlingX fournissait uniquement une plateforme OpenStack optimisée pour le Edge. La version 2.0 présentée aujourd'hui change de technologie et fournit un cluster Kubernetes sur lequel il est possible de déployer OpenStack en option.

Kubernetes devient donc la base sur laquelle StarlingX repose ses services :

• Une registry Docker locale
• La runtime de conteneur utilisée est Docker
• La partie Network utilise Calico
• Ceph and RBD pour fournir du stockage persistent
• Armada afin d’orchestrer le déploiement des services via Helm
• Une authentification centralisée pour la registry et Kubernetes grâce à Keystone

Au-dessus de ce cluster Kubernetes il est possible de déployer un cloud OpenStack. La méthode de déploiement utilisée est proche de celle de Airshipit, c'est-à-dire OpenStack-Helm et Armada pour l’orchestration de Helm.

Le control plane d'OpenStack est déployé dans des pods Kubernetes. Les instances directement sur les nœuds. La version d'OpenStack utilisée est Stein et supporte les backends réseaux suivants :

- Open vSwitch conteneurisé
- Open vSwitch en bare metal avec DPDK
- SR-IOV

Le déploiement d'OpenStack se fait relativement simplement :

1. Application de labels sur les nœuds (controller, worker, storage).
2. Configuration du stockage local pour Nova.
3. Application de stx-openstack pour déployer OpenStack.
4. Finalisation de la configuration via l'API OpenStack.

StarlingX fournit une API REST ainsi qu'une CLI afin de personnaliser la configuration de certains éléments.

StarlingX : les différentes topologies

StarlingX peut scaler de 1 à 100 serveurs et supporte un fonctionnement hyper-convergé (1/2 serveurs) ou un mode frame level deployment (master/worker/storage).

Concernant le stockage :

• Ceph convergé dans le premier cas
• Ceph co-localisés sur les nœuds master en cas de petits déploiements
• Nœuds Ceph dédiés pour les déploiements plus larges

StarlingX : Déploiement

StarlingX est packagé sous forme d'ISO construites tous les jours et accessibles publiquement. Les images Docker sont publiées depuis une registry publique mais il est possible de spécifier une registry privée dans le cas de déploiements en mode hors ligne par exemple. Une fois l'ISO déployée via USB/PXE, la configuration est gérée par Ansible (ce qui permet un zero touch provisionning) et le déploiement de Kubernetes est réalisé via Kubeadm. La configuration peut ensuite être gérée via l'API de StarlingX ou la GUI.

StarlingX : Day 2

Via l'API ou la GUI il est possible de gérer le cycle de vie de StarlingX :

• Changement de configuration
• Maintenance des nœuds : verrouillage, détection d'erreurs, logs centralisés, statistiques
• Orchestration des mises à jour mineures et majeures
• Sauvegarde et restauration

StarlingX fournit donc une solution complète pour déployer des solutions de Edge hyper-convergées rapidement. La version 2.0 semble très prometteuse.

Un des futurs axes de travail est la gestion des périphériques IOT (Raspberry Pi, etc.). StarlingX permettra à des périphériques edge pouvant faire fonctionner Kubernetes, de joindre le cluster et de profiter des fonctionnalités telles que la registry Docker ou les PVC Ceph ainsi que d'un management centralisé.

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23215/starlingx-hardened-managed-kubernetes-platform-for-the-edge

Ironic project update

Nous en avons déjà parlé à l'issue de la première journée, Ironic est le service de provisionning bare metal d'OpenStack.

L'idée de ce service a démarré lors de la release Havana et le service lui-même a été fourni pour la première fois avec Icehouse. Tout d'abord comme projet en incubation (nous étions encore dans la période de la Big Tent), il devint un projet officiel lors de la release Kilo. Depuis tout ce temps, 728 contributeurs ont aidé à développer ce projet dont 123 rien que pour le dernier cycle de développement et la release Stein.

Ironic est un des projets mis en avant par la Fondation OpenStack sur ce Summit. Arrivant à maturité, il est de plus en plus utilisé pour des besoins de provisionning bare metal, que ce soit pour être utilisé par Kubernetes ou par des workloads de "big data". Cette maturité se traduit par les chiffres : en 1 an, le nombre de clouds OpenStack utilisant Ironic en production a augmenté de 4 points, atteignant 23% des clouds. La part des clouds OpenStack utilisant cette fois Ironic en test a diminué de 2 points, atteignant 9%. Ironic est de plus en plus mature et les POC deviennent progressivement des services en production ! Cet engouement pour Ironic est à comparer à celui pour Kubernetes (comme use case sur OpenStack), l'évolution de l'utilisation de ces deux outils est remarquablement similaire.

Cette stabilité se démontre par une autre métrique : le nombre de commits. Celui-ci diminue graduellement depuis 4 releases, signe que moins de bugs ont besoin d'être résolus tout en continuant à produire des nouvelles fonctions et améliorations. Le nombre de contributeurs diminue aussi légèrement mais cela est le cas dans la quasi totalité des projets OpenStack et n'est pas alarmant.

Les évolutions pour Stein sont les suivantes :

• support des templates de déploiement
• support json-rpc permettant de déployer Ironic sans bus de messages
• nettoyage automatique noeud par noeud
• support de iLO5 et de iBMC
• nouveaux champs dans l'API pour les opérateurs (description et protected)
• les déploiements directs peuvent utiliser un serveur HTTP local
• traitement parallèle de l'effacement des disques

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23714/ironic-project-update

Outils de déploiement OpenStack

Après notre article d'hier sur les outils de déploiement d'OpenStack nous rentrons un peu plus dans le détail : nous avons eu droit à un retour d'expérience plutôt complet et honnête. Tout d'abord, tous les aspects on été abordés, c'est-à-dire que déployer OpenStack c'est bien mais le maintenir sur le long terme c'est mieux.

Installation à la main en suivant docs.openstack.org

La première solution est naturellement de suivre la documentation officielle pour installer OpenStack, mais cette approche n'a comme intérêt que de permettre d'apprendre OpenStack. L'absence d'automatisation interdit cette méthode pour une installation sérieuse. Nous recommandons fortement de suivre cette documentation pour apprendre OpenStack si vous souhaitez être un administrateur de cloud privé.

Devstack

Ensuite, en montant dans la complexité, nous avons Devstack qui comme nous l'avons dit hier n'est pas une solution de déploiement, mais plutôt un moyen pour les développeurs de monter rapidement un OpenStack. Le but cherché peut être de tester les APIs.

Kolla et Kolla-ansible

Ensuite viennent Kolla et Kolla-ansible. Le premier sert à builder des containers qui permettrons de faire tourner un service d'OpenStack. Les images sont aussi disponibles sur Docker Hub. Le second sert à déployer et manager ces containers. Kolla et Kolla ansible ne gèrent pas les aspects bare-metal.

TripleO

TripleO utilise un OpenStack (undercloud) pour déployer un OpenStack (overcloud). Il utilise des manifests Puppet et des templates Heat. Il gère les serveurs depuis le metal grâce à Ironic. C'est une solution plutôt complexe mais pouvant disposer d'un support de Red Hat, principal moteur du projet. Il va évoluer vers l'utilisation de Kubernetes.

Kayobe

Il s'agit de Kolla on Bifrost (KoB), donc Kayobe ! En pratique, il s'agit de Kolla, Kolla-ansible, Bifrost et Ironic. Cette méthode permet de compléter Kolla avec la gestion des serveurs, la gestion des interfaces réseau, la configuration des hosts et une CLI. Il utilise Ansible-vault pour tous les fichiers de configuration. Bientôt il intègrera Monasca pour le monitoring et le logging. Mais ce projet n'a pas encore une communauté très importante.

Airship

Airship est un projet récent, la v1 vient de sortir. Il regroupe des outils qui permettent d'installer OpenStack dans Kubernetes et de gérer tout son cycle de vie. Il gère les serveurs depuis le bare metal. Il utilise des manifests YAML pour la configuration des services, ces manifests sont versionnés et validés avant installation. Kubernetes permet les rolling updates de la plateforme. Au niveau opération, les procédures d'installation, de scaling et de mise à jour sont identiques.

StarlingX

StarlingX, dont nous parlons en détails dans cet article, permet notamment de gérer une installation multi-régions.

OpenStack sur Kubernetes ou pas ?

La question est rapidement tombée après la conférence : faut-il utiliser Kubernetes pour orchestrer les conteneurs de services OpenStack ?

La réponse est nuancée : tout d'abord, utiliser Kubernetes permet d'avoir le rolling update, le scaling bien que les services OpenStack n'ont pas été développés pour cette utilisation. Mais il ajoute une surcouche qui apporte de la complexité notamment au niveau du réseau, il doit être géré par Kubernetes donc utilisation obligatoire de Calico.

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23334/deploying-openstack-what-options-do-we-have

Kata Containers : building a container specific Virtual Machine Monitor (VMM)

Samuel Ortiz (Intel), Andreea Florescu (Amazon)

Faut-il encore présenter Kata Containers ? Disons que oui : il s'agit d'une nouvelle technologie d'implémentation, (le terme "implantation" serait d'ailleurs plus juste), de la notion de conteneurs visant à concilier la légèreté des processus Linux et la sécurité des machines virtuelles, ceci en fournissant un runtime conforme aux spécifications de l'OCI (Open Container Initiative). Rien que ça !

L'idée est donc de faire tourner la charge applicative conteneurisée (workload) au sein de machines virtuelles et donc d'utiliser un VMM pour apporter de la sécurité "en profondeur" aux conteneurs, qui par nature apportent un premier niveau d'isolation grâce à des fonctionnalités du kernel Linux telles que les "namespaces" ou les "cgroups".

Au passage, il est important de souligner que la notion de Machine Virtuelle est en cours d'intégration dans les spécifications OCI.

Seulement voilà, pour pouvoir se comparer aux processus Linux en terme de légèreté, il faut pouvoir allumer une machine virtuelle en quelques centaines de millisecondes au plus, cet objectif excluant l'utilisation de QEMU, ceci pour ne citer qu'un seul des éléments du cahier des charges techniques ultra exigeant de Kata Containers.

S'en est donc suivi le développement de NEMU, né de la base de code QEMU, un gestionnaire de machines virtuelles plus léger, moins versatile et au scope fonctionnel plus réduit. Mais NEMU n'a pas permis de couvrir l'intégralité des exigences. Il a donc été remplacé par Firecraker, un VMM de nouvelle génération, également basé sur KVM, tout comme QEMU et NEMU.

Firecracker possède de grandes qualités : taillé pour les applications conteneurisées, base de code réduite, cible fonctionnelle étroite, pour n'en citer que trois.

Mais, butant à nouveau sur des limites inhérentes à Firecracker, la core team Kata Containers s'est rendu à une évidence : Kata Containers a besoin d'un VMM parfaitement adapté à ses besoins, sur mesure en quelque sortes !

Mais où donc trouver cette technologie ? Elle n'existe pas mais un projet ambitieux la préfigure, c'est rust-vmm ! Curieux d'en savoir plus ? Lisez donc le papier de Andreea Florescu sur le sujet et allez vous promener parmi les premières lignes de code dans son repository sur github.com.

Au fait rust est un langage de programmation compilé (ils sont très en vogue actuellement dans le monde des infrastructures...). Conçu et développé par Mozilla Research, il se veut être un langage sécurisé (?) et supportant à la fois la programmation à approche fonctionnelle et procédurale.

Concernant rust-vmm, ses géniteurs (Google, Intel, Red Hat et Amazon) nous promettent :

• une API propre, claire et concise
• un développement accéléré des VMMs spécifiques
• un haut niveau de sécurité et des tests des VMMs facilités, donc potentiellement plus poussés

Bien entendu, le modèle de développement du projet est de type "Open" et, sur le principe, tout le monde peut contribuer.

Kata Containers ne cesse donc de nous surprendre par ses ambitions, sa force d'innovation et sa capacité à surmonter les obstacles qui se présentent sur sa route !

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23378/tailor-made-security-building-a-container-specific-hypervisor

Merci de nous avoir suivi pour ces 3 jours, nous vous donnons rendez vous dans 3 semaines pour la KubeCon/CNCF Con à Barcelone !