🥇Postgres Tuesday #5 : « PostgreSQL et Kubernetes. CI/CD. Automatisation des tests»

À la fin de l'année dernière, une autre diffusion en direct de la communauté russe PostgreSQL a eu lieu #RuPostgres, au cours de laquelle son co-fondateur Nikolai Samokhvalov s'est entretenu avec le directeur technique de Flant, Dmitry Stolyarov, à propos de ce SGBD dans le contexte de Kubernetes.

Nous publions une transcription de la partie principale de cette discussion, et à Chaîne YouTube communautaire Vidéo complète postée :

Bases de données et Kubernetes

NA: Nous ne parlerons pas de VACUUM et de CHECKPOINTs aujourd'hui. Nous voulons parler de Kubernetes. Je sais que vous avez de nombreuses années d'expérience. J'ai regardé vos vidéos et même revu certaines d'entre elles... Allons droit au but : pourquoi Postgres ou MySQL dans K8 ?

DS: Il n’y a pas et ne peut pas y avoir de réponse définitive à cette question. Mais en général, c'est la simplicité et la commodité... le potentiel. Tout le monde veut des services gérés.

NA: À comment RDS, seulement à la maison ?

DS: Oui : comme RDS, n'importe où.

NA: « N'importe où » est un bon point. Dans les grandes entreprises, tout est situé à des endroits différents. Pourquoi alors, s’il s’agit d’une grande entreprise, ne pas adopter une solution toute faite ? Par exemple, Nutanix a ses propres développements, d'autres sociétés (VMware...) ont le même « RDS, uniquement chez soi ».

DS: Mais nous parlons d'une implémentation distincte qui ne fonctionnera que sous certaines conditions. Et si nous parlons de Kubernetes, alors il existe une grande variété d'infrastructures (qui peuvent être dans les K8). Il s'agit essentiellement d'une norme pour les API vers le cloud...

NA: C'est aussi gratuit !

DS: Ce n'est pas si important. La gratuité est importante pour un segment pas très important du marché. Autre chose est important... Vous vous souvenez probablement du reportage «Bases de données et Kubernetes"?

NA: Oui

DS: J'ai réalisé qu'il avait été reçu de manière très ambiguë. Certains pensaient que je disais : « Les gars, mettons toutes les bases de données dans Kubernetes ! », tandis que d’autres pensaient que ce n’étaient que de terribles vélos. Mais je voulais dire quelque chose de complètement différent : « Regardez ce qui se passe, quels sont les problèmes et comment ils peuvent être résolus. Devons-nous utiliser les bases de données Kubernetes maintenant ? Production? Enfin, seulement si tu aimes... faire certaines choses. Mais pour un développeur, je peux dire que je le recommande. Pour un développeur, le dynamisme de création/suppression d’environnements est très important.

NS : Par dev, vous entendez tous les environnements qui ne sont pas des prod ? Mise en scène, assurance qualité…

DS: Si nous parlons de stands de performance, alors probablement pas, car les exigences y sont spécifiques. Si nous parlons de cas particuliers où une très grande base de données est nécessaire pour la préparation, alors probablement pas... S'il s'agit d'un environnement statique et de longue durée, quel est l'avantage d'avoir la base de données située dans les K8 ?

NA: Aucun. Mais où voyons-nous des environnements statiques ? Un environnement statique deviendra obsolète demain.

DS: La mise en scène peut être statique. Nous avons des clients...

NA: Oui, j'en ai un aussi. C'est un gros problème si vous disposez d'une base de données de 10 To et d'un staging de 200 Go...

DS: J'ai un cas très cool ! Lors de la préparation, il existe une base de données de produits dans laquelle les modifications sont apportées. Et il y a un bouton : « déployer en production ». Ces changements - les deltas - sont ajoutés (il semble qu'ils soient simplement synchronisés via l'API) en production. C'est une option très exotique.

NA: J'ai vu des startups dans la Valley qui sont assises dans RDS ou même dans Heroku - ce sont des histoires d'il y a 2-3 ans - et elles téléchargent le dump sur leur ordinateur portable. Parce que la base de données ne fait encore que 80 Go et qu'il y a de la place sur l'ordinateur portable. Ensuite ils achètent des disques supplémentaires pour tout le monde afin de disposer de 3 bases de données pour réaliser différents développements. C’est aussi comme ça que ça se passe. J'ai aussi vu qu'ils n'ont pas peur de copier la production dans la mise en scène - cela dépend beaucoup de l'entreprise. Mais j’ai aussi vu qu’ils ont très peur et qu’ils n’ont souvent pas assez de temps ni de mains. Mais avant de passer à ce sujet, je veux entendre parler de Kubernetes. Ai-je bien compris que personne n'est encore en prod ?

DS: Nous avons de petites bases de données en prod. Nous parlons de volumes de plusieurs dizaines de gigaoctets et de services non critiques pour lesquels nous étions trop paresseux pour faire des répliques (et ce n'est pas nécessaire). Et à condition qu'il y ait un stockage normal sous Kubernetes. Cette base de données fonctionnait dans une machine virtuelle - conditionnellement dans VMware, au-dessus du système de stockage. Nous l'avons placé dans PV et maintenant nous pouvons le transférer de machine à machine.

NA: Des bases de données de cette taille, jusqu'à 100 Go, peuvent être déployées en quelques minutes sur de bons disques et un bon réseau, non ? Une vitesse de 1 Go par seconde n’est plus exotique.

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

NA: Okay, il faut juste penser à la prod. Et si nous envisageons Kubernetes pour les environnements hors production, que devons-nous faire ? Je vois ça chez Zalando faire l'opérateur, en Croquant sciage, il existe d'autres options. Et voici SurGres - voici notre bon ami Alvaro d'Espagne : ce qu'ils font n'est pas simplement l'opérateur, et toute la distribution (StackGres), dans lequel, en plus de Postgres lui-même, ils ont également décidé d'insérer une sauvegarde, le proxy Envoy...

DS: Envoyé pour quoi ? Équilibrer spécifiquement le trafic Postgres ?

NA: Oui. Autrement dit, ils le voient comme suit : si vous prenez une distribution et un noyau Linux, alors PostgreSQL standard est le noyau, et ils veulent créer une distribution qui sera compatible avec le cloud et exécutée sur Kubernetes. Ils assemblent des composants (sauvegardes, etc.) et les déboguent pour qu'ils fonctionnent bien.

DS: Très cool! Il s'agit essentiellement d'un logiciel permettant de créer votre propre Postgres géré.

NA: Les distributions Linux ont d'éternels problèmes : comment créer des pilotes pour que tout le matériel soit pris en charge. Et ils ont l’idée qu’ils travailleront dans Kubernetes. Je sais que chez l'opérateur Zalando nous avons récemment vu une connexion à AWS et ce n'est plus très bon. Il ne devrait pas y avoir de lien avec une infrastructure spécifique – à quoi ça sert alors ?

DS: Je ne sais pas exactement dans quelle situation Zalando s'est retrouvé, mais dans Kubernetes, le stockage est désormais fait de telle manière qu'il est impossible de faire une sauvegarde sur disque en utilisant une méthode générique. Récemment en standard - dans la dernière version Spécifications CSI — nous avons rendu les instantanés possibles, mais où sont-ils implémentés ? Honnêtement, tout est encore aussi brut... Nous essayons CSI sur AWS, GCE, Azure, vSphere, mais dès que vous commencez à l'utiliser, vous voyez qu'il n'est pas encore prêt.

NA: C’est pourquoi nous devons parfois compter sur les infrastructures. Je pense que nous en sommes encore à un stade précoce – des douleurs de croissance. Question : Quels conseils donneriez-vous aux débutants qui souhaitent essayer PgSQL dans K8 ? Quel opérateur peut-être ?

DS: Le problème c'est que Postgres c'est 3% pour nous. Nous avons également une très grande liste de logiciels différents dans Kubernetes, je ne vais même pas tout lister. Par exemple, Elasticsearch. Il existe de nombreux opérateurs : certains se développent activement, d'autres non. Nous avons établi des exigences pour nous-mêmes, ce qui devrait être chez l'opérateur afin que nous le prenions au sérieux. Dans un opérateur spécifiquement pour Kubernetes - pas dans un « opérateur pour faire quelque chose dans les conditions d'Amazon »... En fait, nous utilisons assez largement (= presque tous les clients) un seul opérateur - pour Redis (nous publierons bientôt un article sur lui).

NA: Et pas pour MySQL non plus ? Je sais que Percona... puisqu'ils travaillent désormais sur MySQL, MongoDB et Postgres, ils devront créer une sorte de solution universelle : pour toutes les bases de données, pour tous les fournisseurs de cloud.

DS: Nous n'avons pas eu le temps de regarder les opérateurs pour MySQL. Ce n’est pas notre objectif principal pour le moment. MySQL fonctionne bien en mode autonome. Pourquoi utiliser un opérateur si vous pouvez simplement lancer une base de données... Vous pouvez lancer un conteneur Docker avec Postrges, ou vous pouvez le lancer de manière simple.

NA: Il y avait une question à ce sujet aussi. Pas d'opérateur du tout ?

DS: Oui, 100 % d'entre nous utilisent PostgreSQL sans opérateur. Si loin. Nous utilisons activement l'opérateur pour Prometheus et Redis. Nous envisageons de trouver un opérateur pour Elasticsearch - c'est celui qui est le plus « en feu », car nous voulons l'installer dans Kubernetes dans 100 % des cas. Tout comme nous voulons nous assurer que MongoDB est également toujours installé dans Kubernetes. Ici, certains souhaits apparaissent - on a le sentiment que dans ces cas, quelque chose peut être fait. Et nous n'avons même pas regardé Postgres. Bien sûr, nous savons qu’il existe différentes options, mais en fait nous en avons une autonome.

Base de données pour les tests dans Kubernetes

NA: Passons au sujet des tests. Comment déployer les modifications dans la base de données – du point de vue DevOps. Il existe des microservices, de nombreuses bases de données, quelque chose change tout le temps quelque part. Comment garantir un CI/CD normal afin que tout soit en ordre du point de vue du SGBD. Quelle est votre approche ?

DS: Il ne peut y avoir une seule réponse. Il existe plusieurs options. Le premier est la taille de la base que nous souhaitons déployer. Vous avez vous-même mentionné que les entreprises ont des attitudes différentes à l'égard du fait d'avoir une copie de la base de données de production sur le développement et sur la scène.

NA: Et dans les conditions du RGPD, je pense qu'ils sont de plus en plus prudents... Je peux dire qu'en Europe, ils ont déjà commencé à imposer des amendes.

DS: Mais souvent, vous pouvez écrire un logiciel qui extrait un dump de la production et le masque. Les données de production sont obtenues (instantané, dump, copie binaire...), mais elles sont anonymisées. A la place, il peut y avoir des scripts de génération : il peut s'agir de luminaires ou simplement d'un script qui génère une grande base de données. Le problème est : combien de temps faut-il pour créer une image de base ? Et combien de temps faut-il pour le déployer dans l’environnement souhaité ?

Nous sommes arrivés à un schéma : si le client dispose d'un ensemble de données fixes (version minimale de la base de données), alors nous les utilisons par défaut. Si nous parlons d'environnements de révision, lorsque nous avons créé une branche, nous avons déployé une instance de l'application - nous y déployons une petite base de données. Mais ça s'est bien passé вариант, lorsque nous effectuons un vidage de la production une fois par jour (la nuit) et construisons un conteneur Docker avec PostgreSQL et MySQL avec ces données chargées basées sur celui-ci. Si vous devez agrandir la base de données 50 fois à partir de cette image, cela se fait assez simplement et rapidement.

NA: Par simple copie ?

DS: Les données sont stockées directement dans l'image Docker. Ceux. Nous avons une image toute faite, quoique de 100 Go. Grâce aux couches de Docker, nous pouvons déployer rapidement cette image autant de fois que nécessaire. La méthode est stupide, mais elle fonctionne bien.

NA: Ensuite, lorsque vous testez, cela change directement dans Docker, n'est-ce pas ? Copie sur écriture dans Docker - jetez-le et recommencez, tout va bien. Classe! Et l’utilisez-vous déjà pleinement ?

DS: Pendant longtemps.

NA: Nous faisons des choses très similaires. Seulement, nous n'utilisons pas la copie sur écriture de Docker, mais une autre.

DS: Ce n'est pas générique. Et Docker fonctionne partout.

NA: En théorie, oui. Mais nous y avons aussi des modules, vous pouvez créer différents modules et travailler avec différents systèmes de fichiers. Quel moment ici. Du côté de Postgres, nous regardons tout cela différemment. Maintenant, j'ai regardé du côté Docker et j'ai vu que tout fonctionnait pour vous. Mais si la base de données est énorme, par exemple 1 To, alors tout cela prend beaucoup de temps : opérations de nuit et tout mettre dans Docker... Et si 5 To sont mis dans Docker... Ou est-ce que tout va bien ?

DS: Quelle est la différence : ce sont des blobs, juste des bits et des octets.

NA: La différence est la suivante : le faites-vous via le dump et la restauration ?

DS: Pas du tout nécessaire. Les méthodes pour générer cette image peuvent être différentes.

NA: Pour certains clients, nous avons fait en sorte qu'au lieu de générer régulièrement une image de base, nous la tenions constamment à jour. Il s'agit essentiellement d'une réplique, mais elle reçoit les données non pas directement du maître, mais via une archive. Une archive binaire où les WAL sont téléchargés quotidiennement, où des sauvegardes sont effectuées... Ces WAL atteignent ensuite l'image de base avec un léger retard (littéralement 1 à 2 secondes). Nous le clonons de quelque manière que ce soit - nous avons maintenant ZFS par défaut.

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

NA: Oui. Mais ZFS a aussi un pouvoir magique envoyer: avec, vous pouvez envoyer un instantané et même (je n'ai pas encore vraiment testé ça, mais...) vous pouvez envoyer un delta entre deux PGDATA. En fait, nous disposons d’un autre outil que nous n’avons pas vraiment envisagé pour de telles tâches. PostgreSQL a pg_rewind, qui fonctionne comme un rsync « intelligent », en sautant une grande partie de ce que vous n’avez pas besoin de regarder, car rien n’y a changé. On peut faire une synchronisation rapide entre les deux serveurs et rembobiner de la même manière.

Donc, de ce côté plus DBA, nous essayons de créer un outil qui nous permette de faire la même chose que vous avez dit : nous avons une base de données, mais nous voulons tester quelque chose 50 fois, presque simultanément.

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

NA: Non, nous faisons tout sur une seule machine.

DS: Mais comment allez-vous agrandir 50 fois si cette base de données fait, disons, un téraoctet. Très probablement, elle a besoin de 256 Go de RAM conditionnels ?

NA: Oui, parfois vous avez besoin de beaucoup de mémoire - c'est normal. Mais ceci est un exemple tiré de la vie. La machine de production dispose de 96 cœurs et de 600 Go. Dans le même temps, 32 cœurs (voire 16 cœurs maintenant parfois) et 100 à 120 Go de mémoire sont utilisés pour la base de données.

DS: Et 50 exemplaires y rentrent ?

NA: Il n'y a donc qu'une seule copie, alors la copie sur écriture (ZFS) fonctionne... Je vais vous le dire plus en détail.

Par exemple, nous avons une base de données de 10 To. Ils ont créé un disque pour cela, ZFS a également compressé sa taille de 30 à 40 %. Puisque nous ne effectuons pas de tests de charge, le temps de réponse exact n'est pas important pour nous : qu'il soit jusqu'à 2 fois plus lent - ce n'est pas grave.

Nous donnons l'opportunité aux programmeurs, QA, DBA, etc. effectuer des tests dans 1-2 threads. Par exemple, ils peuvent effectuer une sorte de migration. Il ne nécessite pas 10 cœurs à la fois – il a besoin de 1 backend Postgres, 1 cœur. La migration va commencer - peut-être aspirateur automatique démarrera toujours, alors le deuxième noyau sera utilisé. Nous avons 16 à 32 cœurs alloués, donc 10 personnes peuvent travailler en même temps, sans problème.

Parce que physiquement PGDATA de même, il s'avère que nous trompons Postgres. L'astuce est la suivante : par exemple, 10 Postgres sont lancés simultanément. Quel est le problème habituellement ? Ils mettent tampons_partagés, disons 25%. En conséquence, il s'agit de 200 Go. Vous ne pourrez pas en lancer plus de trois, car la mémoire sera épuisée.

Mais à un moment donné, nous avons réalisé que ce n'était pas nécessaire : nous avons défini shared_buffers sur 2 Go. PostgreSQL a taille_cache_efficace, et en réalité c'est le seul qui influence plans. Nous l'avons fixé à 0,5 To. Et peu importe qu’ils n’existent pas réellement : il fait des projets comme s’ils existaient.

En conséquence, lorsque nous testons une sorte de migration, nous pouvons collecter tous les plans - nous verrons comment cela se passera en production. Les secondes y seront différentes (plus lentes), mais les données que nous lisons réellement et les plans eux-mêmes (quels sont les JOIN, etc.) s'avèrent exactement les mêmes qu'en production. Et vous pouvez exécuter plusieurs de ces vérifications en parallèle sur une seule machine.

DS: Ne pensez-vous pas qu'il y a quelques problèmes ici ? La première est une solution qui ne fonctionne que sur PostgreSQL. Cette approche est très privée, elle n'est pas générique. La seconde est que Kubernetes (et tout ce que vont faire les technologies cloud désormais) implique de nombreux nœuds, et ces nœuds sont éphémères. Et dans votre cas, il s’agit d’un nœud persistant avec état. Ces choses me mettent en conflit.

NA: Tout d'abord, je suis d'accord, c'est une histoire purement Postgres. Je pense que si nous avons une sorte d'E/S directe et un pool de tampons pour presque toute la mémoire, cette approche ne fonctionnera pas - les plans seront différents. Mais pour l’instant nous travaillons uniquement avec Postgres, nous ne pensons pas aux autres.

À propos de Kubernetes. Vous nous dites vous-même partout que nous avons une base de données persistante. Si l'instance échoue, l'essentiel est de sauvegarder le disque. Ici, nous avons également toute la plateforme dans Kubernetes, et le composant avec Postgres est séparé (même s'il sera là un jour). Donc, tout est comme ça : l'instance est tombée, mais nous avons sauvegardé son PV et l'avons simplement connecté à une autre (nouvelle) instance, comme si de rien n'était.

DS: De mon point de vue, nous créons des pods dans Kubernetes. K8s - élastique : les nœuds sont commandés selon les besoins. La tâche consiste simplement à créer un pod et à dire qu'il a besoin d'une quantité X de ressources, puis les K8 le découvriront par eux-mêmes. Mais la prise en charge du stockage dans Kubernetes est toujours instable : 1.16dans 1.17 (cette version a été publiée недели il y a), ces fonctionnalités ne deviennent que la version bêta.

Six mois à un an s'écouleront - cela deviendra plus ou moins stable, ou du moins il sera déclaré comme tel. Ensuite, la possibilité de prendre des instantanés et de redimensionner résout complètement votre problème. Parce que tu as une base. Oui, ce n'est peut-être pas très rapide, mais la vitesse dépend de ce qui se cache sous le capot, car certaines implémentations peuvent copier et copier sur écriture au niveau du sous-système de disque.

NA: Il est également nécessaire que tous les moteurs (Amazon, Google...) commencent à supporter cette version - cela prend également du temps.

DS: Nous ne les utilisons pas encore. Nous utilisons le nôtre.

Développement local pour Kubernetes

NA: Avez-vous rencontré un tel souhait lorsque vous devez installer tous les pods sur une seule machine et faire un si petit test. Pour obtenir rapidement une preuve de concept, vérifiez que l'application s'exécute dans Kubernetes, sans lui consacrer un tas de machines. Il y a Minikube, non ?

DS: Il me semble que ce cas - déployé sur un nœud - concerne exclusivement le développement local. Ou quelques manifestations d’un tel modèle. Manger MinikubeLà K3, GENTIL. Nous nous dirigeons vers l'utilisation de Kubernetes IN Docker. Nous avons maintenant commencé à travailler avec pour des tests.

NA: Je pensais qu'il s'agissait d'une tentative d'envelopper tous les pods dans une seule image Docker. Mais il s’est avéré qu’il s’agissait de quelque chose de complètement différent. Quoi qu'il en soit, il existe des conteneurs séparés, des pods séparés - uniquement dans Docker.

DS: Oui. Et il y a une imitation assez drôle, mais le sens est le suivant... Nous avons un utilitaire de déploiement - cour. Nous voulons en faire un mode conditionnel werf up: « Donnez-moi Kubernetes local. » Et puis exécutez le conditionnel ici werf follow. Ensuite, le développeur pourra éditer l'EDI et un processus sera lancé dans le système qui verra les modifications et reconstruira les images, en les redéployant sur les K8 locaux. C'est ainsi que nous voulons tenter de résoudre le problème du développement local.

Instantanés et clonage de bases de données dans la réalité de K8

NA: Si nous revenons à la copie sur écriture. J'ai remarqué que les nuages ont aussi des instantanés. Ils fonctionnent différemment. Par exemple, dans GCP : vous disposez d’une instance de plusieurs téraoctets sur la côte est des États-Unis. Vous prenez des instantanés périodiquement. Vous récupérez une copie du disque sur la côte ouest à partir d'un instantané - en quelques minutes tout est prêt, cela fonctionne très rapidement, seul le cache doit être rempli en mémoire. Mais ces clones (instantanés) sont destinés à « provisionner » un nouveau volume. C'est cool lorsque vous devez créer beaucoup d'instances.

Mais pour les tests, il me semble que les instantanés, dont vous parlez dans Docker ou dont je parle dans ZFS, btrfs et même LVM... - ils permettent de ne pas créer de données vraiment nouvelles sur une seule machine. Dans le cloud, vous les paierez toujours à chaque fois et n'attendrez pas des secondes, mais des minutes (et dans le cas charge paresseuse, éventuellement une montre).

Au lieu de cela, vous pouvez obtenir ces données en une seconde ou deux, exécuter le test et les jeter. Ces instantanés résolvent différents problèmes. Dans le premier cas, pour évoluer et obtenir de nouvelles répliques, et dans le second, pour des tests.

DS: je ne suis pas d'accord. Faire fonctionner correctement le clonage de volumes est la tâche du cloud. Je n’ai pas examiné leur implémentation, mais je sais comment nous procédons sur le matériel. Nous avons Ceph, il autorise n'importe quel volume physique (RBD) dire cloner et obtenir un deuxième volume avec les mêmes caractéristiques en quelques dizaines de millisecondes, IOPS'ami, etc. Vous devez comprendre qu'il y a une copie sur écriture délicate à l'intérieur. Pourquoi le cloud ne devrait-il pas faire de même ? Je suis sûr qu'ils essaient de procéder d'une manière ou d'une autre.

NA: Mais il leur faudra quand même des secondes, des dizaines de secondes pour lancer une instance, y amener Docker, etc.

DS: Pourquoi est-il nécessaire de relancer une instance entière ? Nous avons une instance avec 32 cœurs, 16... et elle peut y entrer - par exemple quatre. Lorsque nous en commanderons la cinquième, l'instance sera déjà levée, puis elle sera supprimée.

NA: Oui, intéressant, Kubernetes s'avère être une autre histoire. Notre base de données n'est pas dans K8 et nous en avons une instance. Mais le clonage d'une base de données de plusieurs téraoctets ne prend pas plus de deux secondes.

DS: C'est bien. Mais mon premier point est qu’il ne s’agit pas d’une solution générique. Oui, c'est cool, mais cela ne convient qu'à Postgres et uniquement sur un seul nœud.

NA: Il ne convient pas seulement à Postgres : ces plans, comme je l'ai décrit, ne fonctionneront que dans celui-ci. Mais si nous ne nous soucions pas des plans et que nous avons juste besoin de toutes les données pour les tests fonctionnels, alors cela convient à n'importe quel SGBD.

DS: Il y a de nombreuses années, nous avons fait quelque chose de similaire sur les instantanés LVM. C'est un classique. Cette approche a été très activement utilisée. Les nœuds avec état ne sont qu'un problème. Parce qu'il ne faut pas les laisser tomber, il faut toujours s'en souvenir...

NA: Voyez-vous une possibilité d’hybride ici ? Disons que stateful est une sorte de pod, il fonctionne pour plusieurs personnes (de nombreux testeurs). Nous avons un seul volume, mais grâce au système de fichiers, les clones sont locaux. Si le pod tombe, mais que le disque reste, le pod se lèvera, comptera les informations sur tous les clones, reprendra tout et dira : « Voici vos clones fonctionnant sur ces ports, continuez à travailler avec eux.

DS: Techniquement, cela signifie qu'au sein de Kubernetes, il s'agit d'un seul pod dans lequel nous exécutons plusieurs Postgres.

NA: Oui. Il a une limite : disons que pas plus de 10 personnes travaillent avec lui en même temps. Si vous en avez besoin de 20, nous lancerons un deuxième module de ce type. Nous le clonerons entièrement, après avoir reçu le deuxième volume complet, il aura les mêmes 10 clones « fins ». Vous ne voyez pas cette opportunité ?

DS: Nous devons ajouter ici des problèmes de sécurité. Ce type d'organisation implique que ce pod dispose de privilèges (capacités) élevés, car il peut effectuer des opérations non standard sur le système de fichiers... Mais je le répète : je crois qu'à moyen terme ils répareront le stockage dans Kubernetes, et dans les nuages, ils répareront toute l'histoire avec des volumes - tout "fonctionnera". Il y aura un redimensionnement, un clonage... Il y a un volume - nous disons : « Créez-en un nouveau sur cette base » et après une seconde et demie, nous obtenons ce dont nous avons besoin.

NA: Je ne crois pas à une seconde et demie pour plusieurs téraoctets. Sur Ceph, vous le faites vous-même, mais vous parlez des nuages. Accédez au cloud, créez un clone d'un volume EBS de plusieurs téraoctets sur EC2 et voyez quelles seront les performances. Cela ne prendra pas quelques secondes. Je suis très intéressé de savoir quand ils atteindront ce niveau. Je comprends ce que vous dites, mais je ne suis pas d'accord.

DS: Ok, mais j'ai dit à moyen terme, pas à court terme. Pour plusieurs années.

À propos de l'opérateur pour PostgreSQL de Zalando

Au milieu de cette réunion, Alexey Klyukin, un ancien développeur de Zalando, s'est également joint à nous et a évoqué l'histoire de l'opérateur PostgreSQL :

C’est formidable que ce sujet soit abordé de manière générale : à la fois Postgres et Kubernetes. Lorsque nous avons commencé à le faire chez Zalando en 2017, c'était un sujet que tout le monde voulait aborder, mais personne ne le faisait. Tout le monde possédait déjà Kubernetes, mais lorsqu'ils demandaient quoi faire avec les bases de données, même les gens aiment Kelsey High Tower, qui prêchait les K8, a dit quelque chose comme ceci :
« Accédez aux services gérés et utilisez-les, n'exécutez pas la base de données dans Kubernetes. Sinon, vos K8 décideront, par exemple, de faire une mise à niveau, d’éteindre tous les nœuds et vos données s’envoleront très, très loin.
Nous avons décidé de créer un opérateur qui, contrairement à cet avis, lancera une base de données Postgres dans Kubernetes. Et nous avions une bonne raison - patroni. Il s'agit d'un basculement automatique pour PostgreSQL, effectué correctement, c'est-à-dire en utilisant etcd, consul ou ZooKeeper comme stockage d'informations sur le cluster. Un tel référentiel qui donnera à tous ceux qui demandent, par exemple, quel est le leader actuel, les mêmes informations - malgré le fait que nous ayons tout distribué - afin qu'il n'y ait pas de cerveau divisé. De plus, nous avions Image Docker pour lui.
En général, le besoin de basculement automatique de l’entreprise est apparu après la migration d’un centre de données matériel interne vers le cloud. Le cloud reposait sur une solution propriétaire PaaS (Platform-as-a-Service). C'est Open Source, mais il a fallu beaucoup de travail pour le rendre opérationnel. Ça s'appelait COUP DE COUDE.
Au départ, Kubernetes n’existait pas. Plus précisément, lorsque notre propre solution a été déployée, les K8 existaient déjà, mais ils étaient tellement bruts qu'ils n'étaient pas adaptés à la production. C'était, à mon avis, 2015 ou 2016. En 2017, Kubernetes était devenu plus ou moins mature : il fallait y migrer.
Et nous avions déjà un conteneur Docker. Il existait un PaaS qui utilisait Docker. Pourquoi ne pas essayer les K8 ? Pourquoi ne pas écrire votre propre opérateur ? Murat Kabilov, qui nous est venu d'Avito, a lancé ce projet de sa propre initiative - « pour jouer » - et le projet a « décollé ».
Mais en général, je voulais parler d'AWS. Pourquoi y avait-il du code historique lié à AWS...
Lorsque vous exécutez quelque chose dans Kubernetes, vous devez comprendre que K8 est un travail en cours. Il se développe, s’améliore et même s’effondre de temps en temps. Vous devez garder un œil attentif sur tous les changements apportés à Kubernetes, vous devez être prêt à vous y plonger si quelque chose se produit et à apprendre comment cela fonctionne en détail - peut-être plus que vous ne le souhaiteriez. Ceci, en principe, s'applique à toute plate-forme sur laquelle vous exécutez vos bases de données...
Ainsi, lorsque nous avons fait la déclaration, Postgres s'exécutait sur un volume externe (EBS dans ce cas, puisque nous travaillions sur AWS). La base de données s'est agrandie, à un moment donné il a fallu la redimensionner : par exemple, la taille initiale d'EBS était de 100 To, la base de données s'est agrandie, maintenant nous voulons faire EBS de 200 To. Comment? Disons que vous pouvez effectuer un vidage/restauration sur une nouvelle instance, mais cela prendra beaucoup de temps et impliquera des temps d'arrêt.
Par conséquent, je voulais un redimensionnement qui agrandirait la partition EBS, puis indiquerait au système de fichiers d'utiliser le nouvel espace. Et nous l'avons fait, mais à cette époque, Kubernetes ne disposait d'aucune API pour l'opération de redimensionnement. Depuis que nous travaillons sur AWS, nous avons écrit du code pour son API.
Personne ne vous empêche de faire de même pour d’autres plateformes. Rien n'indique dans la déclaration qu'il ne peut être exécuté que sur AWS et qu'il ne fonctionnera pas sur tout le reste. En général, il s'agit d'un projet Open Source : si quelqu'un souhaite accélérer l'émergence de l'utilisation de la nouvelle API, il est le bienvenu. Manger GitHub, pull request - l'équipe Zalando essaie d'y répondre assez rapidement et de promouvoir l'opérateur. Autant que je sache, le projet participé au Google Summer of Code et à d'autres initiatives similaires. Zalando y travaille très activement.

PS-Bonus !

Si le sujet de PostgreSQL et Kubernetes vous intéresse, veuillez également noter que le prochain Postgres Tuesday a eu lieu la semaine dernière, où j'ai parlé avec Nikolai Alexandre Kukushkin de Zalando. La vidéo de celui-ci est disponible ici.