MariaDB Galera Cluster sur Red Hat Open-Shift/Kubernetes
Dans ce billet, nous présentons une solution pour faire fonctionner un cluster MariaDB Galera sur Kubernetes ou des solutions compatibles (par exemple, Red Hat OpenShift Container Platform, CoreOS Tectonic et Kubernetes de Canonical). Il permet d’exécuter des applications natives dans le Cloud dans Kubernetes et les sources de données nécessaires pour fonctionner dans la même infrastructure et gérer avec les mêmes outils.
La fonctionnalité est basée sur la fonctionnalité PetSets de Kubernetes, une API destinée aux applications stateful.
Que sont les PetSets
Au cours des dernières années, Kubernetes est passé d’un nouvel outil de gestion des conteneurs à un projet qui donne le ton dans ce domaine. En raison de l’architecture de Kubernetes, il était auparavant difficile d’exécuter des applications et des services qui n’étaient pas sans état. Les premières idées de ce qu’il est convenu d’appeler des “services nominaux” ont été proposées très tôt, mais n’ont pas été mises en œuvre en raison d’autres priorités.
Avec la sortie de Kubernetes v1.3, il y a maintenant un premier aperçu d’une solution. Avec PetSets, une API en statut alpha a été créée dans Kubernetes qui est spécifiquement adaptée aux exigences des applications et services à état. Pods dans un PetSet obtiennent un nom unique et un index numérique (par exemple app-0, app-1, …) qui reste le même pendant toute la vie du Pod. De plus, les Volumes persistants restent associés au Pod même s’il est migré vers un autre hôte. Comme un[service] est attribué à chaque PetSet, il est possible de traiter des informations sur les dosettes du PetSet via des requêtes au service. Cela permet, par exemple, d’automatiser le démarrage d’un cluster, ou d’ajuster la configuration au moment de l’exécution en conséquence, si l’état du cluster change (mise à l’échelle, réduction, maintenance ou défaillance d’un hôte, …).
Comment le Cluster MariaDB Galera peut-il fonctionner sur Kubernetes ?
Pour exécuter un cluster MariaDB Galera sur Kubernetes, il est nécessaire d’implémenter le bootstrap du cluster et l’adaptation de la configuration basée sur les pods actuels dans le PetSet. Dans notre cas, ces deux tâches sont effectuées par deux Init Containers. Dans le Docker Image galera-init les outils appropriés sont empaquetés pour exécuter le bootstrap, le second conteneur démarre le `peer-finder’ binaire qui interroge l’enregistrement SRV du service Kubernetes et génère la configuration du cluster MariaDB Galera en fonction des membres du PetSet.
Quand le premier Pets est lancé, wsrep_cluster_address=gcomm:/// est défini dans la configuration et le Pod effectue automatiquement un bootstrap du cluster. Tous les autres familiers qui sont lancés remplissent wsrep_cluster_address avec le nom d’hôte de l’enregistrement SRV du service, et rejoignent automatiquement le cluster existant. Voici un exemple de configuration après le démarrage du deuxième familier:
wsrep_cluster_address=gcomm://mariadb-0.galera.lf2.svc.cluster.local,mariadb-1.galera.lf2.svc.cluster.local
wsrep_cluster_name=mariadb
wsrep_node_address=mariadb-1.galera.lf2.svc.cluster.local
Les sources correspondantes pour tester MariaDB Galera Cluster sur votre propre infrastructure Kubernetes ou Red Hat OSCP sont publiées sur Github : https://github.com/adfinis-sygroup/openshift-mariadb-galera>
Limites des PetSets en statut Alpha
Les limitations des PetSets à l’état alpha sont expliquées dans la Documentation Kubernetes et affectent plusieurs domaines, notamment les tâches qui doivent être traitées manuellement. Par exemple, il n’est possible d’augmenter le nombre de répliques qu’en utilisant le paramètre replicas, mais non de les diminuer. De plus, une mise à jour de la définition du PetSet n’est pas possible automatiquement, donc une mise à jour vers une nouvelle version d’image doit être faite manuellement via un nouveau PetSet.
Quel est l’avenir des PetSets ?
Avec la sortie de Kubernetes v1.5 PetSets quitte le statut alpha et est élevé sous le nom StatefulSet dans le statut bêta. Il s’agit d’un développement important car l’API externe de Kubernetes ne change pas après le statut bêta. La sortie de Kubernetes v1.5 est prévue pour le 9 décembre 2016.
prochains travaux
Un autre billet de blog sera publié dès la sortie de Kubernetes v1.5. Il contient des mises à jour des définitions YAML et des instructions supplémentaires sur la façon de tester les clusters MariaDB Galera sur votre propre infrastructure.