OpenStack Summit Vancouver 2018

Pause Cloud & DevOps – édition spéciale OpenStack Summit Vancouver 2018

Jour 2

Vous n’avez pas pu venir à Vancouver pour assister à l’OpenStack Summit et vous souhaitez savoir ce qui est annoncé/présenté d’important ? Les consultants d’Objectif Libre sur place vous racontent.

Au menu : du cloud, de l’Open Source, du stockage, du réseau, de l’Open Infrastructure… tout ce qui fait OpenStack.

  • Kata containers : the Way to run virtualized containers
  • Integrating Keystone with large-scale Centralized Authentication
  • Pre-emptible instances
  • Open CD for OpenInfrastructure – Hybrid and Multi-Cloud Deployments with Spinnaker
  • Project Updates

Bonne lecture !

Pour lire le retour du jour 1 : https://olib.re/20180522-pause-openstack-summit-1

Kata Containers: the way to run virtualized containers

Kata Containers, solution alternative de container runtime « sécurisée », fête aujourd’hui la sortie de sa v1.0.0.
Pour l’occasion, Sebastien Bœuf nous offre une conférence très technique et intéressante, qu’on aurait voulu voir durer plus longtemps.

Pourquoi Kata Containers ?

Reprenons la définition d’un conteneur :

  • Isolation (namespaces) : processus, réseau, etc…
  • Limitation (cgroups) : mémoire, temps CPU, etc…
  • Léger : partage du kernel hôte par l’ensemble des conteneurs

Cependant, « Software is not enough » : la mutualisation du kernel amène des problématiques de sécurité.

Kata Containers se positionne comme la solution à cette problématique de sécurité : Kata Containers gère des « conteneurs virtualisés » (= des conteneurs dans une VM très minimaliste).

Fonctionnement

Dans l’éco-système actuel, Kata containers se place en tant que remplaçant du runtime commun (runC, suivant les spécifications OCI).

Kata containers se décompose en plusieurs projets :

  • Runtime : gestion des conteneurs virtualisés
  • Shim : représentation du conteneur virtualisé sur la machine hôte
  • Agent : gestion des conteneurs au sein de la VM minimaliste
  • Proxy : gestion de la communication entre Runtime/Shim↔Agent.

Fonctionnalités

Une liste non-exhaustive de fonctionnalités prometteuses :

  • Kata-API : compatibilité CRI (frakti) et OCI runtime (kata-runtime)
  • VM « templatisée » : lancement d’un template de VM pré-défini de gabarit fixe, augmentation à chaud (Hot-plug) de ressources supplémentaires (vCPU, RAM, PCI)
  • Drivers virtio : virtio-scsi et virtio-net pour la virtualisation des périphériques de la VM
  • Gestion du réseau : le challenge ? Assurer le portage de l’isolation réseau dans la VM jusqu’à la machine hôte. Deux implémentations sont possibles : MACVTAP (apparemment privilégié) et TC mirroring (Traffic Control, gestion L3).

Un dernier point très intéressant du projet : sa composante « multi-OS ». En effet, Kata Containers ne se limite pas à un seul Kernel.
Chaque conteneur s’exécute dans sa propre machine virtuelle, il profite donc de la version et des fonctionnalités liées à ce Kernel.

Conclusion

Kata Containers se définit comment étant :

  • Sécurisé
  • Rapide
  • Facile d’utilisation

Cet aperçu nous semble très prometteur et mérite un suivi et des investigations complémentaires pour bien saisir les tenants et aboutissants de l’architecture de Kata Containers.

 

Integrating Keystone with large-scale Centralized Authentication

Cette session est un retour d’expérience autour de Keystone par deux ingénieurs de Red Hat, Ken Holden & Chris Janiszewski.

Prélude

Les intervenants prennent soin de leur public en commençant par rappeler les principes fondamentaux de Keystone :

  • Authentification et autorisation : « Who you are » Vs « What you can do »
  • Provisioning des utilisateurs : SQL par défaut, mais d’autres modes existent (LDAP et fédération entre autres)
  • Distribution de token selon différentes méthodes (UUID et Fernet)

Le rôle de Keystone ?

  1. Authentifier l’utilisateur
  2. Définir un token et un scope (projet, domaine, …)
  3. Autorisation ? Et bien non, ceci est à la charge de chaque composant

 

Précisions

LDAP
Couramment utilisé pour provisionner facilement les utilisateurs d’un AD/openLDAP existant.

Fédération
Protocoles comme OpenID et SAML : après sondage rapide à main levée, à peine 10% des présents dans la salle utilisent cette fonctionnalité.

Token

Plusieurs types :

  • UUID : à oublier !
  • Fernet : type à privilégier – aujourd’hui, par défaut.
  • PKI or not PKI ? Ce n’est plus maintenu, donc à oublier !
  • JWT ? à venir

Les speakers précisent que les développements des types de token sont en constante évolution.

API
v2, v3 ? Attention, la v2 est aujourd’hui totalement dépréciée dans Queens. Cependant, de nombreuses personnes/constructeurs utilisent encore cette version d’API.

 

Quid du cas particulier du « Large-scale » ?

Du coté de la configuration

À faire :

  • Token : passer au token de Fernet ! Le gain en termes de performance et d’espace utilisé en BDD est appréciable.
  • LDAP : filtrer les utilisateurs via des groupes clairement identifiés OpenStack (ex: attribut memberOf facilite la sélection des utilisateurs). « Do you really need that your 100K users have an access to the openstack ? »
  • LDAP : tester les filtres avec un ldapsearch en amont, la syntaxe est identique.

À ne pas faire :

  • Mode débug en production : cela impacte clairement les performances de Keystone
  • Utiliser des disques non-performants pour les contrôleurs et le SGBD
  • Synchroniser tout votre LDAP avant d’appliquer les filtres : Keystone ne fera pas le ménage des utilisateurs qui ne seront plus sélectionnés par le filtre
  • API/Dashboard et requêtes au LDAP non sécurisées

Débug

Quelques astuces pour débuguer aisément la mise en pratique du LDAP avec Keystone :

  • Configurer Keystone en Debug + verbose
  • À un niveau avancé de débug, Keystone logue les requêtes LDAP réellement exécutées
  • Un bon vieux tail -f /var/log/keystone/keystone.log | grep LDAP\ search

ATTENTION : retirer le mode débug après l’ajustement des filtres.

Tuning

  • Activer le pooling. La configuration ci-dessous est par défaut dans Queens :
[ldap]
use_auth_pool = true
auth_pool_size = 100
auth_pool_connection_lifetime = 60
  • Pagination : par défaut, la pagination est désactivée (0).
page_size = 100
  • Caching : activer le cache ! Le gain de performance est notable

La présentation se termine par un comparatif des performances en fonction de l’activation ou non des différentes options de tuning. Et c’est très clair, le cache réduit drastiquement le temps de réponse de la requête d’un token.

Conclusion

Globalement, le retour d’expérience de cette conférence sur un nombre important d’utilisateurs (LDAP) montre que le tuning de keystone doit être réfléchi avant tout déploiement en production.

Les speakers terminent en confrontant Keystone au monde réel où les freins à la performance et à l’exploitation sont nombreux :

  • Firewall face aux contrôleurs
  • Proxys
  • Politiques d’expiration de mot de passe, inexistantes dans Keystone
  • Pas de rechargement à chaud de la configuration Keystone (restart required !)
  • Rotation des token de Fernet

 

Pre-emptible instances

Un session-fishbowl (discussion ouverte autour d’un sujet) sur les instances pré-emptibles: ce sont des instances à priorité faible, et qui peuvent être supprimées si les ressources viennent à manquer. Ce type d’instance existe déjà chez AWS (EC2 spot instances) et chez Google (preemptible VMs).

L’idée d’intégrer ces instances à OpenStack a été lancée par le CERN pour optimiser l’utilisation des ressources, notamment concernant les points suivants:

  • Certains serveurs en fin de vie pourraient être utilisés pour des instances pré-emptibles uniquement : les performances ne sont pas critiques pour celles-ci
  • Certains hyperviseurs quasi-pleins ne sont jamais remplis totalement (ce problème est également connu sous le nom de « Tetris problem »)

Un prototype de service « Reaper » a été proposé par le CERN avec pour rôle d’orchestrer les instances pré-emptibles. Il choisit celles qui doivent être stoppées pour libérer des ressources, il gère des quotas, etc.

Ce projet en est encore à ses balbutiements, des questions très diverses ont été soulevées lors de ce fishbowl, parmi lesquelles :

  • Devrait-il y avoir des projets « pre-emptible only » ? L’avis général était plutôt négatif, car cela ajouterait une couche de complexité et n’est pas vraiment transparent du point de vue de l’utilisateur final.
  • Comment les instances pré-emptibles doivent-elles être arrêtées ? Doivent-elles recevoir un signal ACPI ? Si oui, ce signal existe-il sur les architectures ARM ou POWER ?
  • Qui serait en charge de stopper les instances ? Un agent sur les hyperviseurs ? Ce point n’a pas fait l’unanimité, un agent poserait problème si la fonctionnalité venait à être intégrée à Ironic.

Beaucoup de questions restent ouvertes, cette fonctionnalité a encore du potentiel de maturation.

 

Open CD for OpenInfrastructure – Hybrid and Multi-Cloud Deployments with Spinnaker

Spinnaker est une plate-forme de « continous delivery » multi-cloud Open Source développée par Netflix. La solution est issue d’un projet se nommant Asgard, qui a vu le jour en 2012.
Initialement, Asguard permettait le provisioning d’instances EC2 chez AWS. Rapidement, l’outil présentait des limites dues au rythme effréné des nouvelles release de l’équipe R&D de Netflix.
En 2014, le projet Asguard devient spinnaker et vient combler les manques et les limites de l’outil :
  • Pipeline
  • Stratégie de déploiement 
  • Agnosticité des clouds providers (OpenStack, GCP,AWS, Azure, CloudFoundry)
Aujourd’hui, une instance de Spinnakker permet à Netflix :
  • Le déploiement de plus de 2500 applications
  • Plus de 4000 MEPs par jour
  • La mise en place de plus de 9500 pipelines
Elle offre également en standard les principales stratégies de déploiement :
  • Blue/Green
  • Canary release
  • Rolling update
En conclusion, Spinnaker est devenu un outil incontournable dans les stratégies de CI/CD complexes et multi-cloud. Il standardise les processus de livraison en continu et permet aux équipes produit de réaliser leur propre workflow de déploiement, tout en étant responsables de leur pipeline de déploiement. Spinnaker offre un environnement contrôlé et adaptable avec des rollbacks simplifiés lorsqu’une MEP a échoué. 

Project Updates

La majorité des projets OpenStack proposent une présentation de leur actualité : ce sont les sessions « project update ».

Durant cette journée Kolla et CloudKitty ont retenu notre attention.

Kolla – Project Update

Par Jeffrey Zhang (99Cloud), Surya Prakash Singh (NEC)

La présentation commence par une slide présentant l’ensemble des projets s’appuyant sur les images Kolla et où on peut voir kolla-kubernetes barré – ce qui nous confirme que le projet ne sera plus maintenu et va donc laisser la place à Openstack-Helm.
Ensuite, les speakers ont rappelés quels étaient les objectifs du projet : fournir des conteneurs prêt à l’emploi et « prod-ready » (Kolla) tout en proposant l’ensemble de l’outillage nécessaire au déploiement d’un cloud OpenStack (Kolla-ansible).
Il faut rappeler que le projet a vu le jour durant le cycle Kilo, et a intégré la Big Tent durant le cycle Liberty ; Queens est donc la 6ème release du projet.

Kolla (images)

Les nouveauté de Queens pour les images kolla:
  • La taille des images a été réduite
  • Push des images automatisé vers le Docker hub
  • 16 nouvelles images (210 images au total)
Ce qui est prévu pour Rocky :
  • Refactoring du build.py (code responsable du build de l’ensemble des images Kolla)
  • Intégration du bluestore pour Ceph

Kolla-ansible

Les nouveauté de Queens pour kolla-ansible :
  • Upgrade de Ceph vers Luminous
  • Migration des jobs vers Zuul v3
  • Ajout de tests pour un déploiement avec plusieurs nœuds
  • Documentation
  • Mise à jour avec un downtime limité (pour le moment, seul Keystone est validé/géré dans ce contexte)
  • Possibilité d’externaliser la base de données
  • Support d’un « devmode »
A venir pour Rocky :
  • Intégration de la stack prometheus, en plus de Kibana / Elasticsearch et InfluxDB Grafana
  • Intégration du bluestore pour Ceph
  •  Plus de services qui pourront se mettre à jour en mode « rolling upgrade » (en particulier nova et neutron)
  •  Des healthcheck au niveau des services
Pour terminer ce projet update, il est important de souligner qu’aucune entreprise n’a plus de 28% de contribution sur le projet, ce qui nous montre que celui-ci est dans sa majorité porté par la communauté qui compte notamment 120 reviewers qui ont effectué 3900 reviews pour la release Queens.

Cloudkitty – Project Update

Par Luka Peschke (Core) et Christophe Sauthier (PTL) d’Objectif Libre

CloudKitty est le projet de rating (valorisation) à la demande d’OpenStack. Le projet existe depuis 2015 et est développé principalement par Objectif Libre.

Le workflow de travail habituel est le suivant:

  • Récupération des métriques OpenStack
  • Définition/stockage/application d’une politique tarifaire
  • Stockage des données valorisées
  • Export
  • Intégration dans Horizon

La version de Queens a marqué le début de changements importants dans l’architecture et le code de CloudKitty, en particulier:

  • La création d’un nouveau stockage hybride : stockage des états en SQL et des données valorisées dans une Time-series-database
  • La création d’un fetcher de sources non-OpenStack pour être capable de traiter des données en dehors de ce scope initial
  • Un nouveau collecteur pour Monasca (via Ceilosca)
  • La gestion des métriques que l’on veut récupérer dans un fichier de configuration dédié (metrics.yml) au lieu d’être hardcodé dans le code
  • La dépréciation du collecteur ceilometer (l’API ayant été dépréciée) et la dépréciation de tous les stockages autres que Hybrid et SQLAlchemy

Ce travail de fond continue sur Rocky avec une volonté de se concentrer sur l’amélioration de l’existant:

  • Un gros travail pour améliorer la scalabilité avec une l’écriture de l’API V2 et du storage V2
  • Amélioration des interfaces : le travail portera sur le client (avec l’ajout de la pagination par exemple) et amènera aussi de légères modifications de l’IHM Horizon
  • Convergence vers le mode standalone avec la création d’un collecteur Prometheus – à suivre prochainement sur notre blog

Ces améliorations continueront après Rocky avec un travail sur l’UI Horizon, et une gestion plus industrielle des règles de politique tarifaire (export/versionning…).

Concernant la collaboration cross-project, citons :

  • la collaboration avec Ceilometer et Monasca
  • l’intégration avec tous les projets de déploiement d’OpenStack (Kolla, Kolla-ansible, Puppet-openstack, OpenStack-Ansible,…)

Reste enfin la très forte volonté d’avoir de nouveaux contributeurs et des retours de use-cases à implémenter ! Pour cela : #cloudkitty sur IRC Freenode.