Déployer un OpenStack avec un controlplane dans OpenShift géré par des operateurs

OpenStack est une solution composée d’un ensemble de logiciels qui fournit une plateforme libre d’Infrastructure as a Service (IaaS). Dans le paradigme cloud, une plateforme IaaS permet de gérer la puissance de calcul, l’espace de stockage et la connectivité réseau entre les composants de l’infrastructure et de les mettre à disposition à la demande.

Cependant les utilisateurs d’OpenStack savent que le choix de la solution de déploiement est décisif pour la bonne gestion de la plateforme. La solution de déploiement permet de gérer l’initialisation et le cycle de vie de la plateforme, comme par exemple, changer de configuration, ajouter des serveurs ou encore faire la mise à jour de la plateforme. En résumé, la solution de déploiement doit être flexible mais ne doit pas faire l’impasse sur la sécurité pour garantir la stabilité de la plateforme.

Dans cet article, nous allons plonger dans les évolutions du déploiement d’une plateforme OpenStack et analyser la solution de déploiement openstack-k8s-operators afin de découvrir si elle permet de répondre aux enjeux précédemment cités.

Déploiement OpenStack

Les différentes solutions de déploiement

Lors des premiers déploiements de la solution OpenStack, les administrateurs avaient pour habitude d’installer les services à la main sur les différents serveurs. Cette approche s’est très rapidement révélée complexe à maintenir notamment sur les plateformes de plusieurs de dizaines de serveurs.

Dans cette optique, les outils de gestion de configuration tels que Puppet ou Ansible ont été utilisés pour rendre la gestion des plateformes OpenStack plus industrialisable.

Par la suite, des solutions ont émergé pour déployer des plateformes OpenStack basées sur des architectures standards et gérées par Puppet ou Ansible. Ces solutions permettaient de mettre en commun les codes de déploiement et rendaient plus fiables le déploiement et la gestion d’une plateforme OpenStack.

Un des avantages des solutions de déploiement est la possibilité de gérer le cycle de vie des machines sur lesquelles la plateforme sera déployé et donc la gestion de l’installation système, des mises à jour ainsi que configurations (par exemple réseau).

Les conteneurs

Les premières solutions de déploiement installaient les services OpenStack directement sur le système d’exploitation. Ces services étaient gérés initialement par les scripts d’init System V puis ont naturellement basculé vers SystemD.

L’arrivée des conteneurs applicatifs type Docker dans le monde de l’informatique a permis de repenser la façon dont étaient distribués les services. Un des gros avantages des conteneurs est en effet la portabilité des déploiements : en embarquant la couche du système d’exploitation, ils se libèrenet des contraintes des systèmes sur lesquels ils s’exécutent. Les conteneurs apportent aussi d’autres avantages comme l’isolation entre les processus au sein de la même machine, ainsi qu’un déploiement et une gestion du cycle de vie applicatif grandement simplifiés. En conséquence : des mises à jour plus sereines, ce qui serait extrêmement utile à OpenStack…

La communauté OpenStack s’empare donc de ce nouveau paradigme et lance le projet Kolla. Le but du projet Kolla est de fournir des images pour les services OpenStack prêtes pour la production. Il s’agit d’une solution de construction d’images avec la possibilité de personnaliser celles-ci en fonction du besoin.

Pour pouvoir déployer ces images et permettre la création de plateformes OpenStack, la solution kolla-ansible peut être utilisée. Comme son nom l’indique, la solution utilise Ansible afin d’instancier les services OpenStack sous forme de conteneurs sur les machines de la plateforme. C’est l’une des solutions de déploiement la plus utilisée à ce jour.

Cette solution doit être couplée avec des solutions de déploiement de machines et d’OS dans le but d’automatiser le cycle de vie complet d’une plateforme OpenStack. Pour cela, il est possible d’utiliser la solution Kayobe, qui intègre Bifrost pour la gestion des machines et kolla-ansible pour le déploiement des services.

En route vers l’orchestration

Un des grands tournants dans le monde du conteneur à été l’adoption des solutions d’orchestration, notamment Kubernetes. Kubernetes est une plateforme conçue pour automatiser le déploiement de conteneurs sur plusieurs machines et gérer leurs mises à l’échelle. En plus de ces deux points, Kubernetes possède plusieurs atouts comme la tolérance aux pannes, la gestion de la mise en réseau des conteneurs et l’accès aux applications qu’ils embarquent. Kubernetes a permis l’utilisation de conteneurs dans des environnements critiques et orientés production.

On peut diviser les services d’une plateforme OpenStack en deux groupes : ceux qui contrôlent les différentes ressources du cluster, aussi appelé plan de contrôle, et les ressources pilotées par celui-ci, aussi appelé plan de données ou plan de ressources. La perte du plan de contrôle a un impact sur la visualisation des ressources et l’interaction avec le cluster. Pour éviter cet impact, les services sont souvent étalés sur trois noeuds sur un mode de déploiement dit “Hautement disponible” (HA) dans le but d’être tolérant à la panne d’un serveur.

Nous avons expliqué précédemment que les atouts de Kubernetes étaient justement la tolérance à la panne et la haute disponibilité tout en permettant une gestion simplifiée de la mise à l’échelle des conteneurs. Kubernetes est donc une solution qui répond à tous les besoins nécessaires à l’hébergement des services du plan de contrôle. C’est pour cette raison que de plus en plus d’éditeurs, mais aussi la communauté, développent des solutions pour déployer le plan de contrôle OpenStack sur Kubernetes.

On peut citer la solution communautaire openstack-helm basée sur Helm qui permet de gérer des déploiements facilités d’applications sur Kubernetes. Une autre solution est openstack-k8s-operators basée sur les opérateurs Kubernetes permettant de piloter le déploiement et aussi de simplifier la mise à jour d’un plan de contrôle sur Kubernetes. Nous allons approfondir le fonctionnement de cette solution dans cet article.

openstack-k8s-operators

Avant de parler de la solution openstack-k8s-operators, il est important de comprendre la notion d’opérateur Kubernetes.

Les operateurs Kubernetes

Il s’agit d’une méthode pour déployer et gérer le cycle de vie complet d’applications complexes au sein d’un cluster Kubernetes. Le concept d’opérateur s’appuie sur les concepts de base de Kubernetes avec notamment la boucle d’arbitrage qui pilote l’état de l’application et de son déploiement sur Kubernetes. Les opérateurs sont vus comme des extensions à l’API Kubernetes afin de gérer des ressources personnalisées. Si on créait un opérateur pour gérer le déploiement d’une application nommée “SuperApp”, on pourrait alors créer une ressource personnalisée de type SuperApp avec ses paramètres de déploiement.

Voici à quoi cela pourrait ressembler :

apiVersion: superApp.com/v1
kind: SuperApp
metadata:
  name: SuperAppInstance1
spec:
  storage_size: 20g
  replicas: 3
  admin_user: superappadmin
  admin_password: superapppassword

Lors de l’installation d’un opérateur sur un cluster Kubernetes, plusieurs actions sont effectuées :

• Ajout d’une ressource nommée “Custom Ressource Definition (CRD)” qui précise les paramètres que l’on peut indiquer dans nos ressources personnalisées
• Ajout d’un pod controller qui surveille une ressource personnalisée “Custom Resource (CR)” créée par un utilisateur et effectue les actions correspondantes sur le cluster ou sur l’application pour arriver à l’état cible tel que décrit dans la ressource.

Le schéma suivant permet de comprendre le fonctionnement des opérateurs :

Le projet openstack-k8s-operator

Le projet a été initié par Red Hat pour son produit Red Hat OpenStack Services on OpenShift (RHOSO) en remplacement de l’ancien produit Red Hat OpenStack Platform (RHOSP) basé sur la solution TripleO. Comme son nom l’indique, la solution fait usage des opérateurs Kubernetes pour déployer et gérer tous les services du plan de contrôle OpenStack sur un cluster Kubernetes. Bien que la solution semble mentionner Kubernetes à plusieurs reprises, nos tests indiquent que seul OpenShift ou sa version communautaire OKD semble pouvoir être utilisé pour obtenir un déploiement fonctionnel. Nous utiliserons seulement des clusters OKD dans la suite de cet article.

La solution openstack-k8s-operator s’appuie sur plusieurs opérateurs pour effectuer le déploiement du plan de contrôle et la gestion des noeuds de calcul. Le déploiement d’un OpenStack avec cette solution peut-être découpé en 4 étapes différentes :

• Installation des opérateurs et des pré-requis.
• Configuration du réseau sur le cluster OKD.
• Déploiement du plan de contrôle.
• Déploiement ou adoption d’un plan de données (les noeuds de calcul).

Installation des opérateurs

La solution openstack-k8s-operator dépend aussi d’autres opérateurs qui sont nécessaires à son fonctionnement. En pré-requis à l’installation de la solution, il faudra installer les opérateurs suivants :

• nmstate operator : Il permet d’effectuer la configuration réseau des noeuds OKD.
• metallb operator : Il permet la gestion des VIP internes du cluster pour les différents services OpenStack.
• cert-manager operator : Il permet la gestion des certificats pour les différents services OpenStack.

Il faudra ensuite installer les custom ressources et les opérateurs de la solution. La version éditeur propose une ressource catalogsource afin que l’Operator Lifgecycle Manager puisse directement récupérer les images et les CRD associés. Pour le déploiement en version communautaire, il faudra construire ses propres images. Il existe plusieurs moyens d’effectuer ces constructions, vous pouvez trouver des méthodes de constructions ici ou là.

Configuration réseau sur le cluster OKD

Une notion d’isolation réseaux est présente au sein de la solution openstack-k8s-operator avec la création de réseaux distincts :

• Le réseau ctlplane : C’est le réseau utilisé par l’opérateur OpenStack afin d’exécuter des playbooks Ansible sur les noeuds de calcul (data-plane). Ces playbooks déploient et configurent les services sur les noeuds de calcul. C’est aussi le réseau utilisé pour les live-migration des instances entre les noeuds de calcul.
• Le réseau internalAPI : C’est le réseau que les services OpenStack utilisent pour discuter entre eux. Il est aussi utilisé par metallb afin d’héberger les différentes VIP des services internes.
• Le réseau storage : C’est le réseau d’accès au stockage pour les services OpenStack.
• Le réseau tenant : C’est le réseau utilisé pour le transport des réseaux self-service (réseaux privés des instances). En fonction du déploiement, il pourra être mise en place de différentes façons. Avec la solution OVN, c’est ce réseau qui permettra la construction des tunnels GENEVE entre tous les noeuds du cluster.

Pour effectuer la configuration des réseaux sur les noeuds OKD, nous utilisons l’opérateur nmstate. Il faut d’abord créer des NNCP (NodeNetworkConfigurationPolicy) pour ajouter des interfaces sur les différents réseaux précédents. Il faut ensuite utiliser le CNI Multus avec ses NAD (NetworkAttachmentDefinition) pour attacher les différents réseaux ou pods associés.

L’accès aux services OpenStack se fera au travers du mécanisme des routes OKD (extensions des ingress) pour la partie client publique et à travers les VIP MetalLB sur le réseaux internalAPI pour la partie interne.

Déploiement du plan de contrôle

Pour des raisons de simplicité la configuration du déploiement du plan de contrôle se fait au travers d’une seule ressource gérée par l’opérateur OpenStack. L’opérateur OpenStack est un méta-opérateur car il est chargé de créer toutes les autres ressources contrôlées par les autres opérateurs de la solution. La solution comprend des opérateurs spécifiques pour chaque composant d’OpenStack dont voici une liste non exhaustive, chacun portant le nom du composant qu’il est chargé de déployer et maintenir :

• nova-operator
• horizon-operator
• keystone-operator
• neutron-operator
• glance-operator
• cinder-operator
• placement-operator
• octavia-operator
• barbican-operator
• heat-operator
• designate-operator
• watcher-operator
• ironic-operator

D’autres opérateurs, dit d’infrastructure, sont des pré-requis nécessaires au fonctionnement des services OpenStack :

• ovn-operator est l’opérateur qui permet de déployer les ressources nécessaires au fonctionnement du SDN OVN sur le cluster OpenStack
• mariadb-operator est l’opérateur qui s’occupe de déployer les services de base de données sur Kubernetes
• rabbitmq-cluster-operator est l’opérateur qui s’occupe de déployer l’agent de message rabbitMQ
• openstack-ansibleee-operator est l’opérateur qui permet de lancer des environnements d’exécution Ansible sur Kubernetes

Le dépot github de la solution recense des exemples de déploiements de plan de contrôle.

Déploiement ou adoption d’un plan de données (les noeuds de calcul)

La solution permet d’utiliser des noeuds déjà installés et de les adopter dans le cluster ou bien de déployer des noeuds au travers de la solution.

Adoption communautaire

La communauté RDO semble avoir pris en main la solution et veut fournir un “RDO on OKD” qui n’existe actuellement qu’en version expérimentale. La documentation est disponible sur cette page.

Conclusion

Cette solution possède de nombreux avantages et notamment la possibilité de créer des plateformes avec à un passage à l’échelle simplifié.

Par contre elle amène une complexité supplémentaire avec la mise en place d’un cluster OKD. De plus il ne s’agit pas d’un usage simple de cluster OKD mais d’un usage avancé avec des modifications réseaux et des opérateurs. Il faut donc avoir une compréhension et une expérience significative dans la gestion d’un cluster Kubernetes avant de l’utiliser.

Des questions subsistent : Est-ce une solution stable ? La version communautaire est-elle suffisamment mature pour un passage en production ?

Dans un prochain article, nous reviendrons sur le déploiement de la solution et des problèmes que nous avons rencontrés pendant celui-ci.