Eind vorig jaar vond er weer een live-uitzending plaats van de Russische PostgreSQL-gemeenschap , waarin mede-oprichter Nikolai Samokhvalov met Flant technisch directeur Dmitry Stolyarov sprak over dit DBMS in de context van Kubernetes.
We publiceren een transcriptie van het grootste deel van deze discussie, en op Volledige video geplaatst:
Databases en Kubernetes
NS: We zullen het vandaag niet hebben over VACUÜM en CHECKPOINTs. We willen het hebben over Kubernetes. Ik weet dat je vele jaren ervaring hebt. Ik heb je video's bekeken en sommige zelfs opnieuw bekeken... Laten we maar meteen met de deur in huis vallen: waarom Postgres of MySQL überhaupt in K8s?
DS: Er is geen definitief antwoord op deze vraag en dat kan ook niet. Maar over het algemeen is dit eenvoud en gemak... potentieel. Iedereen wil beheerde services.
NS: Naar hoe , alleen thuis?
DS: Ja: zoals RDS, gewoon overal.
NS: “Overal” is een goed punt. Bij grote bedrijven bevindt alles zich op verschillende plekken. Waarom dan, als het een groot bedrijf is, niet voor een kant-en-klare oplossing kiezen? Nutanix heeft bijvoorbeeld eigen ontwikkelingen, andere bedrijven (VMware…) hebben dezelfde ‘RDS, alleen thuis’.
DS: Maar we hebben het over een aparte implementatie die alleen onder bepaalde voorwaarden zal werken. En als we het over Kubernetes hebben, dan is er een enorme verscheidenheid aan infrastructuur (die zich in K8s kan bevinden). In wezen is dit een standaard voor API's naar de cloud...
NS: Het is ook gratis!
DS: Het is niet zo belangrijk. Vrijheid is voor een niet heel groot deel van de markt van belang. Er is nog iets belangrijks... U herinnert zich waarschijnlijk het rapport “"?
NS: Ja.
DS: Ik besefte dat het zeer dubbelzinnig werd ontvangen. Sommige mensen dachten dat ik zei: “Jongens, laten we alle databases in Kubernetes stoppen!”, terwijl anderen besloten dat dit allemaal verschrikkelijke fietsen waren. Maar ik wilde iets heel anders zeggen: “Kijk wat er gebeurt, welke problemen er zijn en hoe die opgelost kunnen worden. Moeten we nu Kubernetes-databases gebruiken? Productie? Nou ja, alleen als je bepaalde dingen graag doet. Maar voor een ontwikkelaar kan ik zeggen dat ik het aanbeveel. Voor een ontwikkelaar is de dynamiek van het creëren/verwijderen van omgevingen erg belangrijk.”
NS: Bedoel je met ontwikkelaar alle omgevingen die niet productief zijn? Staging, kwaliteit…
DS: Als we het hebben over perf-stands, dan waarschijnlijk niet, omdat de eisen daar specifiek zijn. Als we het hebben over speciale gevallen waarin een zeer grote database nodig is voor staging, dan waarschijnlijk niet... Als dit een statische, langlevende omgeving is, wat is dan het voordeel als de database zich in K8s bevindt?
NS: Geen. Maar waar zien we statische omgevingen? Een statische omgeving zal morgen verouderd zijn.
DS: Staging kan statisch zijn. Wij hebben klanten...
NS: Ja, die heb ik ook. Het is een groot probleem als je een database van 10 TB en staging van 200 GB hebt...
DS: Ik heb een heel cool hoesje! Op de staging bevindt zich een productdatabase waarin wijzigingen worden aangebracht. En er is een knop: “uitrollen naar productie”. Deze wijzigingen - delta's - worden in productie toegevoegd (het lijkt erop dat ze eenvoudigweg worden gesynchroniseerd via de API). Dit is een zeer exotische optie.
NS: Ik heb startups in de Valley gezien die in RDS of zelfs in Heroku zitten - dit zijn verhalen van 2-3 jaar geleden - en zij downloaden de dump naar hun laptop. Omdat de database nog steeds maar 80 GB groot is, en er ruimte is op de laptop. Vervolgens kopen ze voor iedereen extra schijven zodat ze 3 databases hebben om verschillende ontwikkelingen uit te voeren. Dit is ook hoe het gebeurt. Ik zag ook dat ze niet bang zijn om prod naar de enscenering te kopiëren - het hangt heel erg van het bedrijf af. Maar ik zag ook dat ze heel bang zijn, en dat ze vaak niet genoeg tijd en handen hebben. Maar voordat we verder gaan met dit onderwerp, wil ik iets over Kubernetes horen. Begrijp ik het goed dat er nog niemand in productie is?
DS: We hebben kleine databases in prod. We hebben het over volumes van tientallen gigabytes en niet-kritieke services waarvoor we te lui waren om replica's te maken (en die noodzaak bestaat niet). En op voorwaarde dat er sprake is van normale opslag onder Kubernetes. Deze database werkte in een virtuele machine - voorwaardelijk in VMware, bovenop het opslagsysteem. Wij hebben het erin geplaatst en nu kunnen we het van machine naar machine overbrengen.
NS: Databases van deze omvang, tot 100 GB, kunnen in een paar minuten worden uitgerold op goede schijven en een goed netwerk, toch? Een snelheid van 1 GB per seconde is niet langer exotisch.
DS: Ja, voor lineaire werking is dit geen probleem.
NS: Oké, we moeten gewoon aan prod denken. En als we Kubernetes overwegen voor niet-productieomgevingen, wat moeten we dan doen? Dat zie ik bij Zalando , in knapperig , er zijn nog enkele andere opties. En daar is - dit is onze goede vriend Alvaro uit Spanje: wat ze doen is in wezen niet rechtvaardig , en de hele distributie (), waarin ze naast Postgres zelf ook besloten een back-up te proppen, de Envoy-proxy...
DS: Gezant voor wat? Specifiek Postgres-verkeer in evenwicht brengen?
NS: Ja. Dat wil zeggen, ze zien het als: als je een Linux-distributie en -kernel neemt, dan is gewone PostgreSQL de kernel, en ze willen een distributie maken die cloudvriendelijk is en op Kubernetes draait. Ze stellen componenten samen (back-ups, enz.) en debuggen deze zodat ze goed werken.
DS: Heel cool! In wezen is dit software om uw eigen beheerde Postgres te maken.
NS: Linux-distributies hebben eeuwige problemen: hoe maak je stuurprogramma's zodat alle hardware wordt ondersteund. En ze hebben het idee dat ze in Kubernetes gaan werken. Ik weet dat we bij de Zalando-operator onlangs een verbinding met AWS hebben gezien en dat deze niet meer zo goed is. Er mag geen verbinding zijn met een specifieke infrastructuur - wat heeft het dan voor zin?
DS: Ik weet niet precies in welke situatie Zalando terecht is gekomen, maar in Kubernetes is de opslag nu zo gemaakt dat het onmogelijk is om op een generieke manier een schijfback-up te maken. Recentelijk in standaard - in de nieuwste versie — we hebben snapshots mogelijk gemaakt, maar waar wordt dit geïmplementeerd? Eerlijk gezegd is alles nog zo rauw... We proberen CSI bovenop AWS, GCE, Azure, vSphere, maar zodra je het gaat gebruiken, zie je dat het nog niet klaar is.
NS: Daarom zijn we soms afhankelijk van infrastructuur. Ik denk dat dit nog in een vroeg stadium is: groeipijnen. Vraag: Welk advies zou je geven aan nieuwelingen die PgSQL in K8s willen proberen? Welke exploitant misschien?
DS: Het probleem is dat Postgres voor ons 3% is. We hebben ook een hele grote lijst met verschillende software in Kubernetes, ik zal niet eens alles opsommen. Bijvoorbeeld Elasticsearch. Er zijn veel operators: sommige ontwikkelen zich actief, andere niet. Wij hebben voor onszelf eisen opgesteld over wat een operator moet hebben om het serieus te kunnen nemen. In een operator specifiek voor Kubernetes - niet in een “operator om iets te doen in de omstandigheden van Amazon”... In feite gebruiken we vrij algemeen (= bijna alle klanten) één enkele operator - (we zullen binnenkort een artikel over hem publiceren).
NS: En ook niet voor MySQL? Ik weet dat Percona... aangezien ze nu werken aan MySQL, MongoDB en Postgres, ze een soort universele oplossing zullen moeten creëren: voor alle databases, voor alle cloudproviders.
DS: We hadden geen tijd om naar de operators voor MySQL te kijken. Dit is op dit moment niet onze voornaamste focus. MySQL werkt prima standalone. Waarom een operator gebruiken als je gewoon een database kunt starten... Je kunt een Docker-container starten met Postrges, of je kunt deze op een eenvoudige manier starten.
NS: Hier was ook een vraag over. Helemaal geen operator?
DS: Ja, 100% van ons gebruikt PostgreSQL zonder operator. Tot nu toe. We gebruiken de operator actief voor Prometheus en Redis. We hebben plannen om een operator voor Elasticsearch te vinden - het is degene die het meest "in brand" staat, omdat we deze in 100% van de gevallen in Kubernetes willen installeren. Net zoals we ervoor willen zorgen dat MongoDB ook altijd in Kubernetes geïnstalleerd wordt. Hier verschijnen bepaalde wensen - er is een gevoel dat er in deze gevallen iets gedaan kan worden. En dan hebben we niet eens naar Postgres gekeken. Natuurlijk weten we dat er verschillende opties zijn, maar in feite hebben we een standalone.
DB voor testen in Kubernetes
NS: Laten we verder gaan met het onderwerp testen. Hoe u wijzigingen in de database kunt uitrollen - vanuit een DevOps-perspectief. Er zijn microservices, veel databases, er verandert voortdurend ergens iets. Hoe u een normale CI/CD kunt garanderen, zodat alles vanuit DBMS-perspectief in orde is. Wat is jouw aanpak?
DS: Er kan niet één antwoord zijn. Er zijn verschillende opties. De eerste is de grootte van de basis die we willen uitrollen. U zei zelf dat bedrijven verschillende houdingen hebben ten opzichte van het hebben van een kopie van de productdatabase op het gebied van ontwikkeling en podium.
NS: En onder de voorwaarden van de AVG denk ik dat ze steeds voorzichtiger zijn... Ik kan zeggen dat ze in Europa al begonnen zijn met het opleggen van boetes.
DS: Maar vaak kun je software schrijven die een dump uit de productie haalt en deze verdoezelt. Prod-gegevens worden verkregen (momentopname, dump, binaire kopie...), maar deze worden geanonimiseerd. In plaats daarvan kunnen er generatiescripts zijn: dit kunnen armaturen zijn of gewoon een script dat een grote database genereert. Het probleem is: hoe lang duurt het om een basisimage te maken? En hoe lang duurt het voordat het in de gewenste omgeving wordt ingezet?
We kwamen tot een schema: als de klant een vaste dataset heeft (minimale versie van de database), dan gebruiken we deze standaard. Als we het hebben over beoordelingsomgevingen, hebben we, toen we een filiaal creëerden, een exemplaar van de applicatie geïmplementeerd - we rolden daar een kleine database uit. Maar het pakte goed uit , wanneer we eenmaal per dag ('s nachts) een dump uit de productie nemen en een Docker-container bouwen met PostgreSQL en MySQL met deze geladen gegevens daarop gebaseerd. Als u de database vanaf deze afbeelding 50 keer wilt uitbreiden, gebeurt dit heel eenvoudig en snel.
NS: Door eenvoudig kopiëren?
DS: gegevens worden rechtstreeks in de Docker-image opgeslagen. Die. We hebben een kant-en-klare afbeelding, zij het 100 GB. Dankzij lagen in Docker kunnen we deze afbeelding snel zo vaak inzetten als we nodig hebben. De methode is stom, maar werkt goed.
NS: Als je vervolgens test, verandert het rechtstreeks in Docker, toch? Copy-on-write in Docker - gooi het weg en ga opnieuw, alles is in orde. Klas! En maak jij er al optimaal gebruik van?
DS: Voor een lange tijd.
NS: Wij doen zeer soortgelijke dingen. Alleen gebruiken wij niet de copy-on-write van Docker, maar een andere.
DS: Het is niet algemeen. En Docker werkt overal.
NS: In theorie wel. Maar we hebben daar ook modules, je kunt verschillende modules maken en met verschillende bestandssystemen werken. Wat een moment hier. Van de kant van Postgres kijken we hier anders naar. Nu keek ik vanaf de Docker-kant en zag dat alles voor jou werkt. Maar als de database enorm is, bijvoorbeeld 1 TB, dan duurt dit allemaal lang: nachtelijke operaties en alles in Docker proppen... En als er 5 TB in Docker wordt gestopt... Of is alles in orde?
DS: Wat is het verschil: dit zijn blobs, alleen maar bits en bytes.
NS: Het verschil is dit: doe je het via dumpen en herstellen?
DS: Helemaal niet nodig. De methoden voor het genereren van deze afbeelding kunnen verschillen.
NS: Voor sommige klanten hebben we het zo gemaakt dat we, in plaats van regelmatig een basisimage te genereren, deze voortdurend up-to-date houden. Het is in wezen een replica, maar ontvangt gegevens niet rechtstreeks van de master, maar via een archief. Een binair archief waar elke dag WAL's worden gedownload, waar back-ups worden gemaakt... Deze WAL's bereiken vervolgens met een kleine vertraging (letterlijk 1-2 seconden) de basisimage. We klonen er op welke manier dan ook van - nu hebben we standaard ZFS.
DS: Maar met ZFS ben je beperkt tot één knooppunt.
NS: Ja. Maar ZFS heeft ook iets magisch : hiermee kun je een snapshot sturen en zelfs (ik heb dit nog niet echt getest, maar...) je kunt een delta tussen twee sturen PGDATA. In feite hebben we nog een ander hulpmiddel dat we voor dergelijke taken niet echt hebben overwogen. PostgreSQL heeft , die werkt als een ‘slimme’ rsync, waarbij veel van wat je niet hoeft te bekijken wordt overgeslagen, omdat daar niets is veranderd. We kunnen een snelle synchronisatie tussen de twee servers uitvoeren en op dezelfde manier terugspoelen.
Dus vanuit deze, meer DBA-kant, proberen we een tool te maken waarmee we hetzelfde kunnen doen als wat je zei: we hebben één database, maar we willen iets 50 keer testen, bijna tegelijkertijd.
DS: 50 keer betekent dat u 50 Spot-exemplaren moet bestellen.
NS: Nee, we doen alles op één machine.
DS: Maar hoe ga je 50 keer uitbreiden als deze ene database bijvoorbeeld terabyte groot is? Hoogstwaarschijnlijk heeft ze voorwaardelijk 256 GB RAM nodig?
NS: Ja, soms heb je veel geheugen nodig - dat is normaal. Maar dit is een voorbeeld uit het leven. De productiemachine heeft 96 kernen en 600 GB. Tegelijkertijd worden 32 cores (soms zelfs 16 cores) en 100-120 GB geheugen gebruikt voor de database.
DS: En daar passen 50 exemplaren in?
NS: Er is dus maar één kopie, dan werkt copy-on-write (ZFS)... Ik zal het je in meer detail vertellen.
We hebben bijvoorbeeld een database van 10 TB. Ze hebben er een schijf voor gemaakt, ZFS heeft de grootte ook met 30-40 procent gecomprimeerd. Omdat we geen belastingtesten doen, is de exacte responstijd voor ons niet belangrijk: laat het tot 2 keer langzamer zijn - dat is oké.
We geven de mogelijkheid aan programmeurs, QA, DBA, etc. voer tests uit in 1-2 threads. Ze kunnen bijvoorbeeld een soort migratie uitvoeren. Het vereist geen 10 cores tegelijk - het heeft 1 Postgres-backend en 1 core nodig. De migratie zal beginnen - misschien nog steeds start, dan wordt de tweede kern gebruikt. We hebben 16-32 kernen toegewezen, dus 10 mensen kunnen tegelijkertijd werken, geen probleem.
Omdat fysiek PGDATA hetzelfde blijkt dat we eigenlijk Postgres bedriegen. De truc is dit: er worden bijvoorbeeld 10 Postgres tegelijkertijd gelanceerd. Wat is meestal het probleem? Ze zetten , laten we zeggen 25%. Dit is dus 200 GB. Je zult niet meer dan drie hiervan kunnen starten, omdat het geheugen dan vol raakt.
Maar op een gegeven moment beseften we dat dit niet nodig was: we stelden shared_buffers in op 2 GB. PostgreSQL heeft , en in werkelijkheid is het de enige die invloed heeft . We hebben het ingesteld op 0,5 TB. En het maakt niet eens uit dat ze niet bestaan: hij maakt plannen alsof ze bestaan.
Dienovereenkomstig kunnen we, wanneer we een of andere vorm van migratie testen, alle plannen verzamelen - we zullen zien hoe het in de productie zal gebeuren. De seconden daar zullen anders zijn (langzamer), maar de gegevens die we daadwerkelijk lezen, en de plannen zelf (welke JOIN's zijn er, etc.) blijken precies hetzelfde als in productie. En u kunt veel van dergelijke controles parallel op één machine uitvoeren.
DS: Denk je niet dat er hier een paar problemen zijn? De eerste is een oplossing die alleen op PostgreSQL werkt. Deze benadering is zeer persoonlijk en niet generiek. De tweede is dat Kubernetes (en alles wat cloudtechnologieën nu gaan doen) veel knooppunten omvat, en deze knooppunten zijn kortstondig. En in jouw geval is het een stateful, persistent knooppunt. Deze dingen zorgen ervoor dat ik in conflict ben.
NS: Ten eerste ben ik het ermee eens dat dit een puur Postgres-verhaal is. Ik denk dat als we een soort directe IO en een bufferpool hebben voor bijna al het geheugen, deze aanpak niet zal werken - de plannen zullen anders zijn. Maar voorlopig werken we alleen met Postgres, we denken niet aan anderen.
Over Kubernetes. U vertelt ons zelf overal dat we een persistente database hebben. Als de instantie mislukt, is het belangrijkste om de schijf op te slaan. Hier hebben we ook het hele platform in Kubernetes, en het onderdeel met Postgres is apart (al zal het er ooit wel zijn). Daarom is alles zo: de instantie viel, maar we hebben de PV bewaard en deze eenvoudigweg met een andere (nieuwe) instantie verbonden, alsof er niets was gebeurd.
DS: Vanuit mijn oogpunt maken we pods in Kubernetes. K8s - elastisch: knopen worden naar behoefte besteld. De taak is om eenvoudigweg een pod te maken en te zeggen dat deze een X-hoeveelheid bronnen nodig heeft, en dan zal K8s het zelf uitzoeken. Maar opslagondersteuning in Kubernetes is nog steeds onstabiel: In (deze uitgave is uitgebracht недели geleden) worden deze functies slechts een bètaversie.
Er zullen zes maanden tot een jaar verstrijken - het zal min of meer stabiel worden, of in ieder geval als zodanig worden verklaard. Dan lost de mogelijkheid van snapshots en formaatwijzigingen uw probleem volledig op. Omdat je een basis hebt. Ja, het is misschien niet erg snel, maar de snelheid hangt af van wat zich “onder de motorkap” bevindt, omdat sommige implementaties kunnen kopiëren en kopiëren tijdens schrijven op schijfsubsysteemniveau.
NS: Het is ook noodzakelijk dat alle zoekmachines (Amazon, Google...) deze versie gaan ondersteunen - dit kost ook enige tijd.
DS: Wij gebruiken ze nog niet. Wij gebruiken de onze.
Lokale ontwikkeling voor Kubernetes
NS: Ben je zo'n wens tegengekomen als je alle pods op één machine moet installeren en zo'n kleine test moet doen? Om snel een proof of concept te krijgen, moet je ervoor zorgen dat de applicatie in Kubernetes draait, zonder er een hele reeks machines voor te gebruiken. Er is Minikube, toch?
DS: Het lijkt mij dat deze casus – ingezet op één knooppunt – uitsluitend over lokale ontwikkeling gaat. Of enkele manifestaties van een dergelijk patroon. Eten Er , . We zijn op weg naar het gebruik van Kubernetes IN Docker. Nu zijn we ermee aan de slag gegaan voor tests.
NS: Ik dacht altijd dat dit een poging was om alle pods in één Docker-image te verpakken. Maar het bleek dat dit over iets heel anders gaat. Hoe dan ook, er zijn afzonderlijke containers, afzonderlijke pods – alleen in Docker.
DS: Ja. En er is een nogal grappige imitatie gemaakt, maar de betekenis is dit... We hebben een hulpprogramma voor implementatie - . We willen er een voorwaardelijke modus van maken werf up: “Geef mij lokale Kubernetes.” En voer vervolgens de voorwaardelijke daar uit werf follow. Vervolgens kan de ontwikkelaar de IDE bewerken en wordt er een proces in het systeem gestart dat de wijzigingen ziet en de afbeeldingen opnieuw opbouwt en deze opnieuw implementeert op lokale K8's. Zo willen wij proberen het probleem van de lokale ontwikkeling op te lossen.
Snapshots en databaseklonen in de realiteit van K8
NS: Als we terugkeren naar copy-on-write. Ik merkte dat de wolken ook momentopnamen hebben. Ze werken anders. In GCP heeft u bijvoorbeeld een exemplaar van meerdere terabytes aan de oostkust van de Verenigde Staten. Je maakt periodiek snapshots. Je haalt een kopie van de schijf aan de westkust op uit een momentopname - binnen een paar minuten is alles klaar, het werkt heel snel, alleen de cache hoeft in het geheugen te worden gevuld. Maar deze klonen (snapshots) zijn bedoeld om een nieuw volume te 'proberen'. Dit is cool als je veel instanties moet maken.
Maar voor tests lijkt het mij dat snapshots, waar je het over hebt in Docker of waar ik het over heb in ZFS, btrfs en zelfs LVM... - je in staat stellen om niet echt nieuwe gegevens op één machine te creëren. In de cloud betaal je er nog steeds elke keer voor en wacht je geen seconden, maar minuten (en in het geval , mogelijk een horloge).
In plaats daarvan kunt u deze gegevens binnen een seconde of twee verkrijgen, de test uitvoeren en weggooien. Deze snapshots lossen verschillende problemen op. In het eerste geval - om op te schalen en nieuwe replica's te krijgen, en in het tweede - voor tests.
DS: Ik ben het er niet mee eens. Het klonen van volumes goed laten werken is de taak van de cloud. Ik heb niet naar de implementatie ervan gekeken, maar ik weet hoe we het op hardware doen. We hebben Ceph, het staat elk fysiek volume toe () inspraak klonen en binnen tientallen milliseconden een tweede volume met dezelfde kenmerken krijgen, 'ami, enz. Je moet begrijpen dat er een lastige copy-on-write in zit. Waarom zou de cloud niet hetzelfde doen? Ik weet zeker dat ze dit op de een of andere manier proberen te doen.
NS: Maar het duurt nog steeds seconden, tientallen seconden om een instantie op te roepen, Docker daarheen te brengen, enz.
DS: Waarom is het nodig om een hele instantie op te roepen? We hebben een instance met 32 cores, 16... en daar passen er bijvoorbeeld vier in. Wanneer we de vijfde bestellen, wordt de instantie al verhoogd en vervolgens verwijderd.
NS: Ja interessant, Kubernetes blijkt een ander verhaal te zijn. Onze database bevindt zich niet in K8s en we hebben één exemplaar. Maar het klonen van een database van meerdere terabytes duurt niet meer dan twee seconden.
DS: Dit is geweldig. Maar mijn eerste punt is dat dit geen generieke oplossing is. Ja, het is cool, maar het is alleen geschikt voor Postgres en slechts op één knooppunt.
NS: Het is niet alleen geschikt voor Postgres: deze plannen, zoals ik heb beschreven, zullen er alleen in werken. Maar als we ons niet druk maken over plannen, en alleen alle data nodig hebben voor functioneel testen, dan is dit geschikt voor elk DBMS.
DS: Vele jaren geleden deden we iets soortgelijks met LVM-snapshots. Dit is een klassieker. Deze aanpak werd zeer actief gebruikt. Stateful knooppunten zijn alleen maar lastig. Omdat je ze niet moet laten vallen, moet je ze altijd onthouden...
NS: Ziet u hier een mogelijkheid voor een hybride? Laten we zeggen dat stateful een soort pod is, het werkt voor meerdere mensen (veel testers). We hebben één volume, maar dankzij het bestandssysteem zijn de klonen lokaal. Als de pod valt, maar de schijf blijft staan, zal de pod omhoog komen, informatie over alle klonen tellen, alles weer oppakken en zeggen: "Hier zijn je klonen die op deze poorten draaien, blijf ermee werken."
DS: Technisch gezien betekent dit dat het binnen Kubernetes één pod is waarbinnen we veel Postgres draaien.
NS: Ja. Hij heeft een limiet: laten we zeggen dat er niet meer dan 10 mensen tegelijk met hem werken. Als je er twintig nodig hebt, lanceren we een tweede dergelijke pod. We zullen het volledig klonen, nadat we het tweede volledige deel hebben ontvangen, zal het dezelfde 20 "dunne" klonen hebben. Zie jij deze kans niet?
DS: We moeten hier beveiligingsproblemen toevoegen. Dit type organisatie houdt in dat deze pod hoge rechten (mogelijkheden) heeft, omdat hij niet-standaard bewerkingen op het bestandssysteem kan uitvoeren... Maar ik herhaal: ik geloof dat ze op de middellange termijn de opslag in Kubernetes zullen repareren, en in de wolken ze zullen het hele verhaal met volumes repareren - alles zal "gewoon werken". Er zal een formaatwijziging plaatsvinden, klonen... Er is een volume - we zeggen: "Maak op basis daarvan een nieuwe", en na anderhalve seconde krijgen we wat we nodig hebben.
NS: Ik geloof niet in anderhalve seconde voor veel terabytes. Op Ceph doe je het zelf, maar je praat over de wolken. Ga naar de cloud, maak een kloon van een EBS-volume van meerdere terabytes op EC2 en kijk wat de prestaties zullen zijn. Het duurt niet een paar seconden. Ik ben erg benieuwd wanneer ze dit niveau zullen bereiken. Ik begrijp wat u zegt, maar ik wil het niet met u eens zijn.
DS: Oké, maar ik zei op de middellange termijn, niet op de korte termijn. Voor meerdere jaren.
Over de operator voor PostgreSQL van Zalando
Halverwege deze bijeenkomst nam ook Alexey Klyukin, een voormalig ontwikkelaar van Zalando, deel en sprak over de geschiedenis van de PostgreSQL-operator:
Het is geweldig dat dit onderwerp in het algemeen wordt aangekaart: zowel Postgres als Kubernetes. Toen we er in 2017 bij Zalando mee begonnen, was het een onderwerp dat iedereen wilde doen, maar niemand deed het. Iedereen had Kubernetes al, maar toen ze vroegen wat ze met databases moesten doen, vonden zelfs mensen het leuk , die K8s predikte, zei zoiets als dit:
“Ga naar beheerde services en gebruik ze, laat de database niet in Kubernetes draaien. Anders besluiten je K8’s bijvoorbeeld om een upgrade uit te voeren, alle knooppunten uit te schakelen en vliegen je gegevens ver, ver weg.”
We hebben besloten een operator te maken die, in tegenstelling tot dit advies, een Postgres-database in Kubernetes gaat lanceren. En we hadden een goede reden: . Dit is een automatische failover voor PostgreSQL, correct uitgevoerd, d.w.z. gebruik van etcd, consul of ZooKeeper als opslag van informatie over het cluster. Zo’n repository die iedereen die bijvoorbeeld vraagt wat de huidige leider is, dezelfde informatie zal geven – ondanks het feit dat we alles verdeeld hebben – zodat er geen gespleten brein ontstaat. Bovendien hadden we dat voor hem.
Over het algemeen ontstond de behoefte van het bedrijf aan automatische failover na de migratie van een intern hardwaredatacenter naar de cloud. De cloud was gebaseerd op een eigen PaaS-oplossing (Platform-as-a-Service). Het is Open Source, maar het kostte veel werk om het operationeel te krijgen. Het heette .
Aanvankelijk was er geen Kubernetes. Om precies te zijn: toen onze eigen oplossing werd ingezet, bestond K8 al, maar het was zo rauw dat het niet geschikt was voor productie. Volgens mij was het 2015 of 2016. In 2017 was Kubernetes min of meer volwassen geworden; er was behoefte om daarheen te migreren.
En we hadden al een Docker-container. Er was een PaaS die Docker gebruikte. Waarom probeer je K8's niet? Waarom schrijft u niet uw eigen operator? Murat Kabilov, die vanuit Avito naar ons toe kwam, begon dit als een project op eigen initiatief – ‘om te spelen’ – en het project ‘ging van start’.
Maar in het algemeen wilde ik het over AWS hebben. Waarom was er historische AWS-gerelateerde code...
Wanneer u iets in Kubernetes uitvoert, moet u begrijpen dat K8s zo'n werk in uitvoering is. Het ontwikkelt zich voortdurend, verbetert en gaat van tijd tot tijd zelfs kapot. Je moet alle veranderingen in Kubernetes nauwlettend in de gaten houden, je moet bereid zijn om erin te duiken als er iets gebeurt en tot in detail te leren hoe het werkt - misschien wel meer dan je zou willen. Dit geldt in principe voor elk platform waarop u uw databases draait...
Dus toen we de verklaring deden, hadden we Postgres op een extern volume draaien (in dit geval EBS, aangezien we aan AWS werkten). De database groeide, op een gegeven moment was het nodig om de grootte ervan aan te passen: de initiële grootte van EBS was bijvoorbeeld 100 TB, de database groeide ernaartoe, nu willen we EBS 200 TB maken. Hoe? Stel dat u een dump/herstel kunt uitvoeren op een nieuw exemplaar, maar dit zal lang duren en downtime met zich meebrengen.
Daarom wilde ik een formaatwijziging die de EBS-partitie zou vergroten en vervolgens het bestandssysteem zou vertellen de nieuwe ruimte te gebruiken. En dat hebben we gedaan, maar op dat moment had Kubernetes geen API voor het wijzigen van de grootte. Sinds we aan AWS werkten, schreven we code voor de API.
Niemand houdt je tegen om hetzelfde te doen voor andere platforms. Er staat geen enkele aanwijzing in de verklaring dat het alleen op AWS kan worden uitgevoerd, en dat het niet op al het andere zal werken. Over het algemeen is dit een Open Source-project: als iemand de opkomst van het gebruik van de nieuwe API wil versnellen, ben je welkom. Eten , pull-aanvragen - het Zalando-team probeert er vrij snel op te reageren en de operator te promoten. Voor zover ik weet, het project bij Google Summer of Code en enkele andere soortgelijke initiatieven. Zalando werkt er heel actief aan.
PS-bonus!
Als u geïnteresseerd bent in het onderwerp PostgreSQL en Kubernetes, houd er dan rekening mee dat de volgende Postgres-dinsdag vorige week plaatsvond, waar ik met Nikolai sprak Alexander Kukushkin van Zalando. Video ervan is beschikbaar .
PPS
Lees ook op onze blog:
- «";
- «";
- «";
- «.
Bron: www.habr.com