Local<\/li>\n<\/ul>\n<\/p>\n
Consid\u00e9rons comment ils diff\u00e8rent et se ressemblent. <\/p>\n
<\/p>\n
Tout d'abord, dans les trois approches, le stockage est constitu\u00e9 de disques locaux situ\u00e9s sur le m\u00eame n\u0153ud physique Kubernetes. Mais ils ont certaines diff\u00e9rences.<\/p>\n
<\/p>\n
<\/p>\n
Commen\u00e7ons par le plus simple, c'est-\u00e0-dire emptyDir. Qu'est-ce que c'est en pratique ? C'est quand dans notre sp\u00e9cification, nous demandons au syst\u00e8me de conteneurisation (la plupart du temps, c'est Docker) de nous donner acc\u00e8s \u00e0 un dossier sur le disque local.<\/p>\n
<\/p>\n
En pratique, Docker cr\u00e9e quelque part, sur ses propres chemins, un dossier temporaire, le nommant avec un long hachage. Et il fournit une interface d'acc\u00e8s \u00e0 celui-ci. <\/p>\n
<\/p>\n
Comment cela fonctionnera-t-il en termes de performance ? Cela fonctionnera \u00e0 la vitesse du disque local, c'est-\u00e0-dire que c'est un acc\u00e8s complet \u00e0 votre disque. <\/p>\n
<\/p>\n
Mais cela a son inconv\u00e9nient. La persistance est assez douteuse dans ce cas. \u00c0 la premi\u00e8re action de Docker avec des conteneurs, la persistance est perdue. Si Kubernetes d\u00e9cide pour une raison quelconque de d\u00e9placer ce Pod sur un autre disque, les donn\u00e9es seront perdues. <\/p>\n
<\/p>\n
Cette approche est bonne pour les tests, car elle montre d\u00e9j\u00e0 une vitesse satisfaisante, mais pour quelque chose de s\u00e9rieux, cette option n'est pas ad\u00e9quate. <\/p>\n
<\/p>\n
<\/p>\n
C'est pourquoi il existe une deuxi\u00e8me approche. C'est le hostPath. Si nous regardons les diapositives pr\u00e9c\u00e9dentes et celle-ci, nous pouvons voir une seule diff\u00e9rence. Notre dossier a \u00e9t\u00e9 d\u00e9plac\u00e9 du Docker vers le n\u0153ud Kubernetes. C'est un peu plus simple. Nous inscrivons directement le chemin dans le syst\u00e8me de fichiers local o\u00f9 nous souhaitons stocker nos donn\u00e9es. <\/p>\n
<\/p>\n
Ce moyen pr\u00e9sente des avantages. C'est une v\u00e9ritable persistance, et en plus, c'est classique. Les donn\u00e9es seront enregistr\u00e9es sur le disque \u00e0 une certaine adresse. <\/p>\n
<\/p>\n
Il y a aussi des inconv\u00e9nients. C'est la complexit\u00e9 de la gestion. Notre Kubernetes peut vouloir d\u00e9placer un Pod vers un autre n\u0153ud physique. Et c'est l\u00e0 qu'intervient DevOps. Il doit bien expliquer \u00e0 tout le syst\u00e8me que ces Pods ne peuvent \u00eatre d\u00e9plac\u00e9s que sur des n\u0153uds o\u00f9 tu as quelque chose mont\u00e9 sur ces chemins, et pas plus d'un n\u0153ud \u00e0 la fois. C'est assez compliqu\u00e9. <\/p>\n
<\/p>\n
Sp\u00e9cifiquement pour ces besoins, nous avons cr\u00e9\u00e9 des mod\u00e8les chez notre op\u00e9rateur pour cacher toute cette complexit\u00e9. On pouvait simplement dire : \u00ab Je veux qu'il y ait une instance de ClickHouse sur chaque n\u0153ud physique et sur tel chemin \u00bb. <\/p>\n
<\/p>\n
<\/p>\n
Mais ce besoin n'est pas seulement le n\u00f4tre, donc les messieurs de Kubernetes comprennent aussi que les gens veulent acc\u00e9der aux disques physiques, c'est pourquoi ils offrent un troisi\u00e8me niveau.<\/p>\n
<\/p>\n
Cela s'appelle local. La diff\u00e9rence avec la diapositive pr\u00e9c\u00e9dente est pratiquement nulle. Auparavant, il fallait le faire manuellement, dire que ces Pods ne peuvent pas \u00eatre d\u00e9plac\u00e9s d'un n\u0153ud \u00e0 un autre, parce qu'ils doivent \u00eatre attach\u00e9s \u00e0 un chemin sp\u00e9cifique d'un disque physique local, et maintenant toutes ces connaissances sont encapsul\u00e9es dans Kubernetes lui-m\u00eame. Et donc, c'est beaucoup plus facile \u00e0 configurer.<\/p>\n
<\/p>\n
<\/p>\n
Revenons \u00e0 notre t\u00e2che pratique. Revenons au mod\u00e8le YAML. Ici, nous avons un vrai stockage. Nous sommes revenus \u00e0 cela. Nous d\u00e9finissons un mod\u00e8le classique VolumeClaim comme dans k8s. Et nous d\u00e9crivons quel stockage nous voulons.<\/p>\n
<\/p>\n
Apr\u00e8s cela, k8s demandera du stockage. Il nous en attribuera dans le StatefulSet. Et finalement, cela sera \u00e0 la disposition de ClickHouse.<\/p>\n
<\/p>\n
<\/p>\n
Nous avions un sch\u00e9ma comme ceci. Notre stockage persistant \u00e9tait rouge, ce qui sugg\u00e9rait qu'il fallait le faire. <\/p>\n
<\/p>\n
<\/p>\n
Et il devient vert. Maintenant, le sch\u00e9ma du cluster ClickHouse sur k8s est compl\u00e8tement finalis\u00e9. Nous avons des shards, des r\u00e9pliques, ZooKeeper, il y a un vrai persistant, r\u00e9alis\u00e9 d'une mani\u00e8re ou d'une autre. Le sch\u00e9ma est d\u00e9j\u00e0 enti\u00e8rement op\u00e9rationnel. <\/p>\n
<\/p>\n
<\/p>\n
Nouscontinuons \u00e0 avancer. Notre cluster \u00e9volue. Et Alexey s'efforce, il sort une nouvelle version de ClickHouse.<\/p>\n
<\/p>\n
Une t\u00e2che pratique se pose - tester la nouvelle version de ClickHouse sur notre cluster. \u00c9videmment, on ne veut pas tout mettre \u00e0 jour, on veut peut-\u00eatre installer la nouvelle version dans un coin \u00e9loign\u00e9 sur une r\u00e9plique, ou peut-\u00eatre pas une nouvelle version, mais deux, car elles sortent fr\u00e9quemment. <\/p>\n
<\/p>\n
Que pouvons-nous en dire ?<\/p>\n
<\/p>\n
<\/p>\n
Ici, nous avons justement cette possibilit\u00e9. Ce sont des mod\u00e8les de pod. On peut d\u00e9tailler comment notre op\u00e9rateur permet de construire un cluster h\u00e9t\u00e9rog\u00e8ne. C\u2019est-\u00e0-dire configur\u00e9, allant de toutes les r\u00e9pliques en tas, jusqu'\u00e0 chaque r\u00e9plique personnelle, avec quelle version de ClickHouse nous souhaitons, quelle version de stockage nous voulons. Nous pouvons compl\u00e8tement configurer un cluster de cette configuration comme nous en avons besoin. <\/p>\n
<\/p>\n
<\/p>\n
Nous allons maintenant approfondir un peu. Auparavant, nous avons parl\u00e9 du fonctionnement de l'op\u00e9rateur ClickHouse en relation avec la sp\u00e9cificit\u00e9 de ClickHouse.<\/p>\n
<\/p>\n
Maintenant, j'aimerais dire quelques mots sur le fonctionnement de n'importe quel op\u00e9rateur, ainsi que sur la mani\u00e8re dont il interagit avec K8s.<\/p>\n
<\/p>\n
<\/p>\n
Commen\u00e7ons par examiner l'interaction avec K8s. Que se passe-t-il lorsque nous faisons un kubectl apply ? Nos objets apparaissent via l'API dans etcd. <\/p>\n
<\/p>\n
<\/p>\n
Par exemple, les objets de base de Kubernetes : pod, StatefulSet, service, etc. <\/p>\n
<\/p>\n
\u00c0 ce stade, rien de physique ne se produit encore. Ces objets doivent \u00eatre mat\u00e9rialis\u00e9s dans le cluster. <\/p>\n
<\/p>\n
<\/p>\n
Pour cela, un contr\u00f4leur appara\u00eet. Le contr\u00f4leur est un composant sp\u00e9cial de k8s qui sait comment mat\u00e9rialiser ces descriptions. Il sait comment et ce qu'il faut faire physiquement. Il sait comment ex\u00e9cuter des conteneurs, ce qu'il faut configurer pour que le serveur fonctionne. <\/p>\n
<\/p>\n
<\/p>\n
Et il mat\u00e9rialise nos objets dans K8s.<\/p>\n
<\/p>\n
Mais nous voulons op\u00e9rer non seulement avec des pods et des StatefulSets, nous voulons cr\u00e9er une ClickHouseInstallation, c'est-\u00e0-dire un objet de type ClickHouse, pour l'op\u00e9rer comme un tout. Pour l'instant, cette possibilit\u00e9 n'existe pas. <\/p>\n
<\/p>\n
<\/p>\n
Mais K8s a une autre chose sympa. Nous souhaitons qu'il y ait quelque part cette entit\u00e9 complexe, qui serait constitu\u00e9e de pods et de StatefulSets pour notre cluster. <\/p>\n
<\/p>\n
<\/p>\n
Et que faut-il faire pour cela ? Tout d'abord, la Custom Resource Definition entre en jeu. Qu'est-ce que c'est ? C'est une description pour K8s indiquant que vous aurez un autre type de donn\u00e9es, que nous souhaitons ajouter une ressource personnalis\u00e9e complexe aux pods et StatefulSets. C'est une description de la structure des donn\u00e9es. <\/p>\n
<\/p>\n
<\/p>\n
Nous l'envoyons \u00e9galement via kubectl apply. Kubernetes l'a joyeusement accept\u00e9. <\/p>\n
<\/p>\n
Et maintenant, nous avons dans le stockage, dans l'objet dans etcd, la possibilit\u00e9 d'enregistrer une ressource personnalis\u00e9e appel\u00e9e ClickHouseInstallation.<\/p>\n
<\/p>\n
Mais pour l'instant, rien d'autre ne se produira. C'est-\u00e0-dire que si nous cr\u00e9ons maintenant un fichier YAML que nous avons examin\u00e9, contenant la description des shards, des r\u00e9pliques, et que nous ex\u00e9cutons \u00ab kubectl apply \u00bb, Kubernetes l'acceptera, le mettra dans etcd et dira : \u00ab Tr\u00e8s bien, mais je ne sais pas quoi en faire. Je ne sais pas comment g\u00e9rer ClickHouseInstallation. \u00bb <\/p>\n
<\/p>\n
<\/p>\n
Par cons\u00e9quent, nous avons besoin de quelqu'un pour aider Kubernetes \u00e0 g\u00e9rer un nouveau type de donn\u00e9es. \u00c0 gauche, nous avons le contr\u00f4leur Kubernetes par d\u00e9faut, qui travaille avec des types de donn\u00e9es standard. \u00c0 droite, nous devrions avoir un contr\u00f4leur personnalis\u00e9 qui sait travailler avec des types de donn\u00e9es personnalis\u00e9s. <\/p>\n
<\/p>\n
Et autrement dit, cela s'appelle un op\u00e9rateur. Je l'ai ici sp\u00e9cifiquement mis en dehors de Kubernetes, car il peut fonctionner en dehors de K8s. Le plus souvent, tous les op\u00e9rateurs fonctionnent dans Kubernetes, mais rien ne l'emp\u00eache de fonctionner \u00e0 l'ext\u00e9rieur, c'est pourquoi il est sp\u00e9cifiquement mis \u00e0 l'ext\u00e9rieur ici. <\/p>\n
<\/p>\n
<\/p>\n
Et d\u00e9j\u00e0 \u00e0 son tour, le contr\u00f4leur personnalis\u00e9, aussi appel\u00e9 op\u00e9rateur, interagit avec Kubernetes via l'API. Il sait d\u00e9j\u00e0 interagir avec l'API. Et il sait d\u00e9j\u00e0 comment mat\u00e9rialiser un sch\u00e9ma complexe \u00e0 partir d'une ressource personnalis\u00e9e que nous voulons cr\u00e9er. C'est pr\u00e9cis\u00e9ment ce que fait l'op\u00e9rateur. <\/p>\n
<\/p>\n
<\/p>\n
Comment fonctionne un op\u00e9rateur ? Regardons la partie droite pour savoir comment il fait cela. D\u00e9couvrons comment l'op\u00e9rateur mat\u00e9rialise tout cela et comment se d\u00e9roule ensuite l'interaction avec K8s.<\/p>\n
<\/p>\n
<\/p>\n
L'op\u00e9rateur est un programme. Il est orient\u00e9 \u00e9v\u00e9nements. L'op\u00e9rateur s'abonne aux \u00e9v\u00e9nements via l'API Kubernetes. Dans l'API Kubernetes, il existe des points d'entr\u00e9e o\u00f9 l'on peut s'abonner aux \u00e9v\u00e9nements. Et si quelque chose change dans K8s, Kubernetes envoie des \u00e9v\u00e9nements \u00e0 tous ceux qui le souhaitent, c'est-\u00e0-dire que ceux qui se sont abonn\u00e9s \u00e0 ce point API recevront des notifications.<\/p>\n
<\/p>\n
L'op\u00e9rateur s'abonne aux \u00e9v\u00e9nements et doit effectuer une certaine r\u00e9action. Sa t\u00e2che est de r\u00e9agir aux \u00e9v\u00e9nements qui apparaissent. <\/p>\n
<\/p>\n
<\/p>\n
Les \u00e9v\u00e9nements sont g\u00e9n\u00e9r\u00e9s par certaines mises \u00e0 jour. Notre fichier YAML avec la description de ClickHouseInstallation arrive. Il passe par kubectl apply et va dans etcd. Un \u00e9v\u00e9nement a alors \u00e9t\u00e9 d\u00e9clench\u00e9, et cet \u00e9v\u00e9nement est finalement arriv\u00e9 au ClickHouse-operator. L'op\u00e9rateur a re\u00e7u cette description. Et il doit faire quelque chose. Si une mise \u00e0 jour de l'objet ClickHouseInstallation arrive, il faut mettre \u00e0 jour le cluster. Et la t\u00e2che de l'op\u00e9rateur est de mettre \u00e0 jour le cluster. <\/p>\n
<\/p>\n
<\/p>\n
Que fait-il ? Tout d'abord, il faut \u00e9tablir un plan d'action pour d\u00e9terminer ce que nous allons faire avec cette mise \u00e0 jour. Les mises \u00e0 jour peuvent \u00eatre tr\u00e8s petites, c'est-\u00e0-dire de petites ex\u00e9cutions YAML, mais elles peuvent entra\u00eener des changements tr\u00e8s importants dans le cluster. Par cons\u00e9quent, l'op\u00e9rateur cr\u00e9e un plan et s'y tient ensuite.<\/p>\n
<\/p>\n
<\/p>\n
Il commence \u00e0 travailler en conformit\u00e9 avec ce plan pour mat\u00e9rialiser les pod, les services, c'est-\u00e0-dire pour faire ce qui est sa t\u00e2che principale. C'est comme construire un cluster ClickHouse dans Kubernetes.<\/p>\n
<\/p>\n
<\/p>\n
D\u00e9sormais, abordons une question int\u00e9ressante. Il s'agit de la r\u00e9partition des responsabilit\u00e9s entre Kubernetes et l'op\u00e9rateur, c'est-\u00e0-dire ce que fait Kubernetes, ce que fait l'op\u00e9rateur et comment ils interagissent entre eux. <\/p>\n
<\/p>\n
Kubernetes s'occupe des \u00e9l\u00e9ments syst\u00e8me, c'est-\u00e0-dire du jeu d'objets de base qui peut \u00eatre interpr\u00e9t\u00e9 comme un ensemble \u00e0 port\u00e9e syst\u00e8me. Kubernetes sait comment lancer des pod, red\u00e9marrer des conteneurs, monter des volumes, travailler avec ConfigMap, c'est-\u00e0-dire tout ce qui peut \u00eatre qualifi\u00e9 de syst\u00e8me. <\/p>\n
<\/p>\n
Les op\u00e9rateurs op\u00e8rent dans des domaines d'application. Chaque op\u00e9rateur est con\u00e7u pour son domaine d'application. Nous avons cr\u00e9\u00e9 celui pour ClickHouse.<\/p>\n
<\/p>\n
Et l'op\u00e9rateur interagit pr\u00e9cis\u00e9ment dans les termes du domaine d'application, tels que l'ajout d'une r\u00e9plique, la cr\u00e9ation d'un sch\u00e9ma, la configuration de la surveillance. Il en r\u00e9sulte une telle r\u00e9partition.<\/p>\n
<\/p>\n
<\/p>\n
Examinons un exemple pratique de la fa\u00e7on dont cette r\u00e9partition des responsabilit\u00e9s se produit lorsque nous effectuons l'action d'ajout d'une r\u00e9plique. <\/p>\n
<\/p>\n
L'op\u00e9rateur re\u00e7oit la t\u00e2che d'ajouter une r\u00e9plique. Que fait-il ? L'op\u00e9rateur calcule qu'il faut cr\u00e9er un nouveau StatefulSet, dans lequel il doit d\u00e9crire certains mod\u00e8les et les r\u00e9clamations de volumes. <\/p>\n
<\/p>\n
<\/p>\n
Il pr\u00e9pare tout cela et le transmet ensuite \u00e0 K8s. Il indique qu'il a besoin d'une ConfigMap, d'un StatefulSet, d'un Volume. Kubernetes ex\u00e9cute cela. Il mat\u00e9rialise les unit\u00e9s de base avec lesquelles il fonctionne. <\/p>\n
<\/p>\n
<\/p>\n
Et ensuite, le ClickHouse-operator entre \u00e0 nouveau en jeu. Il a d\u00e9j\u00e0 un pod physique sur lequel il peut travailler. Et le ClickHouse-operator travaille \u00e0 nouveau dans les termes du domaine d'application. C'est-\u00e0-dire que pour inclure une r\u00e9plique dans le cluster ClickHouse, il faut d'abord configurer le sch\u00e9ma de donn\u00e9es existant dans ce cluster. Deuxi\u00e8mement, cette r\u00e9plique doit \u00eatre int\u00e9gr\u00e9e dans la surveillance afin d'\u00eatre bien suivie. L'op\u00e9rateur s'en occupe d\u00e9j\u00e0. <\/p>\n
<\/p>\n
<\/p>\n
Et ce n'est qu'ensuite que ClickHouse entre en jeu, c'est-\u00e0-dire une autre entit\u00e9 de niveau sup\u00e9rieur. C'est d\u00e9j\u00e0 une base de donn\u00e9es. Elle dispose de sa propre instance, d'une nouvelle r\u00e9plique configur\u00e9e, pr\u00eate \u00e0 rejoindre le cluster.<\/p>\n
<\/p>\n
On obtient une cha\u00eene d'ex\u00e9cution et de r\u00e9partition des responsabilit\u00e9s lors de l'ajout d'une r\u00e9plique qui est assez longue.<\/p>\n
<\/p>\n
<\/p>\n
Continuons nos t\u00e2ches pratiques. Si le cluster existe d\u00e9j\u00e0, il est possible d'effectuer la migration de la configuration. <\/p>\n
<\/p>\n
<\/p>\n
Nous avons fait en sorte que dans le XML existant, que ClickHouse comprend, on puisse passer \u00e0 travers.<\/p>\n
<\/p>\n
<\/p>\n
Il est possible de faire un r\u00e9glage fin de ClickHouse. En fait, le d\u00e9ploiement zon\u00e9 est ce dont j'ai parl\u00e9 en expliquant hostPath, le stockage local. C'est comment r\u00e9aliser correctement un d\u00e9ploiement zon\u00e9.<\/p>\n
<\/p>\n
<\/p>\n
La prochaine t\u00e2che pratique concerne la surveillance.<\/p>\n
<\/p>\n
<\/p>\n
Si notre cluster change, il est n\u00e9cessaire de configurer p\u00e9riodiquement la surveillance. <\/p>\n
<\/p>\n
Examinons le sch\u00e9ma. Nous avons d\u00e9j\u00e0 \u00e9tudi\u00e9 les fl\u00e8ches vertes ici. Maintenant, regardons les fl\u00e8ches rouges. C'est ainsi que nous voulons surveiller notre cluster. Comment les m\u00e9triques du cluster ClickHouse vont dans Prometheus, puis dans Grafana.<\/p>\n
<\/p>\n
<\/p>\n
Quelle est la difficult\u00e9 li\u00e9e \u00e0 la surveillance ? Pourquoi cela est-il consid\u00e9r\u00e9 comme un accomplissement ? La complexit\u00e9 r\u00e9side dans la dynamique. Lorsque nous avons un cluster unique et qu'il est statique, il est possible de configurer une fois pour toutes la surveillance et de ne plus s'en pr\u00e9occuper.<\/p>\n
<\/p>\n
Mais si nous avons plusieurs clusters, ou si quelque chose change constamment, le processus devient dynamique. Et s'occuper en permanence de la reconfiguration de la surveillance est une perte de ressources et de temps, c'est-\u00e0-dire m\u00eame simplement de l'ennui. Il faut automatiser cela. La complexit\u00e9 r\u00e9side pr\u00e9cis\u00e9ment dans la dynamique du processus. Et l'op\u00e9rateur l'automatise tr\u00e8s bien. <\/p>\n
<\/p>\n
<\/p>\n
Comment notre cluster a-t-il \u00e9volu\u00e9 ? Au d\u00e9but, il \u00e9tait comme \u00e7a.<\/p>\n
<\/p>\n
<\/p>\n
Ensuite, il est devenu comme \u00e7a.<\/p>\n
<\/p>\n
<\/p>\n
Au final, il est devenu comme \u00e7a. <\/p>\n
<\/p>\n
Et la surveillance est automatiquement effectu\u00e9e par l'op\u00e9rateur. Un point d'entr\u00e9e unique. <\/p>\n
<\/p>\n
<\/p>\n
Nous regardons simplement dans le tableau de bord Grafana pour voir comment la vie de notre cluster s'anime \u00e0 l'int\u00e9rieur. <\/p>\n
<\/p>\n
Au fait, le tableau de bord Grafana est \u00e9galement distribu\u00e9 avec notre op\u00e9rateur directement dans le code source. Vous pouvez le connecter et l'utiliser. Ce screenshot m'a \u00e9t\u00e9 donn\u00e9 par nos DevOps.<\/p>\n
<\/p>\n
<\/p>\n
O\u00f9 voudrions-nous avancer ? C'est :<\/p>\n
<\/p>\n
\nD\u00e9velopper l'automatisation des tests. L'objectif principal est le test automatis\u00e9 des nouvelles versions. <\/li>\n Nous voulons \u00e9galement automatiser l'int\u00e9gration avec ZooKeeper. Et nous pr\u00e9voyons de nous int\u00e9grer avec ZooKeeper-operator. C'est-\u00e0-dire qu'un op\u00e9rateur a \u00e9t\u00e9 \u00e9crit pour ZooKeeper et il est logique que les deux op\u00e9rateurs commencent \u00e0 s'int\u00e9grer pour cr\u00e9er une solution plus conviviale. <\/li>\n Nous souhaitons effectuer des contr\u00f4les de sant\u00e9 plus complexes. <\/li>\n En vert, j'ai soulign\u00e9 que nous avons l'h\u00e9ritage des Templates en cours - FAIT, c'est-\u00e0-dire qu'avec la prochaine version de l'op\u00e9rateur, nous aurons d\u00e9j\u00e0 l'h\u00e9ritage des mod\u00e8les. C'est un outil puissant qui permet de construire des configurations complexes \u00e0 partir de morceaux. <\/li>\n Et nous voulons automatiser des t\u00e2ches complexes. La principale est le Re-sharding. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Faisons le point interm\u00e9diaire. <\/p>\n
<\/p>\n
<\/p>\n
Qu'obtenons-nous \u00e0 la sortie ? Et vaut-il la peine de s'en occuper ou non ? Devons-nous vraiment essayer d'int\u00e9grer la base de donn\u00e9es dans Kubernetes et d'appliquer l'op\u00e9rateur en g\u00e9n\u00e9ral, et l'op\u00e9rateur Alitnity en particulier ?<\/p>\n
<\/p>\n
\u00c0 la sortie, nous obtenons :<\/p>\n
<\/p>\n
\nUne simplification significative et une automatisation de la configuration, du d\u00e9ploiement, ainsi que du support. <\/li>\n Surveillance int\u00e9gr\u00e9e imm\u00e9diatement. <\/li>\n Et des mod\u00e8les codifi\u00e9s pr\u00eats \u00e0 l'emploi pour des situations complexes. Il n'est plus n\u00e9cessaire d'ajouter une r\u00e9plique manuellement. Cela est g\u00e9r\u00e9 par l'op\u00e9rateur. <\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Il reste une derni\u00e8re question. Nous avons d\u00e9j\u00e0 une base de donn\u00e9es dans Kubernetes, de la virtualisation. Quelle est la performance de cette solution, surtout en tenant compte du fait que ClickHouse est optimis\u00e9 pour la performance ?<\/p>\n
<\/p>\n
La r\u00e9ponse - tout est normal ! Je ne vais pas d\u00e9tailler cela, c'est un sujet pour une pr\u00e9sentation s\u00e9par\u00e9e. <\/p>\n
<\/p>\n
<\/p>\n
Mais il existe un projet, appel\u00e9 TSBS. Quel est son objectif principal ? C'est un test de bases de donn\u00e9es pour la performance. C'est une tentative de comparer le chaud avec le chaud, le doux avec le doux. <\/p>\n
<\/p>\n
Comment cela fonctionne-t-il ? Un ensemble de donn\u00e9es est g\u00e9n\u00e9r\u00e9. Ensuite, cet ensemble de donn\u00e9es est ex\u00e9cut\u00e9 sur le m\u00eame ensemble de tests sur diff\u00e9rentes bases de donn\u00e9es. Chaque base de donn\u00e9es r\u00e9sout un probl\u00e8me comme elle sait le faire. Et ensuite, les r\u00e9sultats peuvent \u00eatre compar\u00e9s. <\/p>\n
<\/p>\n
Il prend d\u00e9j\u00e0 en charge un grand nombre de bases de donn\u00e9es. J'ai mis en avant trois principales. Ce sont :<\/p>\n
<\/p>\n
\nTimescaleDB.<\/li>\n InfluxDB.<\/li>\n ClickHouse.<\/li>\n<\/ul>\n<\/p>\n
<\/p>\n
Une comparaison a \u00e9galement \u00e9t\u00e9 men\u00e9e avec une autre solution similaire. Une comparaison avec RedShift. La comparaison a \u00e9t\u00e9 faite sur Amazon. ClickHouse devance \u00e9galement tous dans ce domaine. <\/p>\n
<\/p>\n
<\/p>\n
Que peut-on conclure de ce que je viens de dire ?<\/p>\n
<\/p>\n
\nIl est possible d'utiliser une base de donn\u00e9es dans Kubernetes. Peut-\u00eatre que n'importe quelle base de donn\u00e9es est utilisable, mais globalement, cela semble possible. Il est certainement possible d'utiliser ClickHouse dans Kubernetes gr\u00e2ce \u00e0 notre op\u00e9rateur. <\/li>\n L'op\u00e9rateur aide \u00e0 automatiser les processus et rend la vie vraiment plus simple.<\/li>\n La performance est correcte.<\/li>\n Et il nous semble que cela peut et doit \u00eatre utilis\u00e9. <\/li>\n<\/ul>\n<\/p>\n
Open source \u2013 rejoignez-nous !<\/p>\n
<\/p>\n
Comme je l'ai d\u00e9j\u00e0 mentionn\u00e9, l'op\u00e9rateur est un produit enti\u00e8rement open source, donc ce serait formidable si le plus grand nombre de personnes possible l'utilisait. Rejoignez-nous ! Nous vous attendons tous !<\/p>\n
<\/p>\n
Merci \u00e0 tous !<\/p>\n
<\/p>\n
Questions<\/p>\n
<\/p>\n
<\/p>\n
Merci pour la pr\u00e9sentation ! Je m'appelle Anton. Je viens de l'entreprise SEMrush. Je suis curieux de savoir ce qu'il en est de la journalisation. On entend parler de surveillance, mais pas de journalisation, quand on parle de tout le cluster. Par exemple, nous avons install\u00e9 un cluster sur du mat\u00e9riel. Et nous utilisons la journalisation centralis\u00e9e, en rassemblant les donn\u00e9es avec des outils standard dans un tout commun. Et puis nous en extrayons les donn\u00e9es qui nous int\u00e9ressent.<\/em> <\/p>\n<\/p>\n
C'est une bonne question, c'est-\u00e0-dire que la journalisation figure sur la liste des choses \u00e0 faire. Pour l'instant, notre op\u00e9rateur ne l'automatise pas. Il est encore en d\u00e9veloppement, le projet est encore assez jeune. Nous comprenons la n\u00e9cessit\u00e9 de la journalisation. C'est aussi un sujet tr\u00e8s important. Et il est probablement tout aussi crucial que la surveillance. Mais la surveillance \u00e9tait en t\u00eate de liste pour la mise en \u0153uvre. La journalisation viendra. Nous essayons \u00e9videmment d'automatiser tous les aspects de la vie du cluster. Donc, la r\u00e9ponse est qu'\u00e0 l'heure actuelle, l'op\u00e9rateur ne peut malheureusement pas le faire, mais c'est pr\u00e9vu, nous allons le faire. Si vous avez envie de participer, n'h\u00e9sitez pas \u00e0 faire un pull request.<\/p>\n
<\/p>\n
Bonjour ! Merci pour la pr\u00e9sentation ! J'ai une question standard li\u00e9e aux Persistent Volumes. Lorsque nous cr\u00e9ons une configuration avec cet op\u00e9rateur, comment l'op\u00e9rateur d\u00e9termine-t-il sur quel n\u0153ud un disque ou un dossier est mont\u00e9 ? Devons-nous lui expliquer au pr\u00e9alable, s'il vous pla\u00eet, de placer notre ClickHouse uniquement sur ces n\u0153uds o\u00f9 il y a un disque ?<\/em><\/p>\n<\/p>\n
D'apr\u00e8s ce que je comprends, cette question est une prolongation du stockage local, en particulier de la partie sur hostPath. C'est comme expliquer \u00e0 tout le syst\u00e8me qu'il faut que le pod soit lanc\u00e9 pr\u00e9cis\u00e9ment sur un n\u0153ud o\u00f9 nous avons un disque connect\u00e9s physiquement qui est mont\u00e9 \u00e0 un certain chemin. C'est un sujet que j'ai abord\u00e9 tr\u00e8s superficiellement, car la r\u00e9ponse est assez longue. <\/p>\n
<\/p>\n
En r\u00e9sum\u00e9, cela ressemble \u00e0 ceci. Bien s\u00fbr, nous devons effectuer le provisioning de ces volumes. \u00c0 l'heure actuelle, il n'y a pas de provisioning dynamique dans le stockage local, donc les DevOps doivent d\u00e9couper les disques eux-m\u00eames, ces volumes. Ils doivent expliquer \u00e0 Kubernetes le provisioning, que vous aurez des volumes persistants d'une certaine classe, qui se trouvent sur certains n\u0153uds. Ensuite, il faudra expliquer \u00e0 Kubernetes que les pods qui exigent une certaine classe de stockage local doivent \u00eatre programm\u00e9s uniquement sur certains n\u0153uds selon les labels. Pour ces objectifs, l'op\u00e9rateur a la possibilit\u00e9 d'assigner un certain label et un par instance h\u00f4te. Ainsi, il en r\u00e9sultera que les pods seront rout\u00e9s par Kubernetes pour ne s'ex\u00e9cuter que sur des n\u0153uds r\u00e9pondant aux exigences, en termes de labels, pour parler simplement. Les administrateurs attribuent des labels et effectuent le provisioning des disques manuellement. Ainsi, cela se dimensionne.<\/p>\n
<\/p>\n
Et justement, la troisi\u00e8me option locale aide \u00e0 faciliter cela. Comme je l'ai soulign\u00e9, c'est un travail minutieux de configuration, qui aide \u00e0 obtenir des performances maximales en sortie.<\/p>\n
<\/p>\n
J'ai une deuxi\u00e8me question \u00e0 ce sujet. Kubernetes a \u00e9t\u00e9 con\u00e7u de mani\u00e8re \u00e0 ce que la perte d'un n\u0153ud ne soit pas un probl\u00e8me pour nous. Que faire si nous perdons le n\u0153ud o\u00f9 se trouve notre shard ?<\/em><\/p>\n<\/p>\n
Oui, Kubernetes \u00e9tait initialement positionn\u00e9 de sorte que notre relation avec nos pods soit celle du b\u00e9tail, mais ici, chaque disque devient quelque chose comme un animal de compagnie. Il y a un probl\u00e8me, c'est que nous ne pouvons pas simplement les jeter. L'\u00e9volution de Kubernetes va dans le sens o\u00f9 il n'est pas possible de traiter cela de mani\u00e8re totalement philosophique, comme s'il s'agissait de ressources compl\u00e8tement interchangeables.<\/p>\n
<\/p>\n
Maintenant, une question pratique. Que faire si vous avez perdu le n\u0153ud sur lequel se trouvait le disque ? Ici, le probl\u00e8me doit \u00eatre r\u00e9solu \u00e0 un niveau sup\u00e9rieur. Dans le cas de ClickHouse, nous avons des r\u00e9pliques qui fonctionnent \u00e0 un niveau sup\u00e9rieur, c'est-\u00e0-dire au niveau de ClickHouse.<\/p>\n
<\/p>\n
Quelle est donc la disposition ? C'est \u00e0 DevOps que revient la responsabilit\u00e9 de ne pas perdre les donn\u00e9es. Ils doivent correctement configurer la r\u00e9plication et veiller \u00e0 ce que celle-ci s'ex\u00e9cute. Les donn\u00e9es doivent \u00eatre dupliqu\u00e9es dans la r\u00e9plique au niveau de ClickHouse. Ce n'est pas la t\u00e2che d'un op\u00e9rateur. Et ce n'est pas non plus la t\u00e2che de Kubernetes lui-m\u00eame. C'est au niveau de ClickHouse.<\/p>\n
<\/p>\n
Que faire si vous avez un n\u0153ud physique qui a \u00e9chou\u00e9 ? Il faudra en installer un second, et correctement y provisionner un disque, appliquer des labels. Apr\u00e8s cela, il r\u00e9pondra aux exigences permettant \u00e0 Kubernetes de lancer une instance de pod dessus. Kubernetes l'initialisera. Vous avez en effet un nombre de pods insuffisant pour atteindre l'objectif. Cela passera par le cycle que j'ai montr\u00e9. Et au plus haut niveau, ClickHouse comprendra qu'une r\u00e9plique est entr\u00e9e, qu'elle est encore vide et qu'il faut commencer \u00e0 y transf\u00e9rer des donn\u00e9es. Ce processus est encore mal automatis\u00e9. <\/p>\n
<\/p>\n
Merci pour votre pr\u00e9sentation ! Lorsque des incidents se produisent, que l'op\u00e9rateur tombe et red\u00e9marre, tout en recevant des \u00e9v\u00e9nements, comment traitez-vous cela ?<\/em><\/p>\n<\/p>\n
Que se passe-t-il si l'op\u00e9rateur est tomb\u00e9 et red\u00e9marr\u00e9, n'est-ce pas ? <\/p>\n
<\/p>\n
Oui. Et \u00e0 ce moment-l\u00e0, des \u00e9v\u00e9nements sont apparus.<\/em> <\/p>\n<\/p>\n
La t\u00e2che de g\u00e9rer cette situation est en partie partag\u00e9e entre l'op\u00e9rateur et Kubernetes. Kubernetes a la capacit\u00e9 de rejouer l'\u00e9v\u00e9nement qui s'est produit. Il le rejoue. La t\u00e2che de l'op\u00e9rateur est de s'assurer que lorsque le replay du log d'\u00e9v\u00e9nements est effectu\u00e9, ces \u00e9v\u00e9nements soient idempotents. Ainsi, la r\u00e9p\u00e9tition de la m\u00eame entr\u00e9e d'\u00e9v\u00e9nement ne d\u00e9truira pas notre syst\u00e8me. Et notre op\u00e9rateur g\u00e8re cette t\u00e2che. <\/p>\n
<\/p>\n
Bonjour ! Merci pour votre pr\u00e9sentation ! Dmitry Zavyalov, entreprise<\/em> Smedova. Envisagez-vous d'ajouter la possibilit\u00e9 de configurer l'op\u00e9rateur avec haproxy ? Un autre \u00e9quilibreur de charge en plus de l'option standard serait int\u00e9ressant, pour qu'il soit intelligent et comprenne que c'est v\u00e9ritablement ClickHouse.<\/em> <\/p>\n<\/p>\n
Parlez-vous de Ingress ?<\/p>\n
<\/p>\n
Oui, remplacer Ingress par haproxy. Dans haproxy, vous pouvez sp\u00e9cifier la topologie du cluster, o\u00f9 se trouvent ses r\u00e9pliques.<\/em><\/p>\n<\/p>\n
Pour l'instant, nous n'y avons pas r\u00e9fl\u00e9chi. Si c'est n\u00e9cessaire pour vous et que vous pouvez expliquer pourquoi, nous pourrions le mettre en \u0153uvre, surtout si vous souhaitez participer. Nous examinerons avec plaisir cette option. En r\u00e9sum\u00e9, non, nous n'avons pas cette fonctionnalit\u00e9 actuellement. Merci pour la suggestion, nous y jetterons un \u0153il. Et si vous pouvez aussi expliquer le cas d'utilisation et pourquoi c'est n\u00e9cessaire en pratique, par exemple en cr\u00e9ant des issues sur GitHub, ce serait parfait.<\/p>\n
<\/p>\n
C'est d\u00e9j\u00e0 fait.<\/em><\/p>\n<\/p>\n
Bien. Nous sommes ouverts \u00e0 toutes les propositions. Et haproxy est sur la liste des t\u00e2ches \u00e0 faire. La liste des t\u00e2ches s'allonge, elle ne diminue pas pour l'instant. Mais c'est une bonne chose, cela signifie que le produit est demand\u00e9.<\/p>\n
Source : habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0414\u043e\u043a\u043b\u0430\u0434 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430 \u0432 Kubernetes, \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044e \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u0438 \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u0445 \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u043e\u0432 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c: \u0447\u0442\u043e \u0442\u0430\u043a\u043e\u0435 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0432 Kubernetes \u0438 \u0437\u0430\u0447\u0435\u043c \u043e\u043d \u043d\u0443\u0436\u0435\u043d; \u043a\u0430\u043a \u0438\u043c\u0435\u043d\u043d\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u0443\u043f\u0440\u043e\u0449\u0430\u0435\u0442 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u043c\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c\u0438; \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043c\u043e\u0436\u0435\u0442, \u0430 \u0447\u0442\u043e \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440 \u043d\u0435 \u043c\u043e\u0436\u0435\u0442. \u0414\u0430\u043b\u0435\u0435, \u043f\u0435\u0440\u0435\u0439\u0434\u0451\u043c \u043a \u043e\u0431\u0441\u0443\u0436\u0434\u0435\u043d\u0438\u044e \u0432\u043d\u0443\u0442\u0440\u0435\u043d\u043d\u0435\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430. \u0420\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0443 \u0438 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":96966,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-96965","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Op\u00e9rateur](\"\/wp-content\/uploads\/2020\/10\/56e002c7408c4708e39ece867f84171e.jpeg\")
<\/p>\n