Pause Cloud & DevOps

Pause Cloud & DevOps – édition spéciale OpenStack Summit Denver 2019

Jour 1

Vous n’êtes pas à Denver pour assister à l’OpenStack Summit, à votre grand regret ?

Pour cette édition, Objectif Libre s’est déplacé en force pour vous permettre de suivre le Summit comme si vous y étiez !

Au menu : de l’Open Infrastructure.

  • Keynotes
  • Next Steps for Standalone Ironic
  • Manila project Update
  • Lessons learned running OpenInfrastructure on baremetal kubernetes clusters in production
  • Rook: A new and easy way to run your Ceph storage on Kubernetes
  • Multicloud CI/CD with OpenStack and kubernetes

Bonne lecture !

Keynote

Les habitudes ne changent pas ! Jonathan Brice introduit le tout nouveau format de summit au nom d’OpenInfrastructure Summit pour l’édition 2019 à Denver.
Nous débutons par une rétrospective de ces dernières années.
Le travail collaboratif pour résoudre des problèmes est particulièrement mis en avant. Il annonce que durant ces trois jours de Summit, beaucoup plus de sessions de travail collaboratif sont proposées que par le passé.
Selon lui la technologie doit aider à changer des vies et contribuer à faire évoluer le monde dans le bon sens. Et cela doit passer par la collaboration entre les individus.
Après une rétrospective sur son parcours depuis l’enfance, Jonathan conclut que plutôt que de développer ses propres outils de son côté, il vaut mieux se tourner vers l’open-source. C’est une philosophie de l’innovation à adopter.
Se pose alors le problème de la valeur ajoutée. Comment monétiser ?
Pour Jonathan le cloud public est une solution, mais pas l’unique solution : on doit également considérer tout l’écosystème : réseau (SDN), stockage (SDS), etc… 

 

Pour conclure, il revient sur quelques principes de la fondation : éducation, soutien des utilisateurs notamment.

Quelques chiffres :
  • Le marché représente plus de 6 milliards de Dollars, dans 180 pays.
  • La fondation comprend plus de 100.000 membres.

Selon lui, les défis de demain seront de mettre à contribution ces technologies open sources pour le développement des nouvelles technologies/normes de demain, comme par exemple la 5G.

Dans la continuité de Jonathan, Amy Leeland vient nous raconter son parcours et l’importance de la gouvernance.
Amy travaille depuis 2006 sur des projets de grande envergure comme Linux, meego, android, OpenStack, StarlingX et Kata Container entre autres.
Son rôle est la gestion de projet, améliorer les process, trouver des moyens pour améliorer le développement des projets.
Elle nous indique que dans la manière de gérer les projets il existe 4 fondamentaux pour avoir une bonne gouvernance.
  • Open source
  • Open design
  • Open development
  • Open community
Que ce soit des personnes, un projet ou une entreprise il y a un point qui les relie, la gouvernance.
Sans cette vision, cette manière de travailler, il ne peut y avoir d’évolution et de bonne communication.
Le mot de fin de sa présentation est essentiel : il faut travailler ensemble sans limite.
La keynote suit son cours avec un retour d’expérience de James Penick sur la transition de Verizon vers l’Opensource (OpenInfrastructre)
Leur infrastructure se compose de plus d’une centaine de milliers de nœuds, et pas moins de 4 millions de cores. De nombreux outils opensources sont aujourd’hui utilisés pour gérer cette infrastructure : déploiement, monitoring, applications.
James nous explique que le 1er challenge pour une transition vers l’opensource chez Verizon est la gestion du « bear »-metal. Il nous rappelle que les nœuds physiques sont la base de toutes les VM et conteneurs déployés aujourd’hui.
Vient ensuite l’instant démo tant attendu !
Démonstration intéressante sur l’utilisation conjointe d’OpenStack & Kubernetes : Julia Kreger (PTL d’Ironic) & Chris Hoge nous présentent le déploiement de 3 nœuds baremetal dans OpenStack à travers de Kubernetes.
L’operator MetalKube (https://github.com/metal3-io/baremetal-operator) est utilisé pour assurer la création des nœuds physiques dans OpenStack à travers Kubernetes. À travers une simple description des nœuds dans un manifest, nous pouvons voir les nœuds up and running en quelques minutes.
Démonstration convaincante, appuyée d’une présentation de l’importance du projet Ironic dans OpenStack. Les dernières releases d’Ironic (Rocky & Stein) ont connu de grandes évolutions, cette première démonstration de la keynote confirme la forte tendance à l’utilisation et contribution au projet Ironic.
S’ensuit la présentation de Kata containers qui fait partie des projets qui sont passés du stade ‘pilote’ au stade ‘confirmé’ par la fondation OpenStack.
Le but de Kata : faire évoluer la manière de gérer des containers en proposant des améliorations en terme d’isolation, de sécurité. L’accent a également été mis sur les performances, l’opérabilité, la simplicité, un meilleur support des mises à jour et le support d’un plus grand nombre d’architectures (arm64, ppc64 par ex.)
Des idées ont émergé pour la prise en charge d’autres hyperviseurs que QEMU : NEMU (un hyperviseur open source pensé pour faire tourner des workloads cloud sur des architectures CPU 64-bit Intel and ARM.) et Firecracker, une technologie open source de virtualisation utilisée pour créer et gérer des containers et des services associés en mode multi-tenants et de manière sécurisée.
Les projets, bien que très jeunes, semblent bien évoluer ensemble. 
Melissa Evers-Hood, director system chez Intel, nous présente aujourd’hui un 5ème point sur les fondamentaux que Amy Leeland à indiqué et  qu’elle trouve important: L’ouverture d’esprit.
L’ouverture d’edsprit est importante dans notre métier car c’est ce qui permet de créer quelque chose tous ensemble.
Pour Melissa, l’ouverture d’esprit se présente sous forme de trois points:
  • Projets: Événement qui permet de regrouper des ressources
  • Usage: Avoir une vision d’hier, aujourd’hui et de demain
  • Communauté: l’engouement des personnes pour les nouvelles technologies
Pour le point projet, Melissa félicite les projets Kata Container et StarlingX car ils ont su écouter les remarques et mettre en œuvre les changements ce qui leur a permis leurs réussites.
Également, elle indique que l’Open SDI (Software Defined Infrastructure) est un exemple pour le point Usage. Cela a permis de regrouper des personnes qui ont connu les infrastructures d’hier et qui permettent aujourd’hui de voir plus loin et d’aller au delà des limites qu’ils ont rencontrées.
Concernant le point de la communauté, elle démontre que les des Hackatons sont un bon exemple. Un hackaton est un rassemblement qui permet en un weekend de travailler avec un grand nombre de personnes sur un sujet précis et de produire de nouvelle fonctionnalités ou de nouvelles améliorations.
Pour résumer ce qu’est l’ouverture d’esprit dans notre métier c’est cette conférence qui permet de rassembler un grand nombre de personnes qui sont de régions différentes , de niveaux différents et de grades différents.
Elle incite à ce qu’on partage nos histoires, nos collaborations avec le hashtag #5thopen sur Twitter
La keynote se termine comme habituellement par les Superuser et Contributor awards.
Les nominés au Superuser étaient Cloudsuite, Vexxhost, Whitestack & NSCC. La récompense est attribuée à Vexxhost, bravo à eux.
La gagnante des contributors awards : Lauren Sell !

 


Next Steps for Standalone Ironic

Cette session « Fishbowl » (discussion ouverte entre les utilisateurs et les mainteneurs d’un projet) portait sur les évolutions à venir pour le mode « Standalone » d’Ironic et proposait un bref retour sur les évolutions de la version Stein: JSON-RPC  est désormais utilisé au lieu de RabbitMQ pour ironic-inspector, et une « Allocation API » (sorte de mini-scheduler permettant de déterminer quelle node sera provisionée par ironic) a été ajoutée.
Celle-ci utilise soit l’API placement dans le cas ou ironic est deployé au sein d’OpenStack, soit metalsmith pour le deploiment stand-alone: https://docs.openstack.org/metalsmith/latest/ .
Bien qu’il soit actuellement possible de déployer Ironic hors d’OpenStack, les fonctionnalités sont limitées, et le projet n’est pas encore complètement autonome. La fonctionnalité la plus demandée par les utilisateurs est le support d’une méthode d’authentification différente de Keystone, indispensable pour des déploiements stand-alone en production. Un autre élément important est le support d’un SDN (Software Defined Networking) autre que Neutron (une bibliothèque python visant à résoudre ce problème est en cours de développement). Enfin, une documentation concernant le « fast-track deployment » (le fait d’accélérer les déploiements en revoyant les cycles de redémarrage) serait également très appréciée par la communauté.
Parmi les features moins demandées, mais néanmoins intéressantes, on peut noter (la liste est non-exhaustive):
  • De la documentation concernant les mises à jour de firmware.
Pour notre part, nous aimerions voir apparaître le support d’un autre catalogue d’images: Glance est le seul catalogue supporté à l’heure actuelle. Si glance
n’est pas disponible, l’URL de l’image à utiliser doit être spécifiée lors du provisionement d’une machine.
Note de la fin: la salle de cette session était pleine ce qui montre un réel intérêt pour le projet Ironic, de plus en plus stable et répandu.

Manila project Update

Pour rappel Manila est un service OpenStack qui permet de provisionner et de gérer des systèmes de fichiers. On peut en parler comme étant le « Cinder » des systèmes de fichiers partagés.
C’est la 9ème fois que Manila sort une nouvelle version pour coller au développement d’OpenStack. D’après Tom Barron, le PTL de Manila, le projet est maintenant mature et son adoption est croissante (source : sondage d’utilisation d’OpenStack).
En ce qui concerne les évolutions, voici ce qu’on a pu noter : 
D’abord, l’API utilise python3 par défaut et intègre plus de fonctionnalités, comme la possibilité de créer des share_types et d’utiliser des Availability Zones
Ensuite, côté drivers, on note des améliorations significatives apportées par des constructeurs comme Dell/EMC et QNAP pour les pilotes compatibles avec leurs solutions de stockage. Le driver générique a aussi bénéficié d’améliorations concernant la performance et la stabilité. Des efforts sont également apportés à la mise à disposition d’un driver pour les containers, mais pour le moment il n’est pas encore utilisable en production.
On note également la possibilité de controller plus finement les droits en utilisant les Policies OpenStack. Les process de review de codes ont été simplifiés et les bugs qualifiés de « low hanging fruits » ont été catégorisés afin de faciliter l’accès à ces tâches aux non-initiés.
Enfin, pour la prochaine version qui sera mise à disposition aevc OpenStack Train, le focus se porte déjà sur la scalabilité, la résilience et l’interopérabilité. Des efforts sont attendus pour le support de Manila en mode actif/actif et également pour renforcer les back-ends open source tels que CephFS (qui a déjà beaucoup de contributeurs) mais aussi GlusterFS (moins de contributeurs).

 

Lessons learned running OpenInfrastructure on baremetal kubernetes clusters in production

Retour d’expérience d’openstack-helm en production par Alan Meadows & Pete Birley (AT&T).

Docker

  • La version 1.13 de docker présentaient des erreurs de démarrage en cas de corruption d’un seul conteneur. La corruption d’un conteneur n’est pas impactante pour kubelet, mais le disfonctionnement de docker l’est.
  • Solution temporaire : suppression des conteneurs corrompus à la main.
  • Upgrade 1.13 –> 17.03 : en apparence aucun problème de migration…en apparence. Gros impacte sur les noeuds (piques CPU réguliers,..).
  • Leur conseil pour les migrations : re-provisionner des noeuds avec la version cible de docker, et migrer les pods sur ces nouveaux noeuds.
A noter que la majorité des erreurs liées à docker ont été résolu :
  • Par un restart du démon docker
  • Par un reboot en dernier recours

Kubernetes

Une grande partie des erreurs rencontrées étaient dues à Kubernetes. On parle ici d’erreurs persistantes, les erreurs transitoires de kubernetes n’étant pas réellement impactantes.

Stockage

« Not so persistent volume claims » :
  • Pas mal d’erreurs de volumes provisionnés non-formattés
  • En cas de corruption du file system, le volume est re-formatté par kubelet (donc suppression des données du PV…).

Réseau

  • Le débugging du réseau est complexe (Neutron + Kubernetes). Il est souvent nécessaire de se connecter sur des douzaines de pods présents sur un noeud.
  • Problématiques de downtime des netns en cas de redémarrage de certains pods (ex: openvswitch-agent)
Solution : Monter les netns en bidirectionel dans le pod des agents

cgroups

De nombreuses erreurs liées aux cgroups:
  • Bug lié à la version 4.15.0-34-generic du kernel, et 229 de systemd : de nombreux cgroups en suspens à la création de pods. Consommation CPU accrue (essentiellement du à cadvisor)
  • Solution : script maison (temporaire) pour nettoyer ces cgroups.
  • Upgrades : hugepage cgroups intégré dans la version 1.10. A apporté des erreurs de fonctionnement de libvirt lors des upgrades.
  • Solutions : augmenter la limite au niveau du cgroups (court terme), ne pas utiliser la fonctionnalité de hugetlb dans Kubernetes (long terme)

Gestion des process

  • Beaucoup de process zombies jamais nettoyés, impact les limites système (ex: pid max,…) et engendre un dysfonctionnement du système
  • On ne souhaite parfois pas le nettoyage des process en cas d’arrêt du conteneur, exemple : libvirtd (si le conteneur s’arrête, on souhaite garder les process des VMs)
Solution : « shareProcessNamespace: true » dans le manifest des agents 

Kubernetes services

Petite explication du fonctionnement des services dans Kubernetes (kube-proxy configuré en iptables), et au passage un rappel de la multitude d’appels effectués lors d’une requête d’API OpenStack.
Le load balancing avec iptables n’est pas résilient car il ne vérifie pas réellement la disponibilité des pods. Conséquences : un ralentissement des requêtes OpenStack dans le cas où un service Kubernetes est défaillant.
Une piste d’amélioration : utiliser des ingress.

 

Pour résumer, conférence complète, avec des retours très concerts et dans la majorité des cas la solution apportée.
Pour les intéressés, la conférence sera en replay (https://www.openstack.org/videos/summits/).

 


 

Rook: A new and easy way to run your Ceph storage on Kubernetes

Rook est conçu pour déployer « facilement » un cluster Ceph dans kubernetes. Le projet fait maintenant partie des produits supportés par la CNCF.

Pour Blaine Gardner, Ceph a pour réputation d’être compliqué à administrer. Il faut donc trouver un moyen de le rendre plus « simple ».

Pourquoi ne pas profiter des possibilités proposées par Kubernetes pour déployer et maintenir un cluster Ceph ?

Rook tombe a pic!

L’outils n’a besoin que d’un simple fichier yaml pour lancer un déploiement de Ceph. Celui-ci doit contenir 5 éléments de base :

  • Définition de base pour les besoin de rook
  • L’operateur ceph dans rook
  • La définition du cluster Ceph
  • La définition du stockage objet, fichier, block
  • La toolbox

Demo Time!

5 minutes après le début de la démonstration, nous avons un cluster Ceph prêt a l’usage.

En plus des opérations de base fournies par un container « toolbox », Rook est capable de:

  • Gérer le recovery d’un OSD qui aurait crashé
  • Mettre à jour Rook
  • Mettre à jour Ceph

Des avancées sont prévues pour les prochaines releases de Rook :

  • Améliorer la sécurité réseau de l’hôte
  • Améliorer les processus de récupérations d’OSDs
  • Possibilité de piloter Ceph et Rook depuis le dashboard
  • Intégration de Rook dans Airship

Liens :

 


Multicloud CI/CD with OpenStack and kubernetes

La présentation a été réalisée par un consultant cloud belge. Pour le présenter en quelques mots, il a travaillé sur du cloud public et privé, sur de l’OpenStack, Kubernetes, Ceph et sur de l’intégration continue.
Le sujet qu’il présente parle sur l’utilisation d’une plateforme multicloud. Comment l’utiliser, comment la gérer.
Il faut définir plusieurs parties avant de continuer.
  • MultiCloud: Aujourd’hui, il existe de nombreux fournisseurs de plateforme cloud. Être un utilisateur de différent cloud est intéressant à 4 niveaux:
    • Le coût: Pouvoir changer lorsque le prix est moins élevé chez un autre fournisseur.
    • Un service résiliant: S’il y a une panne chez un fournisseur, le service continuera de fonctionner.
    • Les différentes features: gestion GPU chez l’un, meilleure connectivité réseaux chez l’autre par exemple
    • La localisation des cloud
  • CI/CD: Utiliser des outils de CI/CD permet d’accélérer le business et les test de failure.
  • OS & K8S: OpenStack fournit la possibilité de créer jusqu’à 60 avaibility zone donc jusqu’à 60 Cloud publique.
    Kubernetes est un orchestrateur de conteneur permettant de déployer des applications de manière reproductible. Il s’adapte à tout type d’infrastructure.
Le principe que Maxime a démontré est qu’un utilisateur n’a pas à se préoccuper de ce qui se passe en dessous. Il doit simplement avoir un nom DNS pour son application.
Le reste est géré en dessous par Kubernetes qui va permettre de déployer son applications dans différents pods.
Également, les différents Pods seront déployés dans différente instance sur OpenStack.

 

Et pour finir, chaque OpenStack sera déployé sur différent fournisseur Cloud. Malin non ? 
Comment gérer cette usine ? 

 

Pour la gestion de l’infrastructure:
  • Heat: C’est un composant natif à OpenStack. L’utilisation est limité car il ne gère que OpenStack.
  • Ansible: Un outil complet car il comporte beaucoup de module Cloud.
  • Terraform: C’est l’outil choisi par Maxime, il permet de gérer via des plans d’exécution quasiment tous les clouds.
Pour la gestion de Kubernetes:
  • Magnum: Seulement pour installer Kubernetes sur OpenStack. Pas très convainquant
  • KOPS: Seulement pour AWS, en cours sur l’intégration avec OpenStack.
  • Rancher: Fonctionne avec plusieurs Cloud mais pas pour OpenStack.
  • KubeSpray: Une bonne solution à choisir si l’on souhaite utiliser plusieurs fournisseur avec différents cloud.
Pour la gestion CI:
  • Jenkins
  • GitLab CI
DEMO TIME
Maxime nous a fait une démonstration en Live de l’utilisation de son multicloud.
Voici son architecture:
  • DNS RR pour la gestion du loadbalancer DNS
  • Kubespray pour installer ses kubernetes
  • Terraform pour gérer les différents cloud
  • CI/CD: gitlab CI 
  • 27 Régions
  • 18 Cloud provider
  • Openstack version de Havana à Queens
 Il a hébergé un site web simple avec l’affichage de la région par une photo de la capitale et le nom du noeud K8S.
 Sur GitLab, il a modifié son fichier HTML en remplacement le Hello World par Hello Denver. 
 Une fois modifié et poussé par GitLab CI, tous les nodes ont été mis à jours sur tous les OpenStack des différentes régions.
 Un rafraîchissement de la page web et la modification a été prise en compte quasiment instantanément.