Mardi Postgres n°5 : « PostgreSQL et Kubernetes. CI/CD. Automatisation des tests »

À la fin de l'année dernière, un autre direct de la communauté PostgreSQL russe a eu lieu #RuPostgres, au cours duquel son cofondateur, Nikolai Samokhvalov, a discuté avec le directeur technique de « Flanta », Dmitri Stolyarov, de cette SGBD dans le contexte de Kubernetes.

Nous publions le compte rendu de la partie principale de cette discussion, et sur la chaîne YouTube de la communauté la vidéo complète a été publiée :

Bases de données et Kubernetes

NS: Nous ne parlerons pas aujourd'hui de VACUUM et des CHECKPOINTS. Nous voulons discuter de Kubernetes. Je sais que tu as déjà beaucoup d'expérience. J'ai regardé tes vidéos et même revisité certains extraits... Allons droit au but : pourquoi utiliser Postgres ou MySQL dans K8s ?

DS: Il n'y a pas de réponse unique à cette question, et il n'y en aura jamais. Mais en gros, il s'agit de simplicité et de commodité... potentielles. Tout le monde souhaite des services gérés.

NS: Pour avoir RDS, uniquement chez soi ?

DS: Oui : pour avoir RDS, mais où que ce soit.

NS: « Où que ce soit » — c'est un bon point. Dans les grandes entreprises, tout est situé à différents endroits. Et pourquoi, si c'est une grande entreprise, ne pas prendre une solution prête à l'emploi ? Par exemple, Nutanix a ses propres développements, d'autres entreprises (VMware…) proposent le même « RDS, mais chez soi ».

DS: Mais cela concerne une mise en œuvre spécifique, qui ne fonctionnera que dans certaines conditions. Et quand il s'agit de Kubernetes, il y a une énorme diversité d'infrastructures (qui peuvent être dans K8s). En essence, c'est une norme pour l'API du cloud...

NS: Et c'est même gratuit !

DS: Ce n'est pas si important. La gratuité est importante pour un segment de marché qui n'est pas si grand. Ce qui est essentiel, c'est autre chose... Tu te souviens probablement de la présentation «Bases de données et Kubernetes»?

NS: Oui.

DS: J'ai compris que cela a été perçu de manière très ambiguë. Une partie des gens a pensé que je disais : « Les gars, allons mettre toutes les bases de données dans Kubernetes ! », tandis que d'autres ont décidé que ce n'était que des bicyclettes terribles. Mais ce que je voulais réellement dire, c'est : « Regardez ce qui se passe, quels problèmes existent et comment les résoudre. Est-ce qu'il faut aller vers les bases dans Kubernetes ? En production ? Eh bien, seulement si vous aimez... vous engager dans certaines choses. Mais pour le développement, je peux dire que je recommande. Pour le développement, la dynamique de création/suppression des environnements est très importante ».

NS : Par développement, tu entends tous les environnements qui ne sont pas prod ? Staging, QA…

DS: Si l'on parle des perf-stands, il n'y en a probablement plus, car les exigences sont spécifiques. Si l'on parle de cas particuliers où une très grande base de données est nécessaire en staging, c'est aussi probablement non… Si c'est un environnement statique, de longue durée, quel est l'avantage d'avoir la base dans K8s ?

NS: Aucun. Mais où voyons-nous des environnements statiques ? L'environnement statique est déjà obsolète.

DS: Le staging peut être statique. Nous avons des clients…

NS: Oui, j'en ai aussi. C'est un gros problème si vous avez une base de 10 To et que le staging n'est que de 200 Go…

DS: J'ai un cas très intéressant ! Dans le staging se trouve la base de production, à laquelle on apporte des modifications. Et il y a un bouton : « déployer en production ». Ces modifications — les deltas — sont ajoutées (il semble qu'elles soient simplement synchronisées via l'API) à la production. C'est une option très exotique.

NS: J'ai vu des startups dans la vallée qui utilisent RDS ou même encore Heroku — c'est des histoires de 2-3 ans — et elles téléchargent des dumps sur leur portable. Parce que la base n'est que de 80 Go, et qu'il y a de la place sur le portable. Ensuite, elles achètent des disques à chacun pour avoir 3 bases afin de mener différents développements. Ça arrive aussi. J'ai aussi vu qu'elles n'hésitent pas à copier la prod en staging — cela dépend beaucoup de la société. Mais j'ai aussi vu qu'elles ont très peur, et qu'il y a souvent un manque de temps et de ressources. Mais avant de passer à ce sujet, j'aimerais entendre parler de Kubernetes. Ai-je bien compris qu'il n'y en a pour l'instant nulle part en prod ?

DS: Nous avons de petites bases en prod. Il s'agit de volumes de dizaines de gigaoctets et de services non critiques, pour lesquels il était fastidieux de créer des répliques (et il n'y a pas vraiment de besoin). Et à condition qu'il y ait un bon stockage sous Kubernetes. Cette base fonctionnait sur une machine virtuelle — supposons sous VMware, au-dessus de SAN. Nous l'avons placée dans PV et maintenant nous pouvons la transférer d'une machine à l'autre.

NS: Des bases de cette taille, jusqu'à 100 Go, sur de bons disques et avec un bon réseau, peuvent être installées en quelques minutes, n'est-ce pas ? Une vitesse de 1 Go par seconde, ce n'est plus une exotique.

DS: Oui, pour une opération linéaire, ce n'est pas un problème.

NS: D'accord, pour la prod, nous devons seulement réfléchir. Et si nous envisageons Kubernetes pour des environnements non-prod — comment faire ? Je vois que chez Zalando ils créent un opérateur, chez Crunchy ils développent, il y a encore d'autres options. Et il y a OnGres — c'est notre bon ami Alvaro d'Espagne : ils font en fait pas seulement un opérateur, mais une distribution entière (StackGres), dans lequel en plus de Postgres lui-même, un backup a également été intégré, le proxy Envoy…

DS: À quoi sert Envoy ? Pour l'équilibrage de la charge du trafic Postgres ?

NS: Oui. Donc, ils le voient comme : si l'on prend une distribution Linux et le noyau, alors PostgreSQL classique est le noyau, et ils veulent créer une distribution qui sera conviviale pour le cloud et fonctionnera sur Kubernetes. Ils assemblent des composants (backups, etc.) et les peaufinent pour qu'ils fonctionnent bien.

DS: C'est vraiment génial ! En gros, c'est un logiciel pour créer son propre Postgres géré.

NS: Les distributions Linux ont toujours des problèmes : comment faire des pilotes pour que tout le matériel soit supporté. Leur idée est qu'ils vont fonctionner sur Kubernetes. Je sais que dans l'opérateur Zalando, nous avons récemment vu une connexion à AWS, et ce n'est pas très bien. Il ne devrait pas y avoir de lien avec une infrastructure spécifique - quel est alors le sens ?

DS: Je ne sais pas dans quelle situation Zalando est lié, mais dans Kubernetes, le stockage est fait de telle manière qu'il n'est pas possible de faire un backup de disque de manière générique. Récemment, dans la norme - dans la dernière version de la spécification CSI — la possibilité de snapshots a été ajoutée, mais où est-elle implémentée ? Honnêtement, c'est encore tellement embryonnaire… Nous essayons CSI sur AWS, GCE, Azure, vSphere, mais dès que l'on commence à l'utiliser, on voit que ce n'est pas encore prêt.

NS: C'est pourquoi il faut parfois s'appuyer sur l'infrastructure. Je pense que cela reste une phase précoce - des problèmes de croissance. Question : quels conseils donnerais-tu aux débutants qui veulent essayer PgSQL dans K8s ? Quel opérateur peut-être ?

DS: Le problème, c'est que Postgres représente pour nous 3%. Nous avons aussi une très grande liste de différents logiciels dans Kubernetes, je ne vais même pas tout énumérer. Par exemple, Elasticsearch. Il y a une multitude d'opérateurs : certains se développent activement, d'autres non. Nous avons établi nos exigences sur ce qui doit être dans un opérateur pour que nous le prenions au sérieux. Dans l'opérateur uniquement pour Kubernetes - pas dans « un opérateur pour faire quelque chose dans des conditions spécifiques à Amazon »… En réalité, nous utilisons assez massivement (= presque tous nos clients) un seul opérateur - pour Redis (nous publierons bientôt un article à ce sujet).

NS: Et pour MySQL, il n'y en a pas non plus ? Je sais que Percona… étant donné qu'ils s'occupent désormais aussi de MySQL, MongoDB et Postgres, ils devront en créer un universel : pour toutes les bases, pour tous les fournisseurs cloud.

DS: Nous n'avons pas eu le temps de nous pencher sur les opérateurs pour MySQL. Ce n'est pas notre priorité actuelle. MySQL fonctionne bien en mode autonome. Pourquoi un opérateur, si tu peux simplement lancer la base de données… Tu peux lancer un conteneur Docker avec Postgres, ou le lancer simplement.

NS: C'était aussi une question. En fait, sans opérateur ?

DS: Oui, à 100% nous avons PostgreSQL fonctionnant sans opérateur. Pour l'instant, c'est comme ça. Nous utilisons activement un opérateur pour Prometheus et pour Redis. Nous prévoyons de trouver un opérateur pour Elasticsearch — c'est le plus urgent, car nous souhaitons l'installer dans 100% des cas sous Kubernetes. De même, nous voulons arriver à installer MongoDB aussi systématiquement sous Kubernetes. Il y a certaines attentes — on a l'impression qu'il y a des choses à réaliser dans ces cas. Quant à Postgres, nous ne nous sommes même pas penchés dessus. Bien sûr, nous savons qu'il existe différentes options, mais en fait, nous fonctionnons en autonome.

Base de données pour les tests dans Kubernetes

NS: Passons au sujet des tests. Comment déployer les modifications dans la base — du point de vue DevOps. Il y a des microservices, beaucoup de bases, et il y a tout le temps des changements. Comment assurer un CI/CD normal, pour que du point de vue SGBD tout soit en ordre. Quelle est ton approche ?

DS: Il ne peut pas y avoir une seule réponse. Il y a plusieurs paramètres. Le premier — c'est la taille de la base que nous souhaitons déployer. Tu as toi-même mentionné que les entreprises ont des attitudes différentes vis-à-vis de la nécessité d'avoir une copie de la base de prod sur dev et stage.

NS: Et dans le cadre du RGPD, je pense qu'ils y font de plus en plus attention… Je peux dire qu'en Europe, ils ont déjà commencé à infliger des amendes.

DS: Mais souvent, on peut écrire un logiciel qui effectue un dump à partir de la production et qui l'obfusque. On obtient des données de prod (snapshot, dump, copie binaire…), mais elles sont anonymisées. Il peut aussi y avoir des scripts de génération : cela peut être des fixtures ou simplement un script qui génère une grande base. Le problème, c'est combien de temps il faut pour créer l'image de base ? Et combien de temps faut-il pour la déployer dans l'environnement souhaité ?

Nous sommes arrivés à un schéma : si le client a un ensemble de données de fixtures (version minimale de la base), nous les utilisons par défaut. Si nous parlons d'environnements de revue, lorsqu'on a créé une branche, un exemplaire de l'application a été déployé — nous y déployons une petite base. Mais cela a bien fonctionné et une variante, lorsque nous effectuons une sauvegarde du production une fois par jour (la nuit) et que nous construisons un conteneur Docker avec PostgreSQL et MySQL en utilisant ces données chargées. Si nous devons déployer cette base 50 fois à partir de cette image, cela se fait simplement et rapidement.

NS: Par simple copie ?

DS: Les données sont directement stockées dans l'image Docker. C'est-à-dire que nous avons une image prête, disons de 100 Go. Grâce aux couches dans Docker, nous pouvons déployer cette image le nombre de fois nécessaire, rapidement. C'est une méthode basique, mais qui fonctionne bien.

NS: Ensuite, quand vous testez, cela change directement dans Docker, n'est-ce pas ? Copy-on-write à l'intérieur de Docker — nous le supprimons et recommençons, tout est parfait. Génial ! Et vous l'utilisez déjà pleinement ?

DS: Depuis longtemps.

NS: Nous faisons des choses très similaires. Sauf que nous n'utilisons pas le copy-on-write de Docker, mais quelque chose d'autre.

DS: Ce n'est pas générique. Mais celui de Docker fonctionne partout.

NS: En théorie, oui. Mais nous avons aussi des modules là-bas, nous pouvons créer différents modules et travailler avec différents systèmes de fichiers. Voici le point. Nous regardons tout cela du côté de Postgres. Maintenant, j'ai regardé du côté Docker et j'ai vu que tout fonctionne pour vous. Mais si la base est énorme, par exemple 1 To, alors cela devient long : que ce soit les opérations de nuit ou pour intégrer tout ça dans Docker... Et si c'est 5 To à intégrer dans Docker… Ou tout va bien ?

DS: Quelle est la différence ? Ce ne sont que des blobs, juste des bits et des octets.

NS: La différence est : vous le faites via dump et restore ?

DS: Ce n'est pas du tout nécessaire. Les méthodes de génération de cette image peuvent être variées.

NS: Pour certains clients, nous avons fait en sorte qu'au lieu de générer régulièrement l'image de base, nous la maintenons constamment à jour. Elle est en fait une réplique, mais les données ne proviennent pas directement du maître, mais par le biais d'un archive. Une archive binaire, où les WAL sont appliqués chaque jour, des sauvegardes sont également prises… Ces WAL arrivent ensuite — avec un léger retard (à peine 1-2 secondes) — à l'image de base. Nous clonons à partir de là de n'importe quelle manière — en ce moment, nous utilisons par défaut ZFS.

DS: Mais avec ZFS, vous êtes limité à un seul nœud.

NS: Oui. Mais ZFS a aussi un aspect magique send: avec lequel vous pouvez envoyer un snapshot et même (je ne l'ai pas encore beaucoup testé, mais…) vous pouvez envoyer la delta entre deux PGDATA. En réalité, nous avons aussi un autre outil que nous n'avons pas vraiment envisagé pour ces tâches. Postgres a pg_rewind, fonctionnant comme un rsync « intelligent », évitant beaucoup de ce qui peut ne pas être examiné, car il n'y a certainement rien qui a changé. Nous pouvons réaliser une synchronisation rapide entre deux serveurs et revenir en arrière de la même manière.

Ainsi, nous essayons de créer un outil de cette manière, plus côté DBA, qui permet de faire ce dont tu parlais : nous avons une base, mais nous voulons tester quelque chose 50 fois, presque simultanément.

DS: 50 fois signifie que vous devez commander 50 instances Spot.

NS: Non, tout se fait sur une seule machine.

DS: Mais comment allez-vous déployer 50 fois, si cette base unique, disons, fait un téraoctet. Elle a probablement besoin de, disons, 256 Go de RAM ?

NS: Oui, parfois il faut beaucoup de mémoire — c'est normal. Mais un exemple de la vie réelle. Sur la machine de production, il y a 96 cœurs et 600 Go. Alors que pour la base de données, 32 cœurs sont utilisés (voire parfois 16 cœurs maintenant) et 100-120 Go de mémoire.

DS: Et vous y mettez 50 copies ?

NS: Donc, la copie est unique, ensuite fonctionne le copy-on-write (ZFS)... Je vais expliquer plus en détail.

Par exemple, nous avons une base de 10 To. Nous avons créé un disque pour elle, ZFS a déjà compressé sa taille de 30-40 %. Puisque nous ne faisons pas de tests de charge, le temps de réponse exact n'est pas important pour nous : il peut être jusqu'à 2 fois plus lent — c'est acceptable.

Nous permettons aux développeurs, aux QA, aux DBA, etc., de faire des tests en 1-2 flux. Par exemple, ils peuvent lancer une migration. Cela ne nécessite pas immédiatement 10 cœurs — il lui faut 1 backend PostgreSQL, 1 cœur. La migration va démarrer — peut-être que l'autovacuum va démarrer aussi, alors le deuxième cœur sera utilisé. Nous avons alloué 16-32 cœurs, donc 10 personnes peuvent travailler en même temps, il n'y a pas de problème.

Puisque physiquement PGDATA identique, il se trouve que nous trompons finalement PostgreSQL. L'idée est la suivante : par exemple, 10 PostgreSQL démarrent en même temps. Quel est généralement le problème ? Ils sont configurés shared_buffers, disons, à 25 %. En conséquence, cela représente 200 Go. Plus de trois de tels systèmes ne peuvent plus être lancés, car la mémoire va manquer.

Mais à un moment donné, nous avons compris que ce n'était pas nécessaire : nous configurons shared_buffers à 2 Go. PostgreSQL a effective_cache_size, et en réalité, c'est le seul qui influence les plans. Nous le réglons à 0,5 To. Et il n'est même pas important qu'il n'y en ait pas réellement : il construit des plans comme s'il y en avait.

Ainsi, lorsque nous testons une migration, nous pouvons collecter tous les plans — nous verrons comment cela se déroulera en production. Les secondes seront différentes (plus lentes), mais les données que nous lisons réellement, ainsi que les plans (les JOIN et autres) restent exactement les mêmes qu'en production. De plus, nous pouvons effectuer de nombreux tests simultanément sur une seule machine.

DS: Ne penses-tu pas qu'il y a plusieurs problèmes ici ? Le premier — c'est une solution qui ne fonctionne que sur PostgreSQL. Cette approche est très spécifique, elle n'est pas générique. Le deuxième — Kubernetes (et tout ce vers quoi vont les technologies cloud) implique de nombreux nœuds, et ces nœuds sont éphémères. Dans ton cas, il s'agit d'un nœud stateful, persistant. Ces aspects me posent des contradictions.

NS: D'abord, je suis d'accord, c'est une histoire purement Postgres. Je pense que si nous avons un I/O direct et un pool de mémoire tampon presque complet, cette approche ne fonctionnera pas — les plans seront différents. Mais pour l'instant, nous travaillons seulement avec Postgres, sans penser aux autres.

Concernant Kubernetes. Tu racontes partout que notre base est persistante. Si une instance plante, l'essentiel est de sauvegarder le disque. Notre plateforme repose également sur Kubernetes, tandis que le composant avec Postgres est séparé (bien qu'il y figure un jour). Donc, c'est comme ça : l'instance est tombée, mais nous avons conservé son PV et l'avons simplement connecté à une autre (nouvelle) instance, comme si rien ne s'était passé.

DS: De mon point de vue, nous créons des pods dans Kubernetes. K8s est élastique : les nœuds sont commandés au besoin. L'objectif est simplement de créer un pod et de dire qu'il a besoin de X ressources, et ensuite K8s gère le reste. Mais la prise en charge du stockage dans Kubernetes reste instable : dans 1.16, sur 1.17 (cette version a été publiée il y a une semaine ) ces fonctionnalités sont encore en bêta.

Dans six mois à un an, cela deviendra plus ou moins stable, ou du moins ce sera annoncé comme tel. À ce moment-là, la possibilité de snapshots et de redimensionnement résoudra complètement votre problème. Parce que vous avez une base. Oui, elle peut ne pas être très rapide, mais la vitesse dépend de ce qui se trouve « sous le capot », car certaines implémentations savent faire la copie et le copy-on-write au niveau du sous-système de stockage.

NS: Il faut aussi que tous les moteurs (Amazon, Google…) commencent à prendre en charge cette version — cela prend aussi un certain temps.

DS: Pour l'instant, nous ne les utilisons pas. Nous utilisons les nôtres.

Développement local sous Kubernetes

NS: As-tu déjà eu ce besoin de déployer tous les pods sur une seule machine pour faire un petit test ? Pour rapidement obtenir une preuve de concept et voir si l'application fonctionne dans Kubernetes sans allouer plein de machines pour cela. Il y a Minikube, non ?

DS: Je pense que ce cas — de déployer sur un seul nœud — concerne exclusivement le développement local. Ou certaines manifestations d'un tel modèle. Il y a Minikube, il y a k3s, KIND. Nous allons utiliser Kubernetes IN Docker. Nous avons commencé à travailler avec ça pour des tests.

NS: Je pensais auparavant que c'était une tentative d'envelopper tous les pods dans une seule image Docker. Mais il s'avère que c'est tout à fait autre chose. Il y a toujours des conteneurs séparés, des pods séparés — juste dans Docker.

DS: Oui. Il y a une imitation assez amusante, mais le sens est tel… Nous avons un utilitaire pour le déploiement — werf. Nous voulons y inclure un mode — disons werf up: «Démarre-moi un Kubernetes local». Et ensuite lancer un werf follow. Ainsi, le développeur pourra coder dans son IDE, tandis qu'un processus s'exécute dans le système, qui voit les modifications et reconstruit les images, les redéploie dans le K8s local. C'est ainsi que nous voulons essayer de résoudre le problème du développement local.

Snapshots et clonage de bases de données dans le cadre de K8s

NS: Si l'on revient au copy-on-write. J'ai remarqué que les clouds ont aussi des snapshots. Ils fonctionnent différemment. Par exemple, dans GCP : tu as une instance de plusieurs téraoctets sur la côte est des États-Unis. Tu fais périodiquement des snapshots. Tu redémarres une copie de disque à partir du snapshot sur la côte ouest — en quelques minutes, tout est prêt, ça fonctionne très rapidement, il te faut juste remplir le cache en mémoire. Mais ces clones (snapshots) servent à provisioning un nouveau volume. C'est génial quand tu dois créer beaucoup d'instances.

Mais pour des tests, je pense que les snapshots dont tu parles dans Docker ou ceux dont je parle dans ZFS, btrfs et même LVM… — ils permettent justement de ne pas réellement créer de nouvelles données sur une seule machine. Dans le cloud, tu devras encore payer pour cela à chaque fois et attendre non pas des secondes, mais des minutes (et dans le cas de lazy loading, peut-être des heures).

Au lieu de cela, tu peux obtenir ces données en une ou deux secondes, faire tourner un test et les jeter. Ces snapshots résolvent des tâches différentes. Dans le premier cas — pour se scaler et obtenir de nouvelles répliques, et dans le second — pour des tests.

DS: Je ne suis pas d'accord. Réaliser correctement le clonage des volumes est une tâche pour le cloud. Je n'ai pas regardé leur implémentation, mais je sais comment nous faisons cela sur le matériel. Nous avons Ceph, on peut dire à n'importe quel volume physique (RBD) et obtenir en quelques dizaines de millisecondes un second volume avec des caractéristiques identiques, clone IOPS etc. Il faut comprendre qu'il y a un copy-on-write complexe en interne. Pourquoi le cloud ne pourrait-il pas faire de même ? Je suis sûr qu'ils essaient de le faire d'une manière ou d'une autre.: Mais ils prendront quand même des secondes, des dizaines de secondes, pour démarrer une instance, faire venir Docker, etc.

NS: Pourquoi est-il nécessaire de démarrer une instance complète ? Nous avons une instance avec 32 cœurs, et une autre avec 16... et elle peut contenir un certain nombre de volumes - par exemple, quatre. Lorsque nous commandons une cinquième, une instance sera déjà lancée, puis elle sera supprimée.

DS: Oui, c'est intéressant, dans Kubernetes cela donne une autre histoire. Notre base de données n'est pas dans K8s, et il y a une instance. Pourtant, le clonage d'une base de données de plusieurs téraoctets prend moins de deux secondes.

NS: C'est génial. Mais mon point de départ est que ce n'est pas une solution générique. Oui, c'est super, mais cela convient uniquement à Postgres et seulement sur un nœud.

DS: Ce n'est pas seulement pour Postgres : les plans, comme je l'ai décrit, fonctionneront ainsi uniquement en son sein. Mais si nous ne nous préoccupons pas des plans, mais avons simplement besoin de toutes les données pour des tests fonctionnels, alors cela conviendra à n'importe quel SGBD.

NS: Il y a de nombreuses années, nous avons fait quelque chose de similaire avec des snapshots LVM. C'est classique. Cette approche a été utilisée très activement. Les nœuds état-plein sont vraiment un défi. Parce qu'il faut les faire fonctionner sans interruption, toujours se souvenir d'eux...

DS: Ne vois-tu pas ici une possibilité de hybridation ? Disons qu'un état-plein est un pod, il fonctionne pour plusieurs utilisateurs (beaucoup de testeurs). Nous avons un seul volume, mais grâce au système de fichiers, les clones sont locaux. Si le pod tombe, le disque reste ; le pod se relèvera, l'information sur tous les clones sera lue, tout sera remis en place et il dira : « Voici vos clones lancés sur ces ports, travaillez avec eux ».

NS: Techniquement, cela signifie qu'au sein de Kubernetes c'est un pod, à l'intérieur duquel nous lançons plusieurs Postgres.

DS: Oui. Il a une limite : disons que pas plus de 10 personnes peuvent y travailler en même temps. Si 20 s'avèrent nécessaires, nous lancerons un second pod identique. Il est tout à fait possible de le cloner complètement, obtenant un second volume complet, avec les mêmes 10 clones 'minces'. Ne vois-tu pas cette possibilité ?

NS: Oui. Il a une limite : disons que pas plus de 10 personnes peuvent y travailler en même temps. Si 20 s'avèrent nécessaires, nous lancerons un second pod identique. Il est tout à fait possible de le cloner complètement, obtenant un second volume complet, avec les mêmes 10 clones 'minces'. Ne vois-tu pas cette possibilité ?

DS: Il faut ajouter ici des questions de sécurité. Ce type d’organisation implique que ce pod a de hauts privilèges (capabilities), car il peut effectuer des opérations non standard sur le système de fichiers... Mais je le répète : je pense qu'à moyen terme, Kubernetes corrigera le stockage, et dans le cloud, ils régleront toute l'histoire avec les volumes – tout fonctionnera « simplement ». Il y aura resize, clonage... Il y a un volume – nous disons : « Crée un nouveau à partir de celui-ci », – et en une seconde et demie, nous obtenons ce qu'il faut.

NS: Je ne crois pas qu’une seconde et demie soit réalisable pour de nombreux téraoctets. Sur Ceph, tu le fais toi-même, mais tu parles des clouds. Va dans le cloud, fais un clone d'un volume EBS de plusieurs téraoctets sur EC2 et regarde quelle sera la performance. Cela ne prendra pas quelques secondes. Cela m’intéresse beaucoup de savoir quand ils atteindront ce résultat. Je comprends de quoi tu parles, mais je me permets de ne pas être d'accord.

DS: D'accord, mais j'ai dit que c'était à moyen terme, pas à court terme. Dans quelques années.

À propos de l’opérateur PostgreSQL de Zalando

Au milieu de cette réunion, Alexey Klyukin, un ancien développeur de Zalando, a également rejoint la discussion et a parlé de l'histoire de l'opérateur PostgreSQL :

C'est génial que ce sujet soit abordé : Postgres et Kubernetes. Quand nous avons commencé à le développer chez Zalando en 2017, c'était un sujet que tout le monde voulait explorer, mais personne ne s'y mettait. Tout le monde avait déjà Kubernetes, mais quand on demandait comment gérer les bases de données, même des gens comme Kelsey Hightower, prônant Kubernetes, disaient à peu près ceci :

« Allez vers des services gérés et utilisez-les, ne lancez pas de BD dans Kubernetes. Sinon, votre K8s décidera, par exemple, de faire une mise à niveau, éteindra tous les nœuds et vos données s'échapperont très loin. »

Nous avons décidé de créer un opérateur qui, contrairement à ce conseil, lancerait la base de données Postgres dans Kubernetes. Et nous avions de bonnes raisons – Patroni. C'est un failover automatique pour PostgreSQL, fait correctement, c'est-à-dire utilisant etcd, consul ou ZooKeeper comme stockage d'informations sur le cluster. Un tel stockage, qui fournira à tous ceux qui le demandent, par exemple, quelle est actuellement le leader, la même information – même si nous sommes tout distribués – afin d'éviter le split brain. De plus, nous avions un Docker image pour cela.

En fait, le besoin de basculement automatique est apparu pour l'entreprise après la migration d'un centre de données interne vers le cloud. Le cloud était basé sur une solution PaaS (Platform-as-a-Service) développée en interne. C'est une solution Open Source, mais pour la mettre en place, il fallait beaucoup travailler. Elle s'appelait STUPS.

Au départ, il n'y avait pas de Kubernetes. En fait, lorsque la solution a été déployée, K8s existait déjà, mais elle était tellement immature qu'elle n'était pas prête pour la production. C'était, je pense, en 2015 ou 2016. En 2017, Kubernetes était devenu relativement mature — il y avait un besoin de migration là-bas.

Et nous avions déjà un conteneur Docker. Il y avait une PaaS qui utilisait Docker. Pourquoi ne pas essayer K8s ? Pourquoi ne pas écrire notre propre opérateur ? Murat Kabilov, qui est venu nous rejoindre depuis Avito, a commencé cela par ses propres initiatives - « juste pour jouer », - et le projet a « décollé ».

Mais en fait, je voulais parler d'AWS. Pourquoi il y avait historiquement du code lié à AWS…

Lorsque vous lancez quoi que ce soit dans Kubernetes, il faut comprendre que K8s est un travail en cours. Il évolue constamment, s'améliore et, parfois, même se casse. Il faut suivre de près tous les changements dans Kubernetes, être prêt à plonger dedans et à comprendre comment cela fonctionne en détail — peut-être plus que vous ne le souhaiteriez. C'est en principe le cas pour toute plateforme sur laquelle vous exécutez vos bases de données…

Alors, lorsque nous avons créé l'opérateur, nous avions Postgres qui fonctionnait avec un volume externe (dans ce cas, EBS, puisque nous travaillions dans AWS). La base de données a grandi, et à un moment donné, il a fallu faire un redimensionnement : par exemple, la taille initiale de l'EBS était de 100 To, la base a atteint cette taille, maintenant nous voulons faire un EBS de 200 To. Comment ? Supposons que l'on puisse faire un dump/restauration sur une nouvelle instance, mais c'est long et entraîne un temps d'arrêt.

C'est pourquoi nous souhaitions un redimensionnement qui augmenterait la partition de l'EBS puis dirait au système de fichiers d'utiliser le nouvel espace. Et nous l'avons fait, mais à l'époque, Kubernetes n'avait aucune API pour l'opération de redimensionnement. Comme nous travaillions sur AWS, nous avons écrit du code pour son API.

Personne n'empêche de faire la même chose pour d'autres plateformes. L'opérateur n'est pas limité à être exécuté uniquement sur AWS, il fonctionnera ailleurs également. En gros, c'est un projet Open Source : si quelqu'un veut accélérer l'apparition de l'utilisation d'une nouvelle API — vous êtes le bienvenu. Il y a GitHub, les pull requests — l'équipe de Zalando s'efforce d'y répondre assez rapidement et de promouvoir l'opérateur. D'après ce que je sais, le projet a participé au Google Summer of Code et à d'autres initiatives similaires. Zalando travaille très activement dessus.

P.S. Bonus !

Si vous êtes intéressé par le sujet de PostgreSQL et Kubernetes, nous attirons également votre attention sur le fait que la semaine dernière a eu lieu le prochain Postgres Tuesday, où Nikolai a échangé avec Alexandre Kukushkin de Zalando. La vidéo est disponible ici.

P.P.S.

Lisez aussi dans notre blog :

• «Bases de données et Kubernetes (aperçu et vidéo de la présentation)»;
• «Migration de Cassandra vers Kubernetes : caractéristiques et solutions»;
• «Migration complexe de MongoDB vers Kubernetes.»;
• «Migration sans tracas de RabbitMQ vers Kubernetes».

Source : habr.com