C'est déjà la fin ! Ce jeudi marque la dernière journée de l'OpenStack Summit de Berlin, dernier événement du nom pour rappel, puisque dès 2019 ces événements bi-annuels organisés par la Fondation OpenStack seront les Open Infrastructure Summits.

Pas de keynotes aujourd'hui, comme à l'habitude.

Bonne lecture, et RDV au prochain Summit !

Breakout sessions

Multicloud CI/CD with OpenStack and Kubernetes

Mettre en place une architecture multicloud est aujourd'hui possible, notamment grâce aux outils de CI/CD. L'intérêt peut être multiple :

• Permet d'améliorer la résilience, en évitant les éventuelles indisponibilités localisées sur un cloud provider
• Permet de se défaire des éventuelles dépendances à des fonctionnalités spécifiques d'un cloud provider (éviter le vendor lock-in)
• Ou permet au contraire d'aller chercher des fonctionnalités spécifiques à chaque cloud provider
• Pour des questions de coût
• Pour se rapprocher des clients en tirant profit des multiples zones de disponibilité, ce qui pourrait permettre de réduire la latence notamment

OpenStack est particulièrement adapté pour ce genre d'architecture, il existe aujourd'hui sur le marché 60 zones de disponibilité de clouds publics OpenStack.

Le multicloud est un contexte alambiqué où il est essentiel d'utiliser des outils de CI/CD pour des questions de cohérence. Attention aux erreurs typographiques : il est rapide de faire des fautes lorsqu'on écrit un pipeline, et dans le cadre de l'infrastructure les erreurs peuvent être coûteuses et pénibles à corriger.

Avant de se lancer, il est préférable de travailler sur les applications elle-mêmes en s'assurant qu'elles respectent bien les principes 12 factor et qu'elles restent fonctionnelles dans un mode de déploiement distribué.

Le multicloud devient particulièrement intéressant pour les applications conteneurisées où l'utilisation d'un orchestrateur comme Kubernetes permet de mettre en place une couche unifiée, portable, simple et homogène quel que soit le cloud provider, dédiée à l'hébergement des applications. Pour Kubernetes, attention à bien monter un cluster par zone de disponibilité et non pas un cluster étendu pour des questions de résilience et de latence.

Quelques services tiers qu'il ne faut pas oublier lorsqu'on cherche à héberger une application en multicloud :

• CDN pour les ressources statiques
• DNS géolocalisé comme Route 53 ou Dyn pour faire du geo-routing
• Solution de fédération d'identité comme OpenID ou des Webhooks, de préférence compatible avec Kubernetes (cf. --iodc-* sur l'API Kube comme documenté ici et Kuberos).

Pour déployer l'infrastructure as code de nombreux outils existent : Heat, Ansible, Terraform, etc.

Pour déployer Kubernetes, on peut utiliser :

• Magnum (OpenStack seulement)
• Kops (OpenStack non supporté, seulement AWS)
• Rancher (OpenStack non supporté)
• Kubespray (Gère bien OpenStack, AWS, Azure, VMWare, le baremetal, basé sur des playbooks Ansible et compatible Terraform)
• Autres

Il est possible de faire de la fédération de cluster Kubernetes, par exemple avec Kubefed. La v1 de Kubefed n'est plus développée, une v2 est en cours, attention toutefois : Kubefed demande l'utilisation d'une version de Kubernetes supérieure à la 1.11. On espère voir arriver une version Beta d'ici la fin de l'année.

Airship project update

Airship est un outil permettant de manager de l'infrastructure de façon déclarative sous forme de fichier YAML. Il fait partie de ce que l'on appelle maintenant les "pilot projects" de la Fondation OpenStack.

A la base, Airship est une collection d'outils conçus pour faciliter le déploiement et le gestion de cycle de vie de OpenStack Helm qui est une solution de déploiement d'OpenStack au dessus de Kubernetes se basant sur des Helm Charts.

Pour le moment, la v1.0 release candidate est concentrée sur la résilience, la sécurité et le déploiement multi-site. La release 1.0 est prévue pour 2019 et met l'accent sur :

• L'assistance à la génération des YAML de configuration
• L’intégration avec Ironic, pour le moment Airship se base sur MAAS, mais celui ci ne répond pas à tous les besoins
• La découverte automatique du matériel
• Support de multiples systèmes d'exploitation : pour le moment Ubuntu 16.04 est supporté, le support de SUSE est en cours

Kata Containers - Project update - Samuel Ortiz (Intel)

Avec Zuul, Airship et StarlingX, Kata Containers (https://katacontainers.io/) est un des 4 projets non directement liés à OpenStack incubés par la fondation. A ce titre, il co-inaugure la nouvelle orientation "Open Infrastructure" de la fondation. Lancé en décembre 2017, le projet kata Containers soufflera sa première bougie le mois prochain (décembre 2018).

Bien que considéré comme quasiment "production ready", Kata Containers doit encore s'améliorer pour tenir ses promesses initiales : "The speed of containers, the security of VMs", rien de moins !

Samuel ORTIZ (Intel), membre du comité technique du projet, nous détaille sans langue de bois les axes d'améliorations stratégiques et nous indique au passage la sortie de la release 1.4.0 d'ici la fin de l'année 2018.

Axe Sécurité ("...security of VMs")

• filtrage des appels système émis depuis le conteneur : mise en oeuvre de Seccomp. Dans la v1.4.0
• réduction de la surface d'attaque : support de l'hyperviseur "lightweight" NEMU. Dans la v1.4.0
• gestion matérielle des nombres et des suites de caractères aléatoires

Axe Performances ("The speed of containers...")

• VM template : aujourd'hui, le prix à payer pour migrer de Docker vers Kata Containers en termes d'overhead mémoire sur le host et de temps de démarrage d'un conteneur est top élevé. Il faut donc réduire ces deux grandeurs. La réponse de l'équipe projet est la VM Factory qui introduit la notion de "VM template" visant à accélérer l'allumage de la VM qui héberge le conteneur. Toutefois, même avec la VM Factory, cette phase d'allumage est encore trop longue : environ 2 fois plus longue que le lancement par Docker d'un conteneur de type "processus" (1600ms vs 900). L'équipe de développement ne s'en satisfait donc pas et travaille encore à son amélioration.
• TC mirroring : nouvelle technique de network bridging plus performante. Disponible dans la v1.4.0
• NEMU : hyperviseur léger, issu d'une partie du code de QEMU mais débarrassé des fonctionnalités de support legacy des périphériques (50 contre 200 devices différents). Les VMs hosts s'allument beaucoup plus vite qu'avec QEMU.
• virtio-fs : file system virtualisé. Rapide et conforme aux spécifications Posix.

Axes complexité, mise au point, opérabilité

• VSOCK : le runtime OCI n'a plus besoin de proxy. Déjà disponible dans la v1.2.0
• traçabilité distribuée
• live upgrade. La roadmap positionne cette fonctionnalité en v1.5.0
• container-shim v2: un seul shim par pod Kubernetes, au lieu de un shim par conteneur auparavant

Axe multi-architecture

• pour répondre au souhait du client en matière de vendor lock-in
• ARM 64 et PPC 64, en plus de x86

Deux mots concernant la communauté et la gouvernance Kata Containers :

• contributions : dans les débuts du projet 99% des commits étaient produits par des personnes travaillant pour Intel et Hyper. Depuis, des personnes de Huawei, ARM, Red Hat, IBM, Nvidia, Suse et Oracle les ont rejoints.
• comité technique : les membres sont élus par les contributeurs. Aujourd'hui (novembre 2018), le comité technique est composé de Samuel Ortiz, Xu Wang, Wei Zhang, Eric Ernst et Jon Olson.

Samuel Ortiz précise qu'il n'y a pas de ticket d'entrée financier pour entrer sur le projet mais on ne vote que si l'on contribue. Actuellement, 50 personnes remplissent cette condition et peuvent donc voter pour élire les membres du comité technique.

S. Ortiz nous dit aussi que la phase d'évangélisation Kata Containers a été relativement difficile, les experts en conteneurs étant incrédules. Ils ne voulaient pas admettre l'idée qu'un conteneur pouvait être autre chose qu'un process qui s'exécute sur un serveur. Cette phase a pris quasiment deux ans ! Les choses ont changé avec les premières implémentations de référence avec Kubernetes. Et le fait que Kubernetes soit "runtime agnostique" a grandement facilité l'acceptation de Kata Container par l'éco-système.

En fin de séance, une personne dans la salle pose la question suivante : " La live migration est-elle gérée ?". Réponse de Samuel Ortiz : "Non, et elle ne le sera pas, sauf si Kubernetes décide un jour de la supporter. Mais, a priori, cette notion n'a pas de sens dans le monde des conteneurs !"

Enfin, pour boucler la séance, Samuel Ortiz rappelle qu'il est possible d'utiliser un kernel guest différent de celui par défaut et aussi qu'il n'est pas nécessaire de reconstruire les images de conteneurs existantes pour les faire tourner avec Kata Containers et que ceci constitue une caractéristique remarquable !

Chez alter way Cloud Consulting, nous savions que Kata Containers était une technologie à suivre de près et Samuel Ortiz nous le confirme aujourd'hui avec ce project update !

Forum

Comparaison des outils de déploiement

Objectif de la session, définir les critères importants différenciant les différentes méthodes et outils de déploiement d'OpenStack, afin de pouvoir les exposer aux opérateurs. On peut citer notamment les éléments suivant :

• Composants OpenStack couverts
• Support des mises à jour majeures
• Distributions Linux supportées
• Gestion de la couche bare-metal et des systèmes de logs/monitoring/etc.
• Gestion du cycle de vie, au-delà du simple déploiement
• Utilisation directe des sources ou de paquets

Ainsi, ces informations pourraient à l'avenir être intégrées sur le site web OpenStack et donc faciliter les comparaisons entre outils, notamment pour les nouveaux opérateurs de cloud OpenStack.