Aan het einde van het afgelopen jaar vond er een nieuwe live-uitzending van de Russische PostgreSQL-gemeenschap plaats , waar zijn medeoprichter Nikolaj Samochvalov sprak met technisch directeur Dmitri Stolyarov van "Flant" over deze database in de context van Kubernetes.
We publiceren het transcript van het belangrijkste deel van deze discussie, en op is de volledige video opgenomen:
Databases en Kubernetes
NS: We zullen het vandaag niet over VACUUM en CHECKPOINTS hebben. We willen het over Kubernetes hebben. Ik weet dat je al jarenlang ervaring hebt. Ik heb je video's bekeken en sommige zelfs stukje voor stukje herbekeken… Laten we meteen ter zake komen: waarom überhaupt Postgres of MySQL in K8s?
DS: Er is geen eenduidig antwoord op deze vraag en dat kan er ook niet zijn. Maar in wezen is het eenvoud en gemak… potentieel. Iedereen wil toch managed services.
NS: Om het zo te hebben , alleen bij jezelf?
DS: Ja: om het te hebben zoals RDS, maar waar dan ook.
NS: "Waar dan ook" — dat is een goede opmerking. In grote bedrijven is alles op verschillende locaties. Maar waarom zou je, als het een groot bedrijf is, geen kant-en-klaar oplossing nemen? Bijvoorbeeld, Nutanix heeft eigen ontwikkelingen, andere bedrijven (VMware…) hebben dezelfde "RDS, alleen bij jezelf".
DS: Maar dat is iets wat we zeggen over een specifieke implementatie die alleen onder bepaalde omstandigheden werkt. En als we het over Kubernetes hebben, is er een enorme diversiteit aan infrastructuur (die in K8s kan zijn). In wezen is dit de standaard voor de API naar de cloud…
NS: En het is ook gratis!
DS: Dat is niet zo belangrijk. Gratis zijn is niet zo relevant voor een groot segment van de markt. Wat belangrijker is… Je herinner je vast de presentatie over "»?
NS: Ja.
DS: Ik begreep dat deze heel verdeeld werd ontvangen. Een deel van de mensen dacht dat ik zei: "Laten we allemaal databases in Kubernetes gaan gebruiken!", terwijl anderen dachten dat dit allemaal verschrikkelijke fietsen waren. Maar ik wilde eigenlijk iets anders zeggen: "Kijk, wat er gebeurt, welke problemen er zijn en hoe we die kunnen oplossen. Is het nu de tijd om databases in Kubernetes te gebruiken? Productie? Nou, alleen als je houdt van… bepaalde zaken doen. Maar voor development – kan ik zeggen dat ik het aanbeveel. Voor development is de dynamiek van het creëren/verwijderen van omgevingen heel belangrijk."
NS: Bedoel je met development alle omgevingen die niet productie zijn? Staging, QA…
DS: Als we het hebben over perf-standa, dan is dat waarschijnlijk niet meer het geval omdat de eisen specifiek zijn. Als we het hebben over uitzonderlijke gevallen waarbij een zeer grote database op staging nodig is, dan is dat ook waarschijnlijk niet het geval... Als het een statische omgeving is die lang meegaat, wat is dan het voordeel van een database die in K8s is geplaatst?
NS: Geen enkel. Maar waar zien we statische omgevingen? Een statische omgeving is morgen al verouderd.
DS: Staging kan statisch zijn. We hebben klanten...
NS: Ja, die heb ik ook. Het is een groot probleem als je een database van 10 TB hebt, en staging is 200 GB...
DS: Ik heb een heel gaaf geval! Op staging staat de productie-database, waarin veranderingen worden aangebracht. En er is een knop voorzien: «uitrollen naar productie». Deze veranderingen — deltas — worden (het lijkt erop dat ze gewoon via API worden gesynchroniseerd) in productie bijgevoegd. Dit is een erg exotische optie.
NS: Ik heb startups in de Vallei gezien die nog in RDS of zelfs in Heroku zitten — dit zijn verhalen van 2-3 jaar geleden — en ze downloaden een dump naar hun laptop. Omdat de database slechts 80 GB is, en er genoeg ruimte op de laptop is. Daarna kopen ze schijven voor iedereen om drie databases te hebben, zodat ze verschillende ontwikkelingen kunnen uitvoeren. Zo gaat het ook soms. Ook heb ik gezien dat ze niet bang zijn om prod naar staging te kopiëren — dit hangt sterk van het bedrijf af. Maar ik heb ook gezien dat ze erg bang zijn, en dat het vaak aan tijd en handen ontbreekt. Maar voordat we dit onderwerp behandelen, wil ik graag over Kubernetes horen. Begrijp ik goed dat nog niemand het in productie heeft?
DS: We hebben kleine databases in productie. Het gaat om volumes in de tientallen gigabytes en niet-kritische services waarvoor het niet de moeite waard was om replicaties te maken (en er is ook geen behoefte aan). En op voorwaarde dat er normaal opslag beschikbaar is onder Kubernetes. Deze database werkte op een virtuele machine — voor het gemak in VMware, bovenop de SAN. We hebben het geplaatst in en nu kunnen we het van machine naar machine verplaatsen.
NS: Dat soort databases, tot 100 GB, kan je op goede schijven en bij een goed netwerk binnen enkele minuten uitrollen, toch? Een snelheid van 1 GB per seconde is al geen exotisch geval meer.
DS: Ja, voor een lineaire operatie is dat geen probleem.
NS: Oké, we moeten alleen over prod nadenken. En als we Kubernetes voor niet-prod-omgevingen overwegen — hoe doen we dat? Ik zie dat Zalando , in Crunchy , zijn er nog andere opties. En er is — dat is onze goede bekende Alvaro uit Spanje: zij maken in wezen niet alleen een , maar een hele distributie (), waarnaast Postgres ook een back-up en proxy Envoy is gestopt...
DS: Waar is Envoy voor? Voor het balanceren van de Postgres-verkeer?
NS: Ja. Ze zien dit als volgt: als je een Linux-distributie en de kernel neemt, dan is de gewone PostgreSQL de kernel, en ze willen een distributie maken die cloud-vriendelijk is en in Kubernetes kan draaien. Ze verbinden componenten (back-ups, etc.) en optimaliseren ze zodat ze goed functioneren.
DS: Heel gaaf! In wezen is dit software om je eigen beheerde Postgres op te zetten.
NS: Bij Linux-distributies zijn er altijd problemen: hoe je stuurprogramma's maakt zodat alle hardware wordt ondersteund. Hun idee is dat ze in Kubernetes willen werken. Ik weet dat we bij de operator Zalando recent een koppeling met AWS hebben gezien, en dat is al niet zo goed. Er zou toch geen afhankelijkheid van een specifieke infrastructuur moeten zijn — wat is dan de zin?
DS: Ik weet niet in welke situatie Zalando zich specifiek heeft verbonden, maar in Kubernetes is de opslag nu zo gemaakt dat je niet op een generieke manier een schijfback-up kunt maken. Recent is de mogelijkheid voor snapshots in de laatste versie van de standaard toegevoegd, maar waar is het geïmplementeerd? Eerlijk gezegd, het is nog steeds zo onvolwassen... — we proberen CSI boven AWS, GCE, Azure, vSphere, maar zodra je het begint te gebruiken, zie je dat het nog niet klaar is.
NS: Daarom moet je soms afhankelijk zijn van de infrastructuur. Ik denk dat dit nog een vroege fase is — groeiproblemen. Vraag: wat zou je adviseren voor beginners die PgSQL in K8s willen proberen? Welke operator misschien?
DS: Het probleem is dat Postgres voor ons maar 3% is. We hebben nog een lange lijst van andere software in Kubernetes, ik ga het niet eens allemaal opsommen. Bijvoorbeeld, Elasticsearch. Er zijn talloze operators: sommige ontwikkelen zich actief, andere niet. We hebben voor onszelf eisen opgesteld waaraan een operator moet voldoen voordat we het serieus nemen. Een operator voor Kubernetes — niet 'een operator om iets te doen in de omstandigheden van Amazon'... In feite gebruiken we vrij massaal (= bijna al onze klanten) één enkele operator — (we publiceren binnenkort ook een artikel over hem).
NS: Maar is er ook geen voor MySQL? Ik weet dat Percona... omdat ze nu met zowel MySQL, MongoDB als Postgres werken, moeten ze wel iets universeler maken: voor alle databases, voor alle cloudproviders.
DS: We hebben de operators voor MySQL nog niet bekeken. Voor ons is dat momenteel niet de belangrijkste focus. MySQL werkt prima in standalone. Waarom een operator, als je gewoon de database kunt opstarten... Je kunt een Docker-container met Postgres opstarten, of je kunt het op de simpele manier doen.
NS: Daar was ook een vraag over. Helemaal zonder operator?
DS: Ja, in 100% van de gevallen draait onze PostgreSQL zonder operator. Tot nu toe zo. We gebruiken actief een operator voor Prometheus, voor Redis. We hebben plannen om een operator voor Elasticsearch te vinden — dat is het meest dringende, omdat we het in 100% van de gevallen op Kubernetes willen zetten. Net zoals we willen dat MongoDB ook altijd op Kubernetes draait. Er verschijnen bepaalde wensen — er is het gevoel dat we in deze gevallen iets kunnen doen. Maar over Postgres hebben we zelfs niet gekeken. Natuurlijk weten we van het bestaan van verschillende opties, maar feitelijk hebben we standalone.
Database voor testen in Kubernetes
NS: Laten we overgaan naar het onderwerp testen. Hoe pas je wijzigingen in de database toe — vanuit een DevOps-perspectief. Er zijn microservices, veel databases, en er verandert voortdurend iets ergens. Hoe zorg je voor een normale CI/CD, zodat alles vanuit het perspectief van de database in orde is? Wat is jouw aanpak?
DS: Er kan niet één antwoord zijn. Er zijn verschillende parameters. De eerste is de grootte van de database die we willen implementeren. Je noemde al dat bedrijven er verschillend over denken om een kopie van de prod-database op dev en stage te hebben.
NS: Onder GDPR-voorwaarden denk ik dat ze er steeds voorzichtiger mee omgaan... Ik kan je vertellen dat ze al zijn begonnen met boetes in Europa.
DS: Maar vaak kun je software schrijven die een dump van de productie maakt en deze obfusqueert. Je krijgt productiegegevens (snapshot, dump, binaire kopie...), maar ze zijn geanonimiseerd. In plaats daarvan kunnen er ook generatiescripts zijn: dat kunnen fixtures zijn of gewoon een script dat een grote database genereert. Het probleem is: hoe lang duurt het om het basisbeeld te creëren? En hoeveel tijd kost het om het op de juiste omgeving te implementeren?
We zijn tot het schema gekomen: als de klant een fixture-dataset heeft (minimale versie van de database), gebruiken we die standaard. Als het gaat om review-omgevingen, wanneer we een branch hebben aangemaakt, hebben we een instantie van de applicatie opgestart — daar implementeren we een kleine database. Maar het is goed gegaan en , wanneer we eenmaal per dag ( 's nachts) een dump maken van de productie en op basis daarvan een Docker-container met PostgreSQL en MySQL opzetten met deze geladen gegevens. Als we deze afbeelding 50 keer moeten uitrollen, is dat vrij eenvoudig en snel te doen.
NS: Gewoon door te kopiëren?
DS: Gegevens worden rechtstreeks in het Docker-image opgeslagen. Dit betekent dat we een kant-en-klaar image hebben, laten we zeggen van 100 GB. Dankzij de lagen in Docker kunnen we dit image snel het vereiste aantal keren uitrollen. Het is een eenvoudige manier, maar het werkt redelijk goed.
NS: Verder, wanneer je test, verandert het rechtstreeks binnen Docker, klopt dat? Copy-on-write binnen Docker — we gooien het weg en gaan opnieuw verder, alles is goed. Geweldig! En gebruiken jullie dat al volop?
DS: Al een tijd.
NS: We doen heel vergelijkbare dingen. Maar we gebruiken geen Docker copy-on-write, maar een andere methode.
DS: Het is niet generiek. Maar de Docker-versie werkt overal.
NS: In theorie, ja. Maar wij hebben daar ook modules, je kunt verschillende modules maken en met verschillende bestandssystemen werken. Hier is het punt. We kijken vanuit de zijde van Postgres naar dit alles op een andere manier. Nu heb ik het vanuit Docker bekeken en gezien dat alles werkt. Maar als de database enorm is, bijvoorbeeld 1 TB, dan wordt het al langdradig: zowel de bewerkingen 's nachts als het in Docker proppen... En als je 5 TB in Docker moet stoppen... Of gaat alles goed?
DS: Wat maakt het uit: het zijn gewoon blobs, alleen bits en bytes.
NS: Het verschil is: doen jullie dat via dump en restore?
DS: Absoluut niet noodzakelijk. De manieren om dit image te genereren kunnen verschillen.
NS: Voor sommige klanten hebben we het zo gedaan dat we in plaats van regelmatig een basisimage te genereren, dit constant up-to-date houden. Het is in feite een replica, maar de gegevens worden niet rechtstreeks van de master verkregen, maar via een archief. Een binaire archief, waar de WAL's elke dag worden toegevoegd, daar worden ook back-ups gemaakt... Deze WAL's komen later aan — met een kleine vertraging (slechts 1-2 seconden) — bij het basisimage. Van daaruit klonen we op elke mogelijke manier — standaard gebruiken we nu ZFS.
DS: Maar met ZFS ben je beperkt tot één node.
NS: Ja. Maar ZFS heeft ook een magische : waarmee je een snapshot kunt verzenden en zelfs (dit heb ik nog niet echt getest, maar...) kun je de delta tussen twee PGDATA. In feite hebben we nog een hulpmiddel dat we niet echt hebben overwogen voor dergelijke taken. In PostgreSQL is er , werkend als een 'slimme' rsync, dat veel overslaat wat je niet hoeft te bekijken omdat er zeker niets is veranderd. We kunnen een snelle synchronisatie tussen twee servers doen en precies terugrollen.
Dus, we proberen vanaf deze meer DBA-achtige kant een tool te maken die hetzelfde mogelijk maakt als wat je zei: we hebben één database, maar we willen iets 50 keer testen, bijna tegelijkertijd.
DS: 50 keer betekent dat je 50 Spot-instanties moet bestellen.
NS: Nee, we doen alles op één machine.
DS: Maar hoe ga je 50 keer implementeren, als deze ene database, laten we zeggen, een terabyte is? Waarschijnlijk heeft die voorwaardelijk 256 GB RAM nodig?
NS: Ja, soms heb je veel geheugen nodig — dat is normaal. Maar een voorbeeld uit het leven. Op de productie machine 96 kernen en 600 GB. Daarbij worden voor de DB 32 kernen gebruikt (zelfs soms 16 kernen nu) en 100-120 GB geheugen.
DS: En past daar 50 kopieën in?
NS: Maar het is één kopie, daarna werkt copy-on-write (ZFS)... Ik zal meer uitleggen.
Bijvoorbeeld, wij hebben een database van 10 TB. We hebben een schijf hiervoor gemaakt, ZFS heeft het nog met 30-40% gecomprimeerd. Aangezien we geen belastingstest doen, is de exacte responstijd niet belangrijk voor ons: als het tot 2 keer langzamer is — dat is goed.
We geven programmeurs, QA, DBA, etc. de mogelijkheid om tests uit te voeren in 1-2 threads. Ze kunnen bijvoorbeeld een migratie starten. Dit vereist niet meteen 10 kernen — het heeft 1 backend van Postgres nodig, 1 kern. De migratie zal starten — misschien, zal ook starten, dan wordt de tweede kern ingezet. We hebben 16-32 kernen toegewezen, zodat 10 mensen tegelijkertijd kunnen werken, geen probleem.
Aangezien fysiek PGDATA hetzelfde is, blijkt dat we Postgres eigenlijk bedotten. Het trucje is dit: bijvoorbeeld, 10 Postgres-instanties starten tegelijkertijd. Wat is meestal het probleem? Ze stellen , laten we zeggen, op 25%. Bijgevolg is dat 200 GB. Meer dan drie van deze kun je al niet starten, omdat het geheugen op is.
Maar op een gegeven moment realiseerden we ons dat dat niet nodig was: we zetten shared_buffers op 2 GB. PostgreSQL heeft , en in werkelijkheid beïnvloedt alleen dat . Dat zetten we op 0,5 TB. En het doet er niet eens toe dat ze er in werkelijkheid niet zijn: het maakt plannen alsof ze er zijn.
Dus, wanneer we een migratie testen, kunnen we alle plannen verzamelen — we zullen zien hoe het zich zal gedragen in productie. De tijdsduur zal anders zijn (langzamer), maar de gegevens die we daadwerkelijk lezen, evenals de plannen (zoals welke JOINs daar zijn, enzovoort) zijn precies hetzelfde als in productie. Tegelijkertijd kunnen we veel van zulke controles op één machine uitvoeren.
DS: Denk je niet dat er hier een paar problemen zijn? Ten eerste is dit een oplossing die alleen op PostgreSQL werkt. Deze aanpak is heel specifiek, niet generiek. Ten tweede gaat Kubernetes (en alles waar cloudtechnologie momenteel naartoe gaat) uit van meerdere knooppunten, en deze knooppunten zijn efemere. En in jouw geval is het een stateful, persistente knoop. Deze dingen roepen tegenstrijdigheden bij me op.
NS: Ten eerste ben ik het ermee eens, dit is puur een PostgreSQL-kwestie. Ik denk dat als we enige directe I/O en een bufferpool bijna voor het volledige geheugen hebben, deze aanpak niet geschikt is — de plannen zullen anders zijn. Maar we werken momenteel alleen met PostgreSQL en denken nog niet aan andere.
Over Kubernetes. Je vertelt zelf overal dat onze database persistent is. Als een instantie crasht, is het belangrijkste om de schijf te behouden. Onze gehele platform draait ook op Kubernetes, en de component met PostgreSQL is apart (hoewel die daar ooit ook zal zijn). Dus het is zo: de instantie is gecrasht, maar we hebben zijn PV behouden en gewoon aangesloten op een andere (nieuwe) instantie, alsof er niets is gebeurd.
DS: Vanuit mijn perspectief creëren we pods in Kubernetes. K8s is elastisch: knooppunten worden automatisch besteld naarmate dat nodig is. De taak is eenvoudig: maak gewoon een pod en geef aan dat het X middelen nodig heeft, en verder regelt K8s de rest zelf. Maar de ondersteuning van opslagsystemen in Kubernetes is nog steeds onbetrouwbaar: in , in (deze release is uitgebracht weken geleden) worden deze functies alleen maar in bèta.
Over een half jaar tot een jaar zal het meer of minder stabiel zijn, of tenminste als zodanig worden verklaard. Dan lost de mogelijkheid van snapshots en resizing jullie probleem volledig op. Want jullie hebben een database. Ja, deze kan niet erg snel zijn, maar de snelheid hangt af van wat er 'onder de motorkap' gebeurt, omdat sommige implementaties kopieën en copy-on-write op het niveau van de schijfsubsystemen kunnen doen.
NS: Dan moeten alle engines (Amazon, Google...) ook deze versie snel gaan ondersteunen — dat kost ook tijd.
DS: Tot nu toe gebruiken we ze niet. We gebruiken de onze.
Lokale ontwikkeling voor Kubernetes
NS: Heb je wel eens het verlangen gehad om op één machine alle pods op te zetten en een kleine test uit te voeren? Om snel een proof of concept te krijgen en te zien of de applicatie werkt in Kubernetes, zonder daarvoor een heleboel machines toe te wijzen. Er is Minikube, toch?
DS: Ik denk dat dit geval — alles op één knooppunt implementeren — uitsluitend over lokale ontwikkeling gaat. Of sommige uitings van zo'n patroon. Er zijn , er is , . We gaan gebruiken maken van Kubernetes IN Docker. We zijn daar nu mee begonnen voor tests.
NS: Ik dacht eerder dat het een poging was om alle pods in één Docker-image te verpakken. Maar het bleek iets heel anders te zijn. Er zijn toch aparte containers, aparte pods — gewoon in Docker.
DS: Ja. En daar is een best leuke simulatie gemaakt, maar het idee is zo… We hebben een tool voor deployment — . We willen daarin een modus maken — bij wijze van spreken werf up: ‘Verhoog mijn lokale Kubernetes’. En dan een hypothetische werf follow. Dan kan de ontwikkelaar aanpassen in de IDE, terwijl in het systeem een proces draait dat de wijzigingen opmerkt en de images opnieuw bouwt en deze opnieuw deploïeert in de lokale K8s. Zo willen we proberen het probleem van lokale ontwikkeling op te lossen.
Snapshots en klonen van databases in de realiteit van K8s
NS: Als we teruggaan naar copy-on-write. Ik merkte dat cloud aanbieders ook snapshots hebben. Ze werken op verschillende manieren. Bijvoorbeeld in GCP: je hebt een multiterabyte instance aan de oostkust van de VS. Je maakt regelmatig snapshots. Je maakt een kopie van de schijf vanuit een snapshot aan de westkust — binnen enkele minuten is alles klaar, het werkt heel snel, je moet alleen de cache in het geheugen vullen. Maar deze klonen (snapshots) — zijn om een nieuwe schijf te ‘provisionen’. Het is geweldig wanneer je veel instanties moet creëren.
Maar voor tests, denk ik, zijn de snapshots waar je over praat in Docker of waar ik over praat in ZFS, btrfs en zelfs LVM… — ze maken het mogelijk om op één machine geen nieuwe data te genereren. In de cloud moet je er bovendien elke keer voor betalen en wachten niet seconden, maar minuten (en in het geval van , mogelijk zelfs uren).
In plaats daarvan kun je deze data in een seconde of twee verkrijgen, de test draaien en weggooien. Deze snapshots lossen verschillende problemen op. In het eerste geval — om te schalen en nieuwe replicas te krijgen, en in het tweede — voor tests.
DS: Ik ben het daar niet mee eens. Het normaal klonen van volumes is een taak voor de cloud. Ik heb hun implementatie niet bekeken, maar ik weet hoe wij dit op hardware doen. We hebben Ceph, daarin kan je elke fysieke schijf(,) zeggen clone en binnen enkele tientallen milliseconden een tweede schijf met dezelfde specificaties krijgen, enzovoort. Je moet begrijpen dat daar binnen een slimme copy-on-write is. Waarom zou de cloud het niet op dezelfde manier doen? Ik ben er zeker van dat ze het op de een of andere manier proberen te realiseren.
NS: Maar ze zullen toch seconden, tientallen seconden nodig hebben om een instantie op te starten, Docker daarheen te brengen, enzovoort.
DS: Waarom moet je een hele instantie opstarten? We hebben immers een instantie met 32 cores, met 16… en daarin kunnen er een aantal passen — bijvoorbeeld vier. Wanneer we de vijfde aanvragen, wordt er al een instantie opgestart, en daarna wordt deze weer verwijderd.
NS: Ja, interessant, in Kubernetes blijkt het een ander verhaal te zijn. Onze database is niet in K8s, en er is slechts één instantie. Maar voor het klonen van een multiterabyte database is niet meer dan twee seconden nodig.
DS: Dat is geweldig. Maar mijn oorspronkelijke punt is dat dit geen generieke oplossing is. Ja, het is geweldig, maar het is alleen geschikt voor Postgres en alleen op één knooppunt.
NS: Het is niet alleen geschikt voor Postgres: dit zijn plannen, zoals ik al beschreef, die alleen daarmee zullen werken. Maar als we ons niet druk maken over plannen, en we gewoon alle gegevens nodig hebben voor functionele testdoeleinden, dan is dit geschikt voor elke DBMS.
DS: Jaren geleden deden we iets vergelijkbaars met LVM-snapshots. Dat is klassiek. Deze aanpak werd heel actief gebruikt. Gewoon stateful knooppunten zijn een probleem. Want je moet ze niet laten vallen, altijd aan ze denken…
NS: Zie jij hier niet een mogelijkheid voor een hybride? Stel, stateful is een pod, deze werkt voor verschillende mensen (veel testers). We hebben één volume, maar dankzij het bestandssysteem zijn de klonen lokaal. Als de pod crasht, blijft de schijf bestaan — de pod start opnieuw op, leest informatie over alle klonen, herstelt alles en zegt: 'Hier zijn je klonen op deze poorten gestart, werk maar verder met hen.'.
DS: Technisch betekent dit dat dit binnen Kubernetes één pod is, waarin we veel Postgres'en draaien.
NS: Ja. Hij heeft een limiet: stel dat er tegelijkertijd niet meer dan 10 mensen mee werken. Als er 20 nodig zijn — zetten we een tweede dergelijke pod op. Volledig mogelijk om deze te klonen, waardoor we een tweede volledige schijf krijgen, met daarop dezelfde 10 'dunne' klonen. Zie jij die mogelijkheid niet?
DS: We need to add security questions here. This organizational option implies that this pod has high privileges (capabilities) because it can perform non-standard operations on the file system… But I’ll repeat: I believe that in the medium term, Kubernetes will fix storage, and clouds will resolve all the issues with volumes — everything will work 'just fine.' There will be resizing, cloning… There's a volume — we say: 'Create a new one based on this,' — and in a second and a half, we get what we need.
NS: I don't believe in a second and a half for many terabytes. In Ceph, you do it yourself, but you are talking about clouds. Go to the cloud, clone an EBS volume of many terabytes on EC2 and see what kind of performance you get. It won't take a few seconds. I'm really curious to see when they reach that level. I understand what you’re saying, but I’ll allow myself to disagree.
DS: Okay, but I said in the medium term, not in the short term. Over the next few years.
About the PostgreSQL operator from Zalando
In the middle of this meeting, Alexey Klyukin, a former developer from Zalando, also joined to talk about the story of the PostgreSQL operator:
It's great that this topic is being addressed: both Postgres and Kubernetes. When we started working on it at Zalando in 2017, it was a topic that everyone wanted to engage with, but no one was doing. Everyone was already getting Kubernetes, but when asked how to handle databases, even people like , who preached K8s, said approximately the following:
"Go to managed services and use them, don’t run databases in Kubernetes. Otherwise, your K8s might decide to upgrade, take down all nodes, and your data will be gone far, far away."
We decided to create an operator that would, despite this advice, run Postgres databases in Kubernetes. And we had a good basis — . This is a proper automatic failover for PostgreSQL, i.e., using etcd, consul, or ZooKeeper as a storage for cluster information. Such storage that will provide everyone who asks, for instance, who the current leader is, with the same information — despite the fact that we are all distributed — to avoid split brain. Plus, we had ervoor.
Eigenlijk ontstond de behoefte aan auto failover voor het bedrijf na de migratie van een interne datacenter naar de cloud. De cloud was gebaseerd op een eigen PaaS (Platform-as-a-Service) oplossing. Het is Open Source, maar om het op te zetten moest er veel werk verzet worden. Het heette .
In het begin was er helemaal geen Kubernetes. Of beter gezegd, toen de eigen oplossing werd opgezet, was K8s al beschikbaar, maar zo onvolwassen dat het niet geschikt was voor productie. Dit was volgens mij in 2015 of 2016. Tegen 2017 was Kubernetes min of meer volwassen geworden - er ontstond behoefte om daarheen te migreren.
En we hadden al een Docker-container. Er was een PaaS die Docker gebruikte. Waarom niet K8s proberen? Waarom niet onze eigen operator schrijven? Murat Kabilov, die bij ons kwam vanuit Avito, begon dit als een vrijwilligersproject - "spelen" - en het project "steeg op".
Maar eigenlijk wilde ik vertellen over AWS. Waarom er historisch gezien code was die verband hield met AWS...
Wanneer je iets in Kubernetes start, moet je begrijpen dat K8s een work in progress is. Het ontwikkelt zich voortdurend, verbetert en soms gaat het zelfs kapot. Je moet goed letten op alle veranderingen in Kubernetes, en bereid zijn om je erin te verdiepen en te leren hoe het in detail werkt - mogelijk meer dan je zou willen. Dit geldt in principe voor elk platform waarop je je databases draait...
Dus, toen we de operator maakten, hadden we Postgres dat werkte met een externe schijf (in dit geval EBS, aangezien we in AWS werkten). De database groeide en op een gegeven moment was een resize nodig: bijvoorbeeld, de oorspronkelijke grootte van EBS was 100 TB, de database had deze grootte bereikt, en nu willen we EBS naar 200 TB vergroten. Hoe? Je kunt een dump/restore naar een nieuwe instantie maken, maar dat duurt lang en leidt tot downtime.
Daarom wilden we een resize die het EBS-volume vergroot en de bestandssystemen vertelt het nieuwe ruimte te gebruiken. En dat hebben we gedaan, maar op dat moment had Kubernetes geen API voor de resize-operatie. Aangezien we op AWS werkten, schreven we code voor hun API.
Niemand staat in de weg om hetzelfde te doen voor andere platforms. In de operator is er geen beperking dat deze alleen op AWS kan worden uitgevoerd, en niet op andere platforms. Kortom, dit is een Open Source-project: als iemand de implementatie van een nieuwe API wil versnellen - voel je vrij. , pull-requests — het Zalando-team probeert er vrij snel op te reageren en de operator te bevorderen. Voor zover ik weet, heeft het project aan Google Summer of Code en andere soortgelijke initiatieven. Zalando werkt hier heel actief aan.
P.S. Bonus!
Als je geïnteresseerd bent in het onderwerp PostgreSQL en Kubernetes, willen we ook uw aandacht vestigen op de afgelopen Postgres-dinsdag, waar Nikolai sprak met Alexander Kukushkin van Zalando. De video ervan is beschikbaar .
P.P.S.
Lees ook op onze blog:
- «»;
- «»;
- «»;
- «».
Bron: habr.com
