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 ?
- Authentifier l’utilisateur
- Définir un token et un scope (projet, domaine, …)
- 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).
- 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.
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.
Par
Kolla (images)
Kolla-ansible
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.
