À la fin de l'année dernière, une autre diffusion en direct de la communauté russe PostgreSQL
#RuPostgres a eu lieu , au cours de laquelle son co-fondateur Nikolai Samokhvalov a parlé avec le directeur technique de Flanta Dmitry Stolyarov de ce SGBD dans le contexte de Kubernetes.
Nous publions une transcription du corps principal de cette discussion, et une vidéo complète a été publiée
sur la chaîne YouTube de la communauté :
Bases de données et Kubernetes
NS : Nous ne parlerons pas de vide et de points de contrôle 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 des pièces ... Allons-y tout de suite: pourquoi Postgres ou MySQL dans K8s?DS : Il n'y a pas de réponse unique à cette question et elle ne peut pas l'être. Mais en général, c'est la simplicité et la commodité ... le potentiel. Après tout, tout le monde veut des services gérés.
NS : Pour aimer RDS , uniquement à la maison?DS : Oui: pour aimer RDS, seulement n'importe où.
NS : «N'importe où» est un bon point. Dans les grandes entreprises, tout est situé à différents endroits. Et pourquoi alors, s'il s'agit d'une grande entreprise, ne prenez pas une solution toute faite? Par exemple, Nutanix a ses propres développements, tandis que d'autres sociétés (VMware ...) ont le même «RDS, uniquement à domicile».DS : Mais nous parlons d'une implémentation unique qui ne fonctionnera que sous certaines conditions. Et si nous parlons de Kubernetes, il existe une grande variété d'infrastructures (qui peuvent être dans les K8). C'est essentiellement la norme pour l'API vers le cloud ...
NS : C'est gratuit aussi!DS : Ce n'est pas si important. La gratuité n'est pas importante pour un très grand segment du marché. Une autre chose est importante ... Vous vous souvenez probablement du rapport "
Bases de données et Kubernetes "?
NS : Oui.DS : J'ai réalisé qu'il était perçu de manière très ambiguë. Certaines personnes pensaient que je disais: "Les gars, nous sommes allés toutes les bases de données à Kubernetes!", Tandis que d'autres ont décidé que ce sont tous des vélos terribles. Et je voulais dire autre chose: «Regardez ce qui se passe, quels sont les problèmes et comment ils peuvent être résolus. Allez maintenant des bases à Kubernetes? La production? Eh bien, seulement si vous aimez ... faire certaines choses. Mais pour les développeurs, je peux dire que je le recommande. Pour les développeurs, la création / suppression dynamique d'environnements est très importante. »
NS: Par dev, voulez-vous dire tous les environnements qui ne sont pas prod? Mise en scène, QA ...DS : Si nous parlons de stands de perf, ce n'est probablement pas déjà le cas, car les exigences y sont spécifiques. Si nous parlons de cas particuliers où la mise en scène a besoin d'une très grande base de données, alors probablement pas non plus ... S'il s'agit d'un environnement statique, de longue durée, alors quel est l'avantage d'avoir la base située dans les K8?
NS : Aucun. Mais où voit-on des environnements statiques? L'environnement statique est dépassé demain.DS : la mise en scène peut être statique. Nous avons des clients ...
NS : Oui, je l'ai aussi. Le gros problème est que si vous avez une base de 10 To et une mise en scène - 200 Go ...DS : J'ai un étui très cool! Lors de la mise en scène, il existe une base prod'ovy dans laquelle des modifications sont apportées. Et un bouton est fourni: "déploiement en production". Ces changements - deltas - sont ajoutés (il semble, ils sont juste synchronisés par les API) en production. C'est une option très exotique.
NS : J'ai vu des startups dans la vallée qui sont encore assis dans RDS ou même dans Heroku - ce sont des histoires d'il y a 2-3 ans - et ils téléchargent le vidage sur leur ordinateur portable. Parce que la base ne fait que 80 Go jusqu'à présent, et qu'il y a une place sur l'ordinateur portable. Ensuite, ils achètent des disques pour tout le monde, afin qu'ils aient 3 bases, afin qu'ils puissent effectuer différents développements. Cela arrive aussi. J'ai également vu qu'ils n'avaient pas peur de copier la prod dans la mise en scène - cela dépend beaucoup de l'entreprise. Mais il a vu qu'ils avaient très peur et que souvent ils n'avaient pas assez de temps et de mains. Mais avant de passer à ce sujet, je veux entendre parler de Kubernetes. Je comprends bien que dans prod'e jusqu'ici personne?DS : Nous avons de petites bases en prod. Nous parlons de volumes de dizaines de gigaoctets et de services non critiques, pour lesquels il était trop paresseux pour faire des répliques (et il n'y a pas un tel besoin). Et à condition que sous Kubernetes il y ait un stockage normal. Cette base de données fonctionnait dans une machine virtuelle - conditionnellement dans VMware, en plus du stockage. Nous l'avons placé en
PV et maintenant nous pouvons le transférer de voiture en voiture.
NS : Des bases de cette taille, jusqu'à 100 Go, sur de bons disques et avec un bon réseau peuvent être déployées en quelques minutes, non? Une vitesse de 1 Go par seconde n'est plus exotique.DS : Oui, pour une opération linéaire ce n'est pas un problème.
NS : D'accord, nous ne devrions penser qu'à prod. Et si nous considérons Kubernetes pour les environnements non prod - comment le faire? Je vois qu'à Zalando ils font un opérateur , à Crunchy ils scient , il y a d'autres options. Et il y a OnGres - c'est notre bon ami espagnol Alvaro: ils ne sont pas seulement un opérateur , mais une distribution entière ( StackGres ), dans laquelle, en plus de Postgres lui-même, ils ont également décidé de bourrer la sauvegarde, le proxy Envoy ...DS : Envoyé pour quoi? L'équilibrage du trafic Postgres exactement?
NS : Oui. Autrement dit, ils le voient comme: si vous prenez la distribution Linux et le noyau, alors le PostgreSQL habituel est le noyau, et ils veulent faire une distribution qui est compatible avec le cloud et fonctionne sur Kubernetes. Ils ancrent les composants (sauvegardes, etc.) et déboguent pour qu'ils fonctionnent bien.DS : Très cool! En substance, c'est un logiciel pour créer vos Postgres gérés.
NS : les distributions Linux ont des problèmes éternels: comment créer des pilotes pour que tout le matériel soit pris en charge. Et ils ont l'idée de travailler chez Kubernetes. Je sais que chez l'opérateur Zalando, nous avons récemment vu les globes oculaires sur AWS et ce n'est pas très bon. Il ne devrait pas y avoir de liens avec une infrastructure spécifique - à quoi bon alors?DS : Je ne sais pas dans quelle situation spécifique Zalando s'est impliqué, mais dans Kubernetes, le stockage est désormais réalisé de telle manière qu'il est impossible de supprimer une sauvegarde de disque de manière générique. Récemment, la norme - dans la dernière version de
la spécification CSI - a rendu possible les instantanés, mais où est-elle implémentée? Honnêtement, c'est toujours aussi brut ... Nous essayons CSI par-dessus AWS, GCE, Azure, vSphere, mais nous commençons à l'utiliser un peu, car vous pouvez voir qu'il n'est pas encore prêt.
NS : Par conséquent, il faut parfois se rattacher à l'infrastructure. Je pense que ce n'est encore qu'un stade précoce - des problèmes de croissance. Question: que recommanderiez-vous aux débutants qui souhaitent essayer PgSQL dans les K8? Quel opérateur peut-être?DS : Le problème est que pour nous, Postgres est de 3%. Nous avons toujours 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 beaucoup d'opérateurs: certains se développent activement, d'autres non. Pour nous, nous avons fait des exigences qui devraient être dans l'opérateur, afin que nous le prenions au sérieux. L'opérateur est spécifiquement pour Kubernetes - pas "l'opérateur pour faire quelque chose dans les conditions d'Amazon ..." En fait, nous utilisons un seul opérateur assez largement (= pour presque tous les clients) -
pour Redis (nous publierons bientôt un article à ce sujet) .
NS : Mais pour MySQL aussi? Je sais que Percona ... puisqu'ils sont maintenant impliqués dans MySQL, MongoDB et Postgres, ils devront avoir une sorte d'entaille 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 déclarations pour MySQL. Pour nous, ce n'est pas l'objectif principal maintenant. MySQL fonctionne très bien en autonome. Pourquoi un opérateur, si vous pouvez simplement démarrer la base de données ... Vous pouvez démarrer le conteneur Docker avec Postrges, ou vous pouvez le démarrer de manière simple.
NS : C'était aussi une question. Pas d'opérateur du tout?DS : Oui, 100% d'entre nous ont PostgreSQL fonctionnant sans opérateur. Jusqu'à présent. Nous utilisons activement l'opérateur pour Prometheus, pour Redis. Nous avons l'intention de trouver un opérateur pour Elasticsearch - il brûle le plus parce que nous voulons l'installer dans 100% des cas à Kubernetes. Tout comme nous voulons nous assurer que MongoDB est toujours également installé dans Kubernetes. Certaines listes de souhaits apparaissent ici - on a le sentiment que dans ces cas, quelque chose peut être fait. Et à propos de Postgres, nous n'avons même pas regardé. Bien sûr, nous connaissons l'existence de différentes options, mais en fait, nous en avons une autonome.
Tester la base de données dans Kubernetes
NS : Passons au sujet des tests. Comment déployer les modifications dans la base de données - du point de vue de la perspective DevOps. Il y a des microservices, de nombreuses bases de données, tout le temps quelque part quelque chose change. Comment garantir un CI / CD normal afin que tout soit en ordre à partir de la position du SGBD. Quelle est votre approche?DS : Il ne peut y avoir qu'une seule réponse. Il existe plusieurs options. Le premier est la taille de la base que nous voulons déployer. Vous avez vous-même mentionné que les entreprises ont une attitude différente à l'idée d'avoir une copie de la base de production sur le développement et la scène.
NS : Et en termes de RGPD, je pense qu'ils sont de plus en plus soignés ... Je peux dire qu'en Europe, ils ont déjà commencé à aller bien.DS : Mais vous pouvez souvent écrire des logiciels qui déchargent la production et la brouillent. Il s'avère que les données prod'ovye (snapshot, dump, copie binaire ...), mais elles sont anonymes. Au lieu de cela, il peut y avoir des scripts de génération: il peut s'agir de fixtures ou simplement d'un script qui génère une grande base de données. Le problème est quoi: combien de temps prend l'image de base pour être créée? Et combien de temps pour le déployer sur le bon environnement?
Nous sommes arrivés au schéma: si le client a un ensemble de données de fixture (version minimale de la base de données), alors par défaut nous les utilisons. Si nous parlons d'environnements d'examen, lorsque nous avons créé une branche, nous avons déployé une instance d'application - nous y déployons une petite base de données. Mais l'
option s'est avérée bien, lorsque nous supprimons le vidage de la production une fois par jour (la nuit) et collectons sur sa base un conteneur Docker avec PostgreSQL et MySQL avec ces données chargées. Si vous devez déployer la base 50 fois à partir de cette image, cela se fait assez simplement et rapidement.
NS : Copie simple?DS : les données sont stockées directement dans l'image Docker. C'est-à-dire nous avons une image prête à l'emploi, bien que 100 Go. Grâce aux couches de Docker, nous pouvons rapidement déployer cette image autant de fois que nécessaire. La méthode est stupide, mais elle fonctionne plutôt bien.
NS : De plus, lors des tests, cela change directement à l'intérieur du Docker, non? Copie sur écriture dans Docker - jetez-le et recommencez, tout va bien. Classe! Et vous l'utilisez déjà avec might et main?DS : Pendant longtemps.
NS : Nous faisons des choses très similaires. Seulement, nous n'utilisons pas la copie sur écriture de Docker, mais quelques autres.JS : Il n'est pas générique. Et Docker'ny fonctionne partout.
NS : En théorie, oui. Mais nous avons également des modules là-bas, vous pouvez créer différents modules et travailler avec différents systèmes de fichiers. Quel moment. De Postgres, nous regardons tout cela différemment. Maintenant, j'ai regardé du côté de Docker et j'ai vu que tout fonctionnait pour vous. Mais si la base de données est énorme, par exemple, 1 To, alors c'est tout long: à la fois les opérations de nuit et tout bourrer dans Docker ... Et si 5 To sont bourrés dans Docker ... Ou est-ce que tout est normal?DS : Quelle différence cela fait-il: ce sont des blobs, juste des bits et des octets.
NS : La différence est la suivante: faites-vous cela via le vidage et la restauration?DS : Pas du tout nécessaire. Les méthodes de génération de cette image peuvent être différentes.
NS : Pour certains clients, nous avons fait en sorte qu'au lieu de générer régulièrement une image de base, nous la maintenions constamment à jour. Il s'agit essentiellement d'une réplique, mais les données ne sont pas reçues directement du maître, mais via l'archive. L'archive binaire où les WAL sont roulés tous les jours, les sauvegardes y sont également supprimées ... Ces WAL volent ensuite - avec un léger retard (littéralement 1-2 secondes) - vers l'image de base. Nous le clonons de quelque façon que ce soit - nous avons maintenant ZFS par défaut.DS : Mais avec ZFS, vous êtes limité à un seul nœud.
NS : Oui. Mais ZFS a aussi un envoi magique: vous pouvez envoyer un instantané avec lui et même (je ne l'ai pas encore vraiment testé, mais ...) vous pouvez envoyer un delta entre deux PGDATA . En fait, nous avons un autre outil que nous n'avons pas particulièrement pris en compte pour de telles tâches. PostgreSQL a pg_rewind , qui fonctionne comme une rsync «intelligente», sautant beaucoup de choses que vous n’avez pas à regarder, car rien n’a changé à coup sûr. Nous pouvons effectuer une synchronisation rapide entre les deux serveurs et rembobiner exactement de la même manière.Donc, nous essayons sur ce point, plus DBA'noy, de créer un outil qui vous permet de faire la même chose que vous avez dit: nous avons une base, mais nous voulons tester quelque chose 50 fois, presque en même temps.DS : 50 fois signifie que vous devez commander 50 instances Spot.
NS : Non, nous faisons tout sur une seule machine.DS : Mais comment déployez-vous 50 fois si cette base est, disons, un téraoctet. Très probablement, elle a besoin conditionnellement de 256 Go de RAM?
NS : Oui, parfois beaucoup de mémoire est nécessaire - c'est normal. Mais un tel exemple de la vie. La machine de production a 96 cœurs et 600 Go. Dans le même temps, 32 cœurs sont utilisés pour la base de données (même 16 cœurs sont parfois désormais utilisés) et 100 à 120 Go de mémoire.DS : Et 50 exemplaires y entrent?
NS : Il n'y a donc qu'une seule copie, puis la copie sur écriture (ZFS'ny) fonctionne ... Je vais vous en dire plus.Par exemple, nous avons une base de 10 To. Ils ont fait un disque pour cela, ZFS a encore réduit sa taille en pourcentage de 30 à 40. Comme nous ne faisons pas de test de charge, le temps de réponse exact n'est pas important pour nous: laissez-le être jusqu'à 2 fois plus lent - c'est correct.Nous permettons aux programmeurs, QA, DBA, etc. Effectuez des tests dans 1-2 threads. Par exemple, ils peuvent démarrer une sorte de migration. Il ne nécessite pas 10 cœurs à la fois - il a besoin de 1 backend Postgres, 1 core. La migration commencera - peut-être que le vide automatique démarrera toujours, puis le deuxième noyau sera activé. Nous avons alloué 16 à 32 cœurs, donc 10 personnes peuvent travailler simultanément, il n'y a aucun problème.Étant donné que PGDATA physiquement le même, il s'avère que nous trompons réellement Postgres. L'astuce est la suivante: elle démarre, par exemple, 10 Postgres en même temps. Quel problème est généralement quoi? Ils ont mis les tampons partagés , disons, à 25%. En conséquence, cela fait 200 Go. Vous n'en démarrerez pas plus de trois, car la mémoire se terminera.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 effective_cache_size , et en réalité, cela n'affecte que les plans . Nous le mettons à 0,5 To. Et peu importe qu’ils ne soient pas vraiment là: il fait des plans comme si c’était le cas.En conséquence, lorsque nous testons une sorte de migration, nous pouvons collecter tous les plans - nous verrons comment cela se produira en production. Les secondes seront différentes (plus lentes), mais les données que nous lisons réellement et les plans eux-mêmes (quel type de JOIN, etc.) sont obtenus exactement de la même manière qu'en production. Et en parallèle, vous pouvez exécuter plusieurs de ces vérifications sur une seule machine.DS : Pensez-vous qu'il y a plusieurs problèmes? 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 - Kubernetes (et c'est là que le cloud va maintenant) 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 contredisent.
NS : Tout d'abord - je suis d'accord, c'est une histoire purement Postgres. Je pense que si nous avons des E / S directes et un pool de mémoire tampon pour presque toute la mémoire, cette approche ne fonctionnera pas - il y aura des plans différents. Mais nous ne travaillons avec Postgres que pour le moment, nous ne pensons pas aux autres.À propos de Kubernetes. Vous dites vous-même toujours que nous avons une base persistante. Si l'instance se bloque, l'essentiel est de sauvegarder le disque. Ici, nous avons également la plate-forme entière dans Kubernetes, et le composant avec Postgres est séparé (bien qu'il soit là un jour). Par conséquent, tout est ainsi: l'instance est tombée, mais nous l'avons enregistrée PV et nous nous sommes juste connectés à une autre (nouvelle) instance, comme si rien ne s'était passé.DS : De mon point de vue, nous créons des pods dans Kubernetes. K8 - élastique: les composants sont commandés seuls selon les besoins. La tâche consiste simplement à créer un pod et à dire qu'il a besoin de ressources X, puis les K8 le découvriront. Mais le support de stockage dans Kubernetes est toujours instable: en
1.16 , en
1.17 (cette version est sortie il y a des
semaines ), ces fonctionnalités ne deviennent que bêta.
Six mois ou un an s'écouleront - il deviendra plus ou moins stable, ou du moins sera déclaré comme tel. Ensuite, la possibilité d'instantanés et de redimensionner résout déjà complètement votre problème. Parce que vous avez une base. Oui, ce n'est peut-être pas très rapide, mais la vitesse dépend de ce qui est «sous le capot», car certaines implémentations peuvent copier et copier-écrire au niveau du sous-système de disque.
NS : Il est également nécessaire que tous les moteurs (Amazon, Google ...) commencent à prendre en charge cette version - cela prend également un certain temps.DS : Bien que nous ne les utilisions pas. Nous utilisons le nôtre.
Développement local sous Kubernetes
NS : Avez-vous rencontré une telle liste de souhaits lorsque vous devez lever tous les pods sur une seule machine et faire un si petit test. Afin d'obtenir rapidement une preuve de concept, vérifiez que l'application fonctionne dans Kubernetes, sans lui allouer un tas de machines. Y a-t-il un Minikube, non?DS : Il me semble que ce cas - déployer sur un nœud - concerne exclusivement le développement local. Ou certaines manifestations d'un tel schéma. Il y a
Minikube , il y a des
k3 ,
KIND . Nous allons utiliser Kubernetes IN Docker. Maintenant, ils ont commencé à travailler avec lui pour des tests.
NS : Je pensais que c'était une tentative d'envelopper tous les pods dans une seule image Docker. Mais il s'est avéré qu'il s'agissait d'autre chose. Quoi qu'il en soit, il y a des conteneurs séparés, des pods séparés - juste dans le Docker.DS : Oui. Et là, une imitation assez drôle est faite, mais le fait est ... Nous avons un outil de déploiement -
werf . Nous voulons y faire un mode -
werf up conditionnellement: «Élevez-moi un Kubernetes local». Et puis exécutez le
werf follow conditionnel
werf follow . Ensuite, le développeur pourra éditer dans l'IDE, et un processus est lancé dans le système qui voit les changements et rassemble les images, les remodèle dans les K8 locaux. Nous voulons donc essayer de résoudre le problème du développement local.
Instantanés et clonage de base de données dans la réalité des K8
NS : Si vous revenez à la copie sur écriture. J'ai remarqué que les nuages ont également des instantanés. Ils fonctionnent différemment. Par exemple, dans GCP: vous avez une instance de plusieurs téraoctets sur la côte est des États-Unis. Vous effectuez régulièrement des instantanés. Vous prenez 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) - afin de «provisionner» un nouveau volume. C'est formidable lorsque vous devez créer de nombreuses instances.Mais pour les tests, il me semble, les instantanés dont vous parlez dans Docker ou dont je parle dans ZFS, btrfs et même LVM ... - ils vous permettent de ne pas faire vraiment de nouvelles données sur la même machine. Dans le cloud, vous devez toujours les payer à chaque fois et attendre non pas des minutes, mais des minutes (et dans le cas d'un chargement paresseux , c'est probablement des heures).Au lieu de cela, vous pouvez obtenir ces données en une seconde ou deux, effectuer le test et le 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 les tests.DS : Je ne suis pas d'accord. Le clonage de volumes est normalement la tâche du cloud. Je n'ai pas regardé leur mise en œuvre, mais je sais comment nous le faisons sur le matériel. Nous avons Ceph, vous pouvez dire à n'importe quel volume physique (
RBD ) de
cloner et obtenir un deuxième volume avec les mêmes caractéristiques,
IOPS , etc., en dizaines de millisecondes. Vous devez comprendre qu'il y a une copie sur écriture délicate à l'intérieur. Pourquoi le cloud ne fait-il pas de même? Je suis sûr qu'ils essaient en quelque sorte de le faire.
NS : Mais il leur faudra encore des secondes, des dizaines de secondes pour soulever l'instance, amener Docker là-bas, etc.DS : Pourquoi est-il nécessaire de générer une instance entière? Mais nous avons une instance pour 32 cœurs, pour 16 ... et il s'intègre en quelque sorte - par exemple, quatre. Lorsque nous commandons le cinquième, l'instance augmentera, puis elle sera supprimée.
NS : Oui, fait intéressant, Kubernetes a une histoire différente. Notre base de données n'est pas en K8 et une seule instance. Mais le clonage d'une base de données de plusieurs téraoctets ne prend pas plus de deux secondes.DS : C'est cool. Mais mon message initial est que ce n'est pas une solution générique. Oui, c'est cool, mais seul Postgres convient et sur un seul nœud.
NS : Il ne convient pas seulement à Postgres: ces plans, comme je l'ai décrit, ne fonctionneront que de cette manière. Mais si vous ne vous embêtez pas avec les plans, mais 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 l'avons fait sur des instantanés LVM. Ceci est un classique. Cette approche a été utilisée très activement. Seuls les nœuds avec état sont une douleur. Parce qu'ils n'ont pas besoin d'être abandonnés, souvenez-vous toujours d'eux ...
NS : Voyez-vous une possibilité hybride ici? Disons que stateful est une sorte de pod, il fonctionne pour plusieurs personnes (de nombreux testeurs). Nous avons un volume, mais grâce au système de fichiers, les clones sont locaux. Si le pod tombe, le disque reste - le pod monte, il considère les informations sur tous les clones, reprend tout et dit: "Voici vos clones sur ces ports, commencez à travailler avec eux."DS : Techniquement, cela signifie qu'au sein de Kubernetes, il s'agit d'un seul pod, à l'intérieur duquel nous exécutons de nombreux Postgres.
NS : Oui. Il a une limite: supposons, en même temps, pas plus de 10 personnes travaillent avec lui. Si vous en avez besoin de 20, exécutez le deuxième module de ce type. De façon réaliste, clonez-le, après avoir reçu le deuxième volume complet, il aura les mêmes 10 clones «fins». Vous ne voyez pas une telle opportunité?DS : Nous devons ajouter des problèmes de sécurité ici. Une telle option d'organisation implique que ce pod a des capacités élevées car il peut effectuer des opérations non standard sur le système de fichiers ... Mais je répète: je pense qu'à moyen terme, le stockage sera fixé dans Kubernetes, toute l'histoire avec des volumes sera fixée dans les nuages - tout fonctionnera "simplement". Il va redimensionner, cloner ... Il y a un volume - nous disons: «Créez-en un nouveau sur la base de cela» - et après une seconde et demie nous obtenons ce dont nous avons besoin.
NS : Je ne crois pas en une seconde et demie pour plusieurs téraoctets. Chez Ceph, vous le faites vous-même et vous parlez de nuages. Accédez au cloud, sur EC2, faites un clone du volume EBS de plusieurs téraoctets et voyez quelles seront les performances. Cela ne prend pas quelques secondes. Je suis très intéressé quand ils atteignent un tel indicateur. Je comprends de quoi vous parlez, mais je ne suis pas d'accord.DS : D'accord, mais je l'ai dit à moyen terme, pas à court terme. Depuis plusieurs années.
Opérateur Pro pour PostgreSQL de Zalando
Au milieu de cette réunion, Alexey Klyukin, un ancien développeur de Zalando, qui a parlé de l'histoire de l'opérateur PostgreSQL, l'a également rejoint:
C'est formidable qu'en général, ce sujet ait été abordé: Postgres et Kubernetes. Lorsque nous avons commencé à le faire à Zalando en 2017, c'était un sujet que tout le monde voulait faire, mais personne ne l'a fait. Tout le monde avait déjà Kubernetes, mais lorsqu'on leur a demandé quoi faire avec les bases de données, même des gens comme Kelsey Hightower qui ont prêché les K8 ont dit quelque chose comme ceci:
«Accédez aux services gérés et utilisez-les, ne démarrez pas la base de données dans Kubernetes. Sinon, vos K8 décideront, par exemple, de mettre à niveau, d'éteindre tous les nœuds et vos données voleront très loin. "
Nous avons décidé de faire un opérateur qui, contrairement à ce conseil, lancera la base de données Postgres à Kubernetes. Et nous avions une bonne base - Patroni . Il s'agit d'un basculement automatique pour PostgreSQL, effectué correctement, c'est-à-dire en utilisant etcd, consul ou ZooKeeper comme référentiel pour les informations de cluster. Un tel référentiel qui sera remis à tous ceux qui demanderont, par exemple, quel leader est maintenant, les mêmes informations - malgré le fait que nous ayons tout distribué - pour qu'il n'y ait pas de cerveau divisé. De plus, nous avions une image Docker pour lui.
En général, le besoin de basculement automatique dans l'entreprise est apparu après la migration du centre de données Iron vers le cloud. Le cloud était basé sur une solution propriétaire PaaS (Platform-as-a-Service). C'est de l'Open Source, mais pour le développer, il a fallu travailler dur. Cela s'appelait STUPS .
Au départ, il n'y avait pas de Kubernetes. Plus précisément, lorsque sa propre solution a été déployée, les K8 l'étaient déjà, mais si grossiers qu'ils n'étaient pas adaptés à la production. C'était, à mon avis, 2015 ou 2016. En 2017, Kubernetes est devenu plus ou moins mature - il fallait y migrer.
Et nous avions déjà un conteneur docker. Il y avait PaaS qui utilisait Docker. Pourquoi ne pas essayer les K8? Pourquoi ne pas écrire votre propre déclaration? Murat Kabilov, qui nous est venu d'Avito, a commencé cela comme un projet de sa propre initiative - «jouer» - et le projet «a décollé».
Mais en général, je voulais parler d'AWS. Pourquoi y avait-il un code historiquement lié à AWS ...
Lorsque vous exécutez quelque chose dans Kubernetes, vous devez comprendre que K8s est un tel travail en cours. Il se développe constamment, s'améliore et se brise même périodiquement. Vous devez surveiller attentivement tous les changements dans Kubernetes, vous devez être prêt à vous y plonger et à découvrir comment cela fonctionne en détail - peut-être plus que vous ne le souhaiteriez. Il s'agit, en principe, de toute plateforme sur laquelle vous exécutez vos bases de données ...
Ainsi, lorsque nous avons fait la déclaration, nous avions Postgres, qui fonctionnait avec un volume externe (dans ce cas, EBS, puisque nous travaillions dans AWS). La base de données grandissait, à un moment donné, il a fallu la redimensionner: par exemple, la taille d'origine de l'EBS est de 100 To, la base de données a grandi, maintenant nous voulons faire de l'EBS en 200 To. Comment? Supposons que vous puissiez vider / restaurer vers une nouvelle instance, mais cela est long et avec des temps d'arrêt.
Par conséquent, je voulais un redimensionnement qui étendrait la partition EBS, puis indiquerait au système de fichiers d'utiliser le nouvel espace. Et nous l'avons fait, mais à ce moment-là, Kubernetes n'avait pas d'API pour l'opération de redimensionnement. Depuis que nous avons travaillé sur AWS, nous avons écrit du code pour son API.
Personne ne prend la peine de faire de même pour les autres plates-formes. Il n'y a aucune complication dans la déclaration selon laquelle il ne peut être exécuté que sur AWS, et il ne fonctionnera pas sur tout le reste. Il s'agit en général d'un projet Open Source: si quelqu'un veut accélérer l'émergence de l'utilisation de la nouvelle API, nous sommes les bienvenus. Il y a GitHub , pull-requests - l'équipe Zalando essaie de leur répondre rapidement et de promouvoir l'opérateur. Pour autant que je sache, le projet a participé à Google Summer of Code et à d'autres initiatives similaires. Zalando y est très actif.
Bonus PS!
Si vous êtes intéressé par le sujet de PostgreSQL et Kubernetes, alors nous attirons également l'attention sur le fait que la semaine dernière, le prochain Postgres a eu lieu, où
Alexander Kukushkin de Zalando a parlé avec Nikolai. La vidéo est disponible
ici .
PPS
Lisez aussi dans notre blog: