Opérateur dans Kubernetes pour la gestion des clusters de bases de données. Vladislav Klimenko (Altinité, 2019)

Le rapport est consacré aux questions pratiques liées au développement d'un opérateur dans Kubernetes, à la conception de son architecture et de ses principes de fonctionnement de base.

Dans la première partie du rapport, nous considérerons :

• qu'est-ce qu'un opérateur dans Kubernetes et pourquoi est-il nécessaire ;
• comment exactement l'opérateur simplifie la gestion des systèmes complexes ;
• ce que l'opérateur peut et ne peut pas faire.

Passons ensuite à la discussion de la structure interne de l'opérateur. Examinons étape par étape l'architecture et le fonctionnement de l'opérateur. Regardons cela en détail :

• interaction entre l'opérateur et Kubernetes ;
• quelles fonctions l'opérateur assume et quelles fonctions il délègue à Kubernetes.

Examinons la gestion des fragments et des répliques de bases de données dans Kubernetes.
Nous aborderons ensuite les problèmes de stockage des données :

• comment travailler avec le stockage persistant du point de vue d'un opérateur ;
• pièges liés à l’utilisation du stockage local.

Dans la dernière partie du rapport, nous examinerons des exemples pratiques d'application opérateur clickhouse depuis Amazon ou Google Cloud Service. Le rapport est basé sur l'exemple de l'expérience de développement et d'exploitation d'un opérateur pour ClickHouse.

Vidéo:

Je m'appelle Vladislav Klimenko. Aujourd'hui, je voulais parler de notre expérience dans le développement et l'exploitation d'un opérateur, et il s'agit d'un opérateur spécialisé dans la gestion de clusters de bases de données. Par exemple Opérateur ClickHouse pour gérer le cluster ClickHouse.

Pourquoi avons-nous l'occasion de parler de l'opérateur et de ClickHouse ?

• Nous soutenons et développons ClickHouse.
• Pour le moment, nous essayons d'apporter lentement notre contribution au développement de ClickHouse. Et nous sommes deuxièmes après Yandex en termes de volume de modifications apportées à ClickHouse.
• Nous essayons de créer des projets supplémentaires pour l'écosystème ClickHouse.

J'aimerais vous parler d'un de ces projets. Il s'agit de l'opérateur ClickHouse pour Kubernetes.

Dans mon rapport, je voudrais aborder deux sujets :

• Le premier sujet concerne le fonctionnement de notre opérateur de gestion de base de données ClickHouse dans Kubernetes.
• Le deuxième sujet concerne le fonctionnement de tout opérateur, c'est-à-dire comment il interagit avec Kubernetes.

Toutefois, ces deux questions se croiseront tout au long de mon rapport.

Qui serait intéressé à écouter ce que j’essaie de dire ?

• Il intéressera surtout ceux qui exploitent des opérateurs.
• Ou pour ceux qui souhaitent créer le leur afin de comprendre comment cela fonctionne en interne, comment l'opérateur interagit avec Kubernetes et quels pièges peuvent apparaître.

Pour mieux comprendre ce dont nous allons discuter aujourd'hui, c'est une bonne idée de savoir comment fonctionne Kubernetes et de suivre une formation de base sur le cloud.

Qu’est-ce que ClickHouse ? Il s'agit d'une base de données en colonnes dotée de fonctionnalités spécifiques pour le traitement en ligne des requêtes analytiques. Et c'est complètement open source.

Et il est important pour nous de savoir seulement deux choses. Vous devez savoir qu'il s'agit d'une base de données, donc ce que je vais vous dire sera applicable à presque toutes les bases de données. Et le fait que le SGBD ClickHouse évolue très bien donne une évolutivité presque linéaire. Et par conséquent, l’état du cluster est un état naturel pour ClickHouse. Et nous sommes particulièrement intéressés par la manière de servir le cluster ClickHouse dans Kubernetes.

Pourquoi est-il nécessaire là-bas ? Pourquoi ne pouvons-nous pas continuer à l’exploiter nous-mêmes ? Et les réponses sont en partie techniques et en partie organisationnelles.

• Dans la pratique, nous sommes de plus en plus confrontés à une situation où, dans les grandes entreprises, presque tous les composants sont déjà dans Kubernetes. Les bases de données restent à l’extérieur.
• Et la question se pose de plus en plus : « Est-ce que cela peut être placé à l’intérieur ? Par conséquent, les grandes entreprises tentent d'atteindre une unification maximale de la gestion afin de pouvoir gérer rapidement leurs entrepôts de données.
• Et cela est particulièrement utile si vous avez besoin d'un maximum de possibilités de répéter la même chose dans un nouvel endroit, c'est-à-dire d'une portabilité maximale.

Est-ce facile ou difficile ? Bien entendu, cela peut être fait à la main. Mais ce n'est pas si simple, car nous avons la complexité supplémentaire de gérer Kubernetes lui-même, mais en même temps les spécificités de ClickHouse se superposent. Et c’est une telle agrégation qui en résulte.

Et dans l'ensemble, cela donne un ensemble assez large de technologies, qui devient assez difficile à gérer, car Kubernetes met en œuvre ses propres problèmes quotidiens, et ClickHouse apporte ses propres problèmes au fonctionnement quotidien. Surtout si nous avons plusieurs ClickHouses et que nous devons constamment faire quelque chose avec eux.

Avec une configuration dynamique, ClickHouse présente un assez grand nombre de problèmes qui créent une charge constante sur DevOps :

• Lorsque nous voulons modifier quelque chose dans ClickHouse, par exemple ajouter une réplique ou un fragment, nous devons alors gérer la configuration.
• Modifiez ensuite le schéma de données, car ClickHouse a une méthode de partitionnement spécifique. Là, vous devez présenter le diagramme de données, présenter les configurations.
• Vous devez mettre en place une surveillance.
• Collecte de journaux pour les nouveaux fragments, pour les nouvelles répliques.
• Prenez soin de la restauration.
• Et redémarrez.

Ce sont des tâches de routine que j’aimerais vraiment rendre plus faciles à utiliser.

Kubernetes lui-même aide bien au fonctionnement, mais sur les éléments de base du système.

Kubernetes est efficace pour faciliter et automatiser des choses telles que :

• Récupération.
• Redémarrage.
• Gestion du système de stockage.

C'est bien, c'est la bonne direction, mais il ne sait absolument pas comment faire fonctionner un cluster de bases de données.

Nous en voulons plus, nous voulons que toute la base de données fonctionne dans Kubernetes.

J'aimerais avoir quelque chose comme un gros bouton rouge magique sur lequel vous appuyez et un cluster avec des tâches quotidiennes qui doivent être résolues est déployé et maintenu tout au long de son cycle de vie. Cluster ClickHouse dans Kubernetes.

Et nous avons essayé de trouver une solution qui faciliterait le travail. Il s'agit d'un opérateur ClickHouse pour Kubernetes d'Altinity.

Un opérateur est un programme dont la tâche principale est de gérer d'autres programmes, c'est-à-dire qu'il est un gestionnaire.

Et il contient des modèles de comportement. Vous pouvez appeler cela des connaissances codifiées sur le domaine.

Et sa tâche principale est de faciliter la vie du DevOps et de réduire la microgestion, afin qu'il (DevOps) pense déjà en termes de haut niveau, c'est-à-dire qu'il (DevOps) ne s'engage pas dans la microgestion, afin qu'il ne configure pas tous les détails manuellement.

Et seul l'opérateur est un assistant robotique qui s'occupe des microtâches et aide DevOps.

Pourquoi avez-vous besoin d'un opérateur ? Il est particulièrement performant dans deux domaines :

• Lorsque le spécialiste qui s'occupe de ClickHouse n'a pas assez d'expérience, mais a déjà besoin de faire fonctionner ClickHouse, l'opérateur facilite l'opération et permet d'exploiter un cluster ClickHouse avec une configuration assez complexe, sans trop entrer dans les détails de son fonctionnement. à l'intérieur. Vous lui confiez simplement des tâches de haut niveau, et ça marche.
• Et la deuxième tâche dans laquelle il est le plus performant est lorsqu’il est nécessaire d’automatiser un grand nombre de tâches typiques. Supprime les microtâches des administrateurs système.

C'est ce dont ont le plus besoin soit ceux qui commencent tout juste leur voyage, soit ceux qui ont besoin de faire beaucoup d'automatisation.

En quoi l’approche basée sur l’opérateur diffère-t-elle des autres systèmes ? Il y a Helm. Cela aide également à installer ClickHouse ; vous pouvez dessiner des graphiques de barre, qui installeront même un cluster ClickHouse entier. Quelle est alors la différence entre l'opérateur et le même, par exemple Helm ?

La principale différence fondamentale est que Helm est une gestion de packages et Operator va encore plus loin. Il s’agit d’un support pour l’ensemble du cycle de vie. Il ne s'agit pas seulement d'installation, ce sont des tâches quotidiennes qui incluent la mise à l'échelle, le partitionnement, c'est-à-dire tout ce qui doit être fait pendant le cycle de vie (si nécessaire, puis la suppression également) - tout cela est décidé par l'opérateur. Il tente d'automatiser et de maintenir l'intégralité du cycle de vie du logiciel. C'est sa différence fondamentale par rapport aux autres solutions présentées.

C'était la partie introductive, passons à autre chose.

Comment construisons-nous notre opérateur? Nous essayons d'aborder le problème pour gérer le cluster ClickHouse comme une ressource unique.

Ici, nous avons les données d'entrée sur le côté gauche de l'image. Il s'agit de YAML avec une spécification de cluster, qui est transmise à Kubernetes de manière classique via kubectl. Là, notre opérateur le récupère et fait sa magie. Et en sortie, nous obtenons le schéma suivant. Il s'agit d'une implémentation de ClickHouse dans Kubernetes.

Et puis, nous examinerons lentement comment fonctionne exactement l'opérateur, quelles tâches typiques peuvent être résolues. Nous ne considérerons que les tâches typiques car nous disposons de peu de temps. Et tout ce que l’opérateur peut décider ne sera pas discuté.

Commençons par la pratique. Notre projet est entièrement open source, vous pouvez donc voir comment il fonctionne sur GitHub. Et vous pouvez partir des considérations selon lesquelles si vous souhaitez simplement le lancer, vous pouvez commencer avec le Guide de démarrage rapide.

Si vous souhaitez comprendre en détail, nous essayons de maintenir la documentation sous une forme plus ou moins décente.

Commençons par un problème pratique. La première tâche, par laquelle nous voulons tous commencer, consiste à exécuter le premier exemple d’une manière ou d’une autre. Comment lancer ClickHouse avec l’opérateur, même si je ne sais pas vraiment comment ça marche ? Nous écrivons un manifeste, parce que... Toute communication avec les k8 est une communication via des manifestes.

C’est un manifeste tellement complexe. Ce que nous avons souligné en rouge est ce sur quoi nous devons nous concentrer. Nous demandons à l'opérateur de créer un cluster nommé demo.

Ce sont des exemples de base pour l’instant. Le stockage n'a pas encore été décrit, mais nous y reviendrons un peu plus tard. Pour l’instant, nous allons observer la dynamique de développement du cluster.

Nous avons créé ce manifeste. Nous le donnons à notre opérateur. Il travaillait, il faisait de la magie.

Nous regardons la console. Trois composants sont intéressants : un Pod, deux Services et un StatefulSet.

L'opérateur a travaillé et nous pouvons voir exactement ce qu'il a créé.

Il crée quelque chose comme ça. Nous avons un StatefulSet, Pod, ConfigMap pour chaque réplique, ConfigMap pour l'ensemble du cluster. Les services sont requis comme points d’entrée dans le cluster.

Les services constituent le service central d'équilibrage de charge et peuvent également être utilisés pour chaque réplica, pour chaque partition.

Notre cluster de base ressemble à ceci. Il s'agit d'un seul nœud.

Allons plus loin et compliquons les choses. Nous devons partitionner le cluster.

Nos tâches s'agrandissent, une dynamique s'amorce. Nous voulons ajouter un fragment. Nous suivons l'évolution. Nous modifions notre cahier des charges. Nous indiquons que nous voulons deux fragments.

Il s'agit du même fichier qui se développe dynamiquement avec la croissance du système. Stockage non, le stockage sera discuté plus loin, c'est un sujet distinct.

Nous nourrissons l'opérateur YAML et voyons ce qui se passe.

L'opérateur a pensé et réalisé les entités suivantes. Nous avons déjà deux Pods, trois Services et, du coup, 2 StatefulSets. Pourquoi 2 StatefulSets ?

Sur le diagramme, c'était comme ceci : c'est notre état initial, lorsque nous n'avions qu'un seul pod.

C'est devenu comme ça. Jusqu'à présent, tout est simple, c'est dupliqué.

Et pourquoi est-il devenu deux StatefulSets ? Ici, nous devons faire une parenthèse et discuter de la question de savoir comment les pods sont gérés dans Kubernetes.

Il existe un objet appelé StatefulSet qui vous permet de créer un ensemble de pods à partir d'un modèle. Le facteur clé ici est le modèle. Et vous pouvez lancer de nombreux pods en utilisant un seul modèle dans un seul StatefulSet. Et la phrase clé ici est « plusieurs pods pour un seul modèle ».

Et la tentation était grande de créer le cluster entier en le regroupant dans un seul StatefulSet. Cela fonctionnera, il n'y a aucun problème avec ça. Mais il y a une mise en garde. Si nous souhaitons constituer un cluster hétérogène, c'est-à-dire à partir de plusieurs versions de ClickHouse, alors nos questions commencent. Oui, StatefulSet peut effectuer une mise à jour continue, et là, vous pouvez déployer une nouvelle version, expliquez que vous ne devez pas essayer plus d'un certain nombre de nœuds en même temps.

Mais si nous extrapolons la tâche et disons que nous voulons créer un cluster complètement hétérogène et que nous ne voulons pas passer de l'ancienne version à une nouvelle en utilisant une mise à jour continue, mais que nous voulons simplement créer un cluster hétérogène à la fois en termes de différentes versions de ClickHouse et en termes de stockage différent. Nous souhaitons, par exemple, réaliser certaines répliques sur des disques séparés, sur des disques lents, en général, pour construire complètement un cluster hétérogène. Et comme StatefulSet crée une solution standardisée à partir d'un seul modèle, il n'y a aucun moyen de le faire.

Après réflexion, il a été décidé que nous procéderions de cette façon. Nous avons chaque réplique dans son propre StatefulSet. Cette solution présente certains inconvénients, mais en pratique, tout est entièrement encapsulé par l'opérateur. Et les avantages sont nombreux. Nous pouvons construire exactement le cluster que nous souhaitons, par exemple un cluster absolument hétérogène. Par conséquent, dans un cluster dans lequel nous avons deux fragments avec une réplique, nous aurons 2 StatefulSets et 2 Pods précisément parce que nous avons choisi cette approche pour les raisons évoquées ci-dessus afin de pouvoir construire un cluster hétérogène.

Revenons aux problèmes pratiques. Dans notre cluster, nous devons configurer les utilisateurs, c'est-à-dire vous devez effectuer une configuration de ClickHouse dans Kubernetes. L'opérateur offre toutes les possibilités pour cela.

Nous pouvons écrire ce que nous voulons directement en YAML. Toutes les options de configuration sont mappées directement à partir de ce YAML dans les configurations ClickHouse, qui sont ensuite distribuées dans tout le cluster.

Vous pouvez l'écrire comme ça. C'est par exemple. Le mot de passe peut être crypté. Absolument toutes les options de configuration ClickHouse sont prises en charge. Voici juste un exemple.

La configuration du cluster est distribuée sous forme de ConfigMap. En pratique, la mise à jour de ConfigMap ne se produit pas instantanément, donc si le cluster est volumineux, le processus de poussée de la configuration prend un certain temps. Mais tout cela est très pratique à utiliser.

Compliquons la tâche. Le cluster se développe. Nous voulons répliquer les données. Autrement dit, nous avons déjà deux fragments, une réplique chacun, et les utilisateurs sont configurés. Nous grandissons et souhaitons faire de la réplication.

De quoi avons-nous besoin pour la réplication ?

Nous avons besoin de ZooKeeper. Dans ClickHouse, la réplication est construite à l'aide de ZooKeeper. ZooKeeper est nécessaire pour que les différentes répliques ClickHouse aient un consensus concernant les blocs de données sur lesquels ClickHouse.

ZooKeeper peut être utilisé par n’importe qui. Si l'entreprise dispose d'un ZooKeeper externe, celui-ci peut être utilisé. Sinon, vous pouvez l'installer depuis notre référentiel. Il existe un programme d'installation qui facilite tout cela.

Et le diagramme d'interaction de l'ensemble du système se présente ainsi. Nous avons Kubernetes comme plateforme. Il exécute l'opérateur ClickHouse. J'ai imaginé ZooKeeper ici. Et l'opérateur interagit à la fois avec ClickHouse et ZooKeeper. C'est-à-dire les résultats de l'interaction.

Et tout cela est nécessaire pour que ClickHouse réussisse à répliquer les données dans les k8.

Examinons maintenant la tâche elle-même et voyons à quoi ressemblera le manifeste de réplication.

Nous ajoutons deux sections à notre manifeste. La première est de savoir où trouver ZooKeeper, qui peut être interne à Kubernetes ou externe. Ceci est juste une description. Et nous commandons des répliques. Ceux. nous voulons deux répliques. Au total, nous devrions avoir 4 pods en sortie. On se souvient du stockage, cela reviendra un peu plus tard. Le stockage est une autre histoire.

C'était comme ça.

Cela devient comme ça. Des répliques sont ajoutées. Le 4ème ne rentre pas, nous pensons qu'il pourrait y en avoir beaucoup. Et ZooKeeper est ajouté sur le côté. Les schémas deviennent de plus en plus complexes.

Et il est temps d'ajouter la tâche suivante. Nous ajouterons le stockage persistant.

Pour le stockage persistant, nous proposons différentes options.

Si nous utilisons un fournisseur de cloud, par exemple Amazon, Google, la tentation est alors grande d'utiliser le stockage dans le cloud. C'est très pratique, c'est bien.

Et il existe une deuxième option. C'est pour le stockage local, lorsque nous avons des disques locaux sur chaque nœud. Cette option est beaucoup plus difficile à mettre en œuvre, mais en même temps elle est plus productive.

Voyons ce que nous avons concernant le stockage cloud.

Il y a des avantages. C'est très simple à configurer. Nous commandons simplement auprès du fournisseur de cloud qu'il nous fournisse un stockage de telle ou telle capacité, de telle ou telle classe. Les cours sont programmés par les prestataires de manière indépendante.

Et il y a un inconvénient. Pour certains, il s'agit d'un inconvénient non critique. Bien sûr, il y aura quelques problèmes de performances. Il est très pratique à utiliser et fiable, mais il présente certains inconvénients potentiels en termes de performances.

Et parce que ClickHouse se concentre spécifiquement sur la productivité, on pourrait même dire qu'il exploite tout ce qu'il peut, c'est pourquoi de nombreux clients tentent d'obtenir une productivité maximale.

Et pour en tirer le meilleur parti, nous avons besoin d’un stockage local.

Kubernetes fournit trois abstractions pour utiliser le stockage local dans Kubernetes. Ce:

• VideDir
• Chemin d'hôte.
• Lieu

Voyons en quoi ils diffèrent et en quoi ils se ressemblent.

Premièrement, dans les trois approches, nous avons du stockage - ce sont des disques locaux situés sur le même nœud physique k8s. Mais ils présentent quelques différences.

Commençons par le plus simple, à savoir emptyDir. Qu’est-ce que c’est en pratique ? Dans notre spécification, nous demandons au système de conteneurisation (le plus souvent Docker) de nous fournir un accès à un dossier sur le disque local.

En pratique, Docker crée un dossier temporaire quelque part sur ses propres chemins et l'appelle un long hachage. Et fournit une interface pour y accéder.

Comment cela fonctionnera-t-il en termes de performances ? Cela fonctionnera à la vitesse du disque local, c'est-à-dire C'est un accès complet à votre vis.

Mais cette affaire a son inconvénient. La persistance est assez douteuse en la matière. La première fois que Docker se déplace avec des conteneurs, Persistent est perdu. Si Kubernetes souhaite déplacer ce pod vers un autre disque pour une raison quelconque, les données seront perdues.

Cette approche est bonne pour les tests, car elle montre déjà une vitesse normale, mais pour quelque chose de sérieux, cette option ne convient pas.

Il existe donc une deuxième approche. Il s'agit du chemin hôte. Si vous regardez la diapositive précédente et celle-ci, vous ne verrez qu’une seule différence. Notre dossier a été déplacé de Docker directement vers le nœud Kubernetes. C'est un peu plus simple ici. Nous spécifions directement le chemin sur le système de fichiers local où nous souhaitons stocker nos données.

Cette méthode présente des avantages. C'est déjà un vrai Persistant, et un classique en plus. Nous aurons des données enregistrées sur le disque à une certaine adresse.

Il y a aussi des inconvénients. C'est la complexité de la gestion. Notre Kubernetes souhaitera peut-être déplacer le Pod vers un autre nœud physique. Et c’est là que DevOps entre en jeu. Il doit expliquer correctement à l'ensemble du système que ces pods ne peuvent être déplacés que vers les nœuds sur lesquels quelque chose est monté le long de ces chemins, et pas plus d'un nœud à la fois. C'est assez difficile.

Surtout à ces fins, nous avons réalisé des modèles chez notre opérateur afin de masquer toute cette complexité. Et vous pourriez simplement dire : « Je souhaite avoir une instance de ClickHouse pour chaque nœud physique et le long de tel ou tel chemin. »

Mais nous ne sommes pas les seuls à avoir besoin de ce besoin, donc les messieurs de Kubernetes eux-mêmes comprennent également que les gens veulent avoir accès aux disques physiques, ils fournissent donc une troisième couche.

Cela s'appelle local. Il n'y a pratiquement aucune différence par rapport à la diapositive précédente. Seulement avant, il était nécessaire de confirmer manuellement que nous ne pouvons pas transférer ces pods d'un nœud à l'autre, car ils doivent être attachés via un chemin vers un disque physique local, mais maintenant toutes ces connaissances sont encapsulées dans Kubernetes lui-même. Et cela s’avère beaucoup plus simple à configurer.

Revenons à notre problème pratique. Revenons au modèle YAML. Ici, nous avons un vrai stockage. Nous y sommes de retour. Nous définissons le modèle VolumeClaim classique comme dans k8s. Et nous décrivons le type de stockage que nous souhaitons.

Après cela, les k8 demanderont du stockage. Nous l'attribuera dans le StatefulSet. Et à terme, il sera à la disposition de ClickHouse.

Nous avions ce schéma. Notre stockage persistant était rouge, ce qui semblait laisser entendre que cela devait être fait.

Et ça devient vert. Le schéma de cluster ClickHouse sur k8s est désormais complètement finalisé. Nous avons des fragments, des répliques, ZooKeeper, nous avons un vrai Persistent, qui est implémenté d'une manière ou d'une autre. Le système est déjà pleinement opérationnel.

Nous continuons à vivre. Notre cluster se développe. Et Alexey essaie et publie une nouvelle version de ClickHouse.

Une tâche pratique se présente : tester la nouvelle version de ClickHouse sur notre cluster. Et, bien sûr, vous ne voulez pas tout déployer ; vous voulez mettre une nouvelle version dans une réplique quelque part dans le coin le plus éloigné, et peut-être pas une nouvelle version, mais deux à la fois, car elles sortent souvent.

Que pouvons-nous dire à ce sujet ?

Ici, nous avons justement une telle opportunité. Ce sont des modèles de pods. Vous pouvez écrire que notre opérateur vous permet totalement de construire un cluster hétérogène. Ceux. configurez, en commençant par toutes les répliques d'un groupe, en terminant par chaque réplique personnelle, quelle version nous voulons ClickHouse, quelle version nous voulons stocker. Nous pouvons entièrement configurer le cluster avec la configuration dont nous avons besoin.

Allons un peu plus profondément à l'intérieur. Avant cela, nous avons parlé du fonctionnement de l'opérateur ClickHouse par rapport aux spécificités de ClickHouse.

Je voudrais maintenant dire quelques mots sur le fonctionnement général de tout opérateur, ainsi que sur la manière dont il interagit avec les K8.

Voyons d'abord interagir avec les K8. Que se passe-t-il lorsque nous appliquons Kubectl ? Nos objets apparaissent dans etcd via l'API.

Par exemple, les objets Kubernetes de base : pod, StatefulSet, service, etc. dans la liste.

En même temps, rien de physique ne se produit encore. Ces objets doivent être matérialisés dans le cluster.

A cet effet, un contrôleur apparaît. Le contrôleur est un composant spécial k8s qui peut matérialiser ces descriptions. Il sait comment et quoi faire physiquement. Il sait comment exécuter des conteneurs, ce qui doit y être configuré pour que le serveur fonctionne.

Et cela matérialise nos objets en K8.

Mais nous voulons fonctionner non seulement avec des pods et des StatefulSets, nous voulons créer une ClickHouseInstallation, c'est-à-dire un objet de type ClickHouse, afin de fonctionner avec lui comme un tout. Jusqu’à présent, une telle possibilité n’existe pas.

Mais K8s a la bonne chose suivante. Nous voulons que nous ayons quelque part comme cette entité complexe dans laquelle notre cluster serait assemblé à partir de pods et de StatefulSet.

Et que faut-il faire pour cela ? Tout d’abord, la définition des ressources personnalisées entre en scène. Ce que c'est? Ceci est une description pour les K8, que vous aurez un type de données supplémentaire, que nous souhaitons ajouter une ressource personnalisée au pod, StatefulSet, qui sera complexe à l'intérieur. Ceci est une description de la structure des données.

Nous l'envoyons également là-bas via kubectl apply. Kubernetes l'a pris avec plaisir.

Et maintenant, dans notre stockage, l'objet dans etcd a la possibilité d'enregistrer une ressource personnalisée appelée ClickHouseInstallation.

Mais pour l’instant, il ne se passera rien d’autre. Autrement dit, si nous créons maintenant le fichier YAML que nous avons examiné décrivant les fragments et les répliques et disons « kubectl apply », alors Kubernetes l'acceptera, le mettra dans etcd et dira : « Super, mais je ne sais pas quoi faire. avec ça. Je ne sais pas comment maintenir ClickHouseInstallation.

En conséquence, nous avons besoin de quelqu’un pour aider Kubernetes à gérer le nouveau type de données. Sur la gauche, nous avons un contrôleur Kubernetes natif qui fonctionne avec des types de données natifs. Et sur la droite, nous devrions avoir un contrôleur personnalisé capable de fonctionner avec des types de données personnalisés.

Et d'une autre manière, cela s'appelle un opérateur. Je l'ai spécifiquement inclus ici sous le nom de Kubernetes, car il peut également être exécuté en dehors des K8. Le plus souvent, bien sûr, tous les opérateurs sont exécutés dans Kubernetes, mais rien ne l'empêche de se tenir à l'extérieur, il est donc ici spécialement déplacé à l'extérieur.

Et à son tour, un contrôleur personnalisé, également appelé opérateur, interagit avec Kubernetes via l'API. Il sait déjà comment interagir avec l'API. Et il sait déjà matérialiser le circuit complexe que l’on souhaite réaliser à partir d’une ressource personnalisée. C'est exactement ce que fait l'opérateur.

Comment fonctionne l'opérateur ? Regardons du côté droit pour voir comment il procède. Voyons comment l'opérateur matérialise tout cela et comment se produit la poursuite de l'interaction avec les K8.

Un opérateur est un programme. Elle est orientée événement. L'opérateur s'abonne aux événements via l'API Kubernetes. L'API Kubernetes dispose de points d'entrée où vous pouvez vous abonner à des événements. Et si quelque chose change dans les K8, alors Kubernetes envoie des événements à tout le monde, c'est-à-dire quiconque s'est abonné à ce point API recevra des notifications.

L'opérateur s'abonne aux événements et doit réagir d'une manière ou d'une autre. Sa tâche est de réagir aux événements émergents.

Les événements sont générés par certaines mises à jour. Notre fichier YAML avec une description de ClickHouseInstallation arrive. Il est allé à etcd via kubectl apply. Un événement y a été déclenché et, par conséquent, cet événement est arrivé à l'opérateur ClickHouse. L'opérateur a reçu cette description. Et il doit faire quelque chose. Si une mise à jour est arrivée pour l'objet ClickHouseInstallation, vous devez alors mettre à jour le cluster. Et la tâche de l’opérateur est de mettre à jour le cluster.

Que fait-il? Tout d’abord, nous devons élaborer un plan d’action pour ce que nous ferons avec cette mise à jour. Les mises à jour peuvent être très petites, c'est-à-dire petit dans l'exécution de YAML, mais peut entraîner des changements très importants sur le cluster. Par conséquent, l’opérateur crée un plan, puis il s’y tient.

Selon ce plan, il commence à cuire cette structure à l'intérieur afin d'y matérialiser des pods, des services, c'est à dire. faire quelle est sa tâche principale. Voici comment créer un cluster ClickHouse dans Kubernetes.

Parlons maintenant d'une chose aussi intéressante. Il s'agit d'un partage des responsabilités entre Kubernetes et l'opérateur, c'est-à-dire ce que fait Kubernetes, ce que fait l'opérateur et comment ils interagissent les uns avec les autres.

Kubernetes est responsable des éléments du système, c'est-à-dire pour un ensemble d'objets de base qui peuvent être interprétés comme étant de portée système. Kubernetes sait comment lancer des pods, comment redémarrer des conteneurs, comment monter des volumes, comment travailler avec ConfigMap, c'est-à-dire tout ce qu'on peut appeler un système.

Les opérateurs opèrent dans des domaines. Chaque opérateur est conçu pour son propre domaine. Nous l'avons fait pour ClickHouse.

Et l'opérateur interagit précisément en fonction du domaine, comme ajouter une réplique, réaliser un schéma, mettre en place une surveillance. Il en résulte une division.

Examinons un exemple pratique de la façon dont cette division des responsabilités se produit lorsque nous effectuons l'action d'ajout de réplique.

L'opérateur reçoit une tâche : ajouter une réplique. Que fait l'opérateur ? L'opérateur calculera qu'un nouveau StatefulSet doit être créé, dans lequel tel ou tel modèle, revendication de volume, devra être décrit.

Il a tout préparé et le transmet aux K8. Il dit qu'il a besoin de ConfigMap, StatefulSet, Volume. Kubernetes fonctionne. Il matérialise les unités de base avec lesquelles il opère.

Et puis l’opérateur ClickHouse entre à nouveau en jeu. Il possède déjà un pod physique sur lequel il peut déjà faire quelque chose. Et l'opérateur ClickHouse fonctionne à nouveau en termes de domaine. Ceux. Plus précisément ClickHouse, afin d'inclure une réplique dans un cluster, vous devez d'abord configurer le schéma de données qui existe dans ce cluster. Et deuxièmement, cette réplique doit être incluse dans la surveillance afin qu’elle puisse être clairement tracée. L'opérateur le configure déjà.

Et seulement après cela, ClickHouse lui-même entre en jeu, c'est-à-dire une autre entité de niveau supérieur. C'est déjà une base de données. Il possède sa propre instance, une autre réplique configurée prête à rejoindre le cluster.

Il s’avère que la chaîne d’exécution et de partage des responsabilités lors de l’ajout d’une réplique est assez longue.

Nous continuons nos tâches pratiques. Si vous disposez déjà d'un cluster, vous pouvez migrer la configuration.

Nous avons fait en sorte que vous puissiez coller du XML existant, ce que ClickHouse comprend.

Vous pouvez affiner ClickHouse. Le déploiement zoné est ce dont j'ai parlé en expliquant hostPath, le stockage local. Voici comment effectuer correctement un déploiement zoné.

La prochaine tâche pratique est la surveillance.

Si notre cluster change, nous devons alors configurer périodiquement la surveillance.

Regardons le diagramme. Nous avons déjà regardé les flèches vertes ici. Regardons maintenant les flèches rouges. C'est ainsi que nous voulons surveiller notre cluster. Comment les métriques du cluster ClickHouse entrent dans Prometheus, puis dans Grafana.

Quelle est la difficulté du suivi ? Pourquoi est-ce présenté comme une sorte de réussite ? La difficulté réside dans la dynamique. Lorsque nous avons un cluster et qu'il est statique, nous pouvons alors configurer la surveillance une fois et ne plus nous embêter.

Mais si nous avons beaucoup de clusters ou si quelque chose change constamment, alors le processus est dynamique. Et reconfigurer constamment la surveillance est une perte de ressources et de temps, c'est-à-dire même juste de la paresse. Cela doit être automatisé. La difficulté réside dans la dynamique du processus. Et l'opérateur automatise cela très bien.

Comment notre cluster s’est-il développé ? Au début, il était comme ça.

Puis il était comme ça.

Finalement, il est devenu comme ça.

Et la surveillance est effectuée automatiquement par l'opérateur. Point d'entrée unique.

Et juste à la sortie, nous regardons le tableau de bord Grafana pour voir comment bouillonne la vie de notre cluster à l'intérieur.

D'ailleurs, le tableau de bord Grafana est également distribué auprès de notre opérateur directement dans le code source. Vous pouvez vous connecter et utiliser. Notre DevOps m'a donné cette capture d'écran.

Où aimerions-nous aller ensuite ? Ce:

• Développer l'automatisation des tests. La tâche principale est le test automatisé des nouvelles versions.
• Nous souhaitons également vraiment automatiser l'intégration avec ZooKeeper. Et il est prévu d'intégrer l'opérateur ZooKeeper. Ceux. Un opérateur a été écrit pour ZooKeeper et il est logique que les deux opérateurs commencent à s'intégrer pour construire une solution plus pratique.
• Nous voulons étudier des signes vitaux plus complexes.
• J'ai souligné en vert que nous approchons de l'héritage des modèles - DONE, c'est-à-dire qu'avec la prochaine version de l'opérateur, nous aurons déjà l'héritage des modèles. Il s'agit d'un outil puissant qui vous permet de créer des configurations complexes à partir de pièces.
• Et nous voulons une automatisation des tâches complexes. Le principal est le re-sharding.

Prenons quelques résultats intermédiaires.

Qu’obtient-on en conséquence ? Et est-ce que ça vaut le coup ou pas ? Est-il même nécessaire d'essayer de glisser la base de données dans Kubernetes et d'utiliser l'opérateur en général et l'opérateur Alitnity en particulier ?

En sortie on obtient :

• Simplification et automatisation significatives de la configuration, du déploiement et de la maintenance.
• Surveillance immédiatement intégrée.
• Et des modèles codifiés prêts à l’emploi pour les situations complexes. Une action telle que l’ajout d’une réplique n’a pas besoin d’être effectuée manuellement. C'est l'opérateur qui le fait.

Il ne reste qu'une dernière question. Nous avons déjà une base de données dans Kubernetes, la virtualisation. Qu’en est-il des performances d’une telle solution, d’autant plus que ClickHouse est optimisé pour les performances ?

La réponse est que tout va bien ! Je n'entrerai pas dans les détails, c'est le sujet d'un rapport séparé.

Mais il existe un projet tel que TSBS. Quelle est sa mission principale ? Il s'agit d'un test de performances de base de données. Il s'agit d'une tentative de comparer le chaud avec le chaud, le doux avec le doux.

Comment travaille-t-il ? Un ensemble de données est généré. Ensuite, cet ensemble de données est exécuté sur différentes bases de données en utilisant le même ensemble de tests. Et chaque base de données résout un problème comme elle le sait. Et puis vous pourrez comparer les résultats.

Il prend déjà en charge un grand nombre de bases de données. J’en ai identifié trois principaux. Ce:

• Échelle de tempsDB.
• InfluxDB.
• Cliquez sur Maison.

Une comparaison a également été faite avec une autre solution similaire. Comparaison avec RedShift. La comparaison a été faite sur Amazon. ClickHouse est également bien en avance sur tout le monde en la matière.

Quelles conclusions peut-on tirer de ce que j’ai dit ?

• La base de données dans Kubernetes est possible. Tout est probablement possible, mais dans l’ensemble, cela semble possible. ClickHouse dans Kubernetes est tout à fait possible avec l'aide de notre opérateur.
• L'opérateur aide à automatiser les processus et rend vraiment la vie plus facile.
• Les performances sont normales.
• Et il nous semble que cela peut et doit être utilisé.

Open source – rejoignez-nous !

Comme je l'ai déjà dit, l'opérateur est un produit entièrement open source, ce serait donc très bien si le maximum de personnes l'utilisaient. Rejoignez-nous! Nous vous attendons tous !

Merci à tous!

des questions

Merci pour le rapport! Je m'appelle Anton. Je viens de SEMrush. Je me demande ce qui se passe avec la journalisation. On parle de surveillance, mais pas de journalisation, si l'on parle de l'ensemble du cluster. Par exemple, nous avons créé un cluster sur le matériel. Et nous utilisons une journalisation centralisée, en les collectant dans un tas commun à l'aide de moyens standard. Et puis à partir de là, nous obtenons les données qui nous intéressent.

Bonne question, c'est-à-dire se connecter à une liste de tâches. Notre opérateur n'automatise pas encore cela. Il est encore en développement, le projet est encore assez jeune. Nous comprenons la nécessité de la journalisation. C'est aussi un sujet très important. Et ce n’est probablement pas moins important que la surveillance. Mais la première priorité à mettre en œuvre était le suivi. Il y aura une journalisation. Bien entendu, nous essayons d’automatiser tous les aspects de la vie du cluster. Par conséquent, la réponse est que pour le moment, l’opérateur ne sait malheureusement pas comment faire cela, mais c’est dans les plans, nous le ferons. Si vous souhaitez nous rejoindre, faites une pull request, s'il vous plaît.

Bonjour! Merci pour le rapport! J'ai une question standard liée aux volumes persistants. Lorsque nous créons une configuration avec cet opérateur, comment l'opérateur détermine-t-il sur quel nœud un disque ou un dossier particulier est-il attaché ? Il faut d'abord lui expliquer que s'il vous plait placez notre ClickHouse sur ces nœuds qui ont un disque ?

Autant que je sache, cette question est une continuation du stockage local, en particulier de sa partie hostPath. C'est comme expliquer à l'ensemble du système qu'il faut lancer le pod sur tel ou tel nœud, auquel on a un disque physiquement connecté, qui est monté selon tel ou tel chemin. C’est toute une section que j’ai abordée de manière très superficielle car la réponse y est assez vaste.

En bref, cela ressemble à ceci. Naturellement, nous devons provisionner ces volumes. Pour le moment, il n'y a pas de disposition dynamique dans le stockage local, les DevOps doivent donc couper eux-mêmes les disques, ces volumes. Et ils doivent expliquer le provisionnement de Kubernetes que vous aurez des volumes persistants de telle ou telle classe, qui sont situés sur tel ou tel nœuds. Il faudra ensuite expliquer à Kubernetes que les pods qui nécessitent telle ou telle classe de stockage local doivent être dirigés uniquement vers tel ou tel nœuds à l'aide d'étiquettes. À ces fins, l'opérateur a la possibilité d'attribuer une sorte d'étiquette et une par instance hôte. Et il s'avère que les pods seront acheminés par Kubernetes pour s'exécuter uniquement sur des nœuds qui répondent aux exigences, aux étiquettes, en termes simples. Les administrateurs attribuent des étiquettes et provisionnent les disques manuellement. Et puis ça évolue.

Et c’est la troisième option, locale, qui contribue à rendre les choses un peu plus faciles. Comme je l'ai déjà souligné, il s'agit d'un travail de réglage minutieux, qui permet finalement d'obtenir des performances maximales.

J'ai une deuxième question à ce sujet. Kubernetes a été conçu de telle manière que peu importe que nous perdions un nœud ou non. Que devons-nous faire dans ce cas si nous avons perdu le nœud où est suspendu notre fragment ?

Oui, Kubernetes était initialement positionné selon lequel notre relation avec nos pods était comme celle du bétail, mais ici, chez nous, chaque disque devient quelque chose comme un animal de compagnie. Il y a un tel problème que nous ne pouvons pas simplement les jeter. Et le développement de Kubernetes va dans le sens où il est impossible de le traiter complètement avec philosophie, comme s'il s'agissait d'une ressource complètement abandonnée.

Passons maintenant à une question pratique. Que faire si vous avez perdu le nœud sur lequel se trouvait le disque ? Ici, le problème est résolu à un niveau supérieur. Dans le cas de ClickHouse, nous avons des répliques qui fonctionnent à un niveau supérieur, c'est-à-dire au niveau ClickHouse.

Quelle est la disposition qui en résulte ? DevOps est chargé de garantir que les données ne sont pas perdues. Il doit configurer correctement la réplication et doit s'assurer que la réplication est en cours d'exécution. La réplique au niveau ClickHouse doit avoir des données dupliquées. Ce n'est pas le problème que l'opérateur résout. Et ce n’est pas le problème que Kubernetes lui-même résout. C'est au niveau ClickHouse.

Que faire si votre nœud de fer tombe ? Et il s'avère que vous devrez en installer un deuxième, y approvisionner correctement le disque et appliquer des étiquettes. Et après cela, il remplira les conditions requises pour que Kubernetes puisse lancer un pod d'instance dessus. Kubernetes le lancera. Votre nombre de pods n'est pas suffisant pour atteindre le nombre spécifié. Cela passera par le cycle que j’ai montré. Et au plus haut niveau, ClickHouse comprendra que nous avons saisi une réplique, qu'elle est toujours vide et que nous devons commencer à y transférer des données. Ceux. Ce processus n'est pas encore bien automatisé.

Merci pour le rapport! Lorsque toutes sortes de choses désagréables se produisent, l'opérateur plante et redémarre, et à ce moment-là les événements arrivent, gérez-vous cela d'une manière ou d'une autre ?

Que se passe-t-il si l'opérateur plante et redémarre, n'est-ce pas ?

Oui. Et c’est à ce moment-là que les événements sont arrivés.

La tâche de savoir quoi faire dans ce cas est en partie partagée entre l'opérateur et Kubernetes. Kubernetes a la capacité de rejouer un événement qui s'est produit. Il rejoue. Et la tâche de l’opérateur est de s’assurer que lorsque le journal des événements est relu sur lui, ces événements sont idempotents. Et pour que la répétition du même événement ne brise pas notre système. Et notre opérateur s'acquitte de cette tâche.

Bonjour! Merci pour le rapport! Dmitri Zavyalov, entreprise Smedova. Est-il prévu d'ajouter la possibilité de configuration avec haproxy à l'opérateur ? Je serais intéressé par un autre équilibreur que celui standard, afin qu'il soit intelligent et comprenne que ClickHouse est vraiment là.

Parlez-vous d’Ingress ?

Oui, remplacez Ingress par haproxy. Dans haproxy, vous pouvez spécifier la topologie du cluster sur lequel il contient des réplicas.

Nous n'y avons pas encore réfléchi. Si vous en avez besoin et pouvez expliquer pourquoi cela est nécessaire, il sera alors possible de le mettre en œuvre, surtout si vous souhaitez y participer. Nous serons heureux d’étudier cette option. La réponse courte est non, nous ne disposons pas actuellement d’une telle fonctionnalité. Merci pour le conseil, nous allons étudier cette question. Et si vous expliquez également le cas d'utilisation et pourquoi cela est nécessaire dans la pratique, par exemple, créez des problèmes sur GitHub, alors ce sera formidable.

J'ai déjà

Bien. Nous sommes ouverts à toutes suggestions. Et haproxy est ajouté à la liste de tâches. La liste de choses à faire s’allonge, mais ne diminue pas encore. Mais c'est bien, cela veut dire que le produit est demandé.

Source: habr.com