🥇Postgres tisdag #5: "PostgreSQL och Kubernetes. CI/CD. Testautomation"

I slutet av förra året ägde ytterligare en direktsändning av den ryska PostgreSQL-communityn rum. #RuPostgres, där dess medgrundare Nikolai Samokhvalov pratade med Flants tekniska direktör Dmitry Stolyarov om detta databashanteringssystem i samband med Kubernetes.

Vi publicerar en transkription av huvuddelen av denna diskussion, och på Community YouTube-kanal Hela videon har publicerats:

Databaser och Kubernetes

NSVi kommer inte att prata om VAKUUM och CHECKPOINTS idag. Vi vill prata om Kubernetes. Jag vet att du har många års erfarenhet. Jag har tittat på dina videor och till och med tittat om några av dem delvis... Låt oss gå rakt på sak: varför behöver du Postgres eller MySQL i K8s?

DSDet finns inget och kan inte finnas ett tydligt svar på den här frågan. Men generellt sett handlar det om enkelhet och bekvämlighet... potential. Alla vill ju trots allt ha hanterade tjänster.

NSSå att som RDS, bara för dig själv?

DSJa: som RDS, men var som helst.

NS"Var som helst" är en bra poäng. I stora företag finns allt på olika platser. Varför då, om det är ett stort företag, inte ta en färdig lösning? Till exempel har Nutanix sina egna utvecklingar, andra företag (VMware...) har samma "RDS, bara i sitt eget".

DSMen vi pratar om en enda implementering som bara fungerar under vissa förutsättningar. Och om vi pratar om Kubernetes, så finns det en enorm variation av infrastruktur (som kan finnas i K8). I huvudsak är detta en standard för API till molnet...

NSOch det är gratis!

DSDet är inte så viktigt. Gratis är inte viktigt för ett särskilt stort segment av marknaden. Något annat är viktigt... Du minns säkert rapporten "Databaser och Kubernetes"?

NS: Ja.

DSJag insåg att det uppfattades väldigt tvetydigt. Vissa trodde att jag sa: "Grabbar, låt oss gå med alla databaser till Kubernetes!", medan andra bestämde sig för att allt detta var bara struntprat. Men jag ville säga något helt annat: "Titta vad som händer, vilka problem det finns och hur de kan lösas. Ska vi gå med databaser till Kubernetes nu? Med produktion? Tja, bara om du gillar... att göra vissa saker. Men för en utvecklare kan jag säga att jag rekommenderar det. Dynamiskt skapande/borttagning av miljöer är mycket viktigt för en utvecklare."

NS: Med utvecklare menar du alla miljöer som inte är produktionsmiljöer? Staging, QA…

DSOm vi pratar om perf-stands, så förmodligen inte, eftersom kraven där är specifika. Om vi pratar om specialfall, där en mycket stor databas behövs för staging, så förmodligen inte heller... Om detta är en statisk miljö, långlivad, vad är då fördelen med att databasen finns i K8s?

NSInga. Men var ser vi statiska miljöer? En statisk miljö är föråldrad imorgon.

DSStaging kan vara statiskt. Vi har kunder…

NSJa, jag har också en. Det är ett stort problem om du har en 10 TB databas och 200 GB staging...

DSJag har ett riktigt coolt case! På staging finns en produktionsbas där ändringar görs. Och det finns en knapp: "roll out to production". Dessa ändringar – deltas – läggs till (det verkar som att de helt enkelt synkroniseras via API) till produktionen. Detta är ett väldigt exotiskt alternativ.

NSJag har sett startups i Valley som sitter i RDS eller till och med Heroku – det här är historier från 2-3 år sedan – och de laddar ner dumpen till sin laptop. Eftersom databasen bara är 80 GB stor, och det finns utrymme på laptopen. Sedan köper de extra diskar för att var och en ska ha 3 databaser för att genomföra olika utvecklingar. Detta händer också. Jag har också sett att de inte är rädda för att kopiera prod till staging – det beror mycket på företaget. Men jag har också sett att de är väldigt rädda, och att det ofta inte finns tillräckligt med tid och händer. Men innan vi går vidare till det här ämnet skulle jag vilja höra om Kubernetes. Har jag rätt i att ingen har det i prod än?

DSVi har små databaser i produktion. Vi talar om volymer på tiotals gigabyte och icke-kritiska tjänster för vilka det var för lat att göra repliker (och det finns inget sådant behov). Och förutsatt att det finns normal lagring under Kubernetes. Denna databas fungerade i en virtuell maskin - villkorligt i VMware, ovanpå lagringssystemet. Vi placerade den i PV och nu kan vi flytta den från bil till bil.

NSDatabaser av den här storleken, upp till 100 GB, kan väl rullas ut på några minuter på bra diskar och med ett bra nätverk? En hastighet på 1 GB per sekund är inte längre exotiskt.

DSJa, för en linjär operation är detta inget problem.

NSOkej, vi borde bara tänka på produktion. Och om vi betraktar Kubernetes för miljöer utan produktion – hur gör man det? Jag ser det i Zalando. make-operatorn, i Knaprigt de sågar, finns det några andra alternativ. Och det finns OnGres - det här är vår gode vän Alvaro från Spanien: de gör i princip inte bara operatöroch hela fördelningen (StackGres), i vilken de, förutom Postgres självt, också bestämde sig för att klämma in en säkerhetskopia, en Envoy-proxy ...

DSSändebud för vad? Balansera specifikt Postgres-trafik?

NSJa. Det vill säga, de ser det som: om du tar LinuxOm vi pratar om en distribution och en kärna, så är vanlig PostgreSQL kärnan, och de vill skapa en distribution som är molnvänlig och körs på Kubernetes. De kopplar ihop komponenterna (säkerhetskopior etc.) och felsöker dem för att säkerställa att de fungerar bra.

DSVäldigt coolt! I grund och botten är detta programvara för att skapa dina egna hanterade Postgres.

NS: U LinuxDistributioner har ett ständigt problem: hur man skapar drivrutiner som stöder all hårdvara. Och de tror att de kommer att fungera i Kubernetes. Jag vet att vi nyligen såg Zalandos beroende av AWS, och det är inte särskilt bra. Det borde inte finnas ett beroende av en specifik infrastruktur – vad är poängen då?

DSJag vet inte exakt i vilken situation Zalando fastnade, men i Kubernetes är lagringen nu gjord på ett sådant sätt att man inte kan ta en diskbackup med en generisk metod. Nyligen i standarden - i den senaste versionen. CSI-specifikationer — vi gjorde snapshots möjliga, men var är det implementerat? Ärligt talat är det fortfarande så rått… Vi testar CSI över AWS, GCE, Azure, vSphere, men så fort man börjar använda det ser man att det inte är klart än.

NSDet är därför man ibland måste knyta sig till infrastrukturen. Jag tror att det fortfarande är ett tidigt stadium – växtvärk. Fråga: vad skulle du rekommendera till nybörjare som vill prova PgSQL i K8s? Vilken operator, kanske?

DSProblemet är att Postgres står för 3 % för oss. Vi har en väldigt lång lista med olika programvaror i Kubernetes, jag kommer inte ens lista alla. Till exempel Elasticsearch. Det finns många operatorer: vissa utvecklas aktivt, andra inte. Vi har sammanställt krav för oss själva, vad en operator bör ha så att vi tar det på allvar. I en operator specifikt för Kubernetes - inte i en "operator för att göra något under Amazons villkor"... Faktum är att vi ganska brett (= nästan alla klienter) använder en enda operator - för Redis (vi kommer att publicera en artikel om honom snart).

NSOch för MySQL också? Jag vet att Percona… eftersom de nu arbetar med MySQL, MongoDB och Postgres, måste de skapa någon form av universell sådan: för alla databaser, för alla molnleverantörer.

DSVi har inte haft tid att titta på MySQL-operatorer. Det här är inte vårt huvudfokus just nu. MySQL fungerar bra fristående. Varför behöver man en operator om man bara kan starta en databas... Man kan starta en Docker-container med Postrges, eller så kan man starta den helt enkelt.

NSDet fanns en fråga om det också. Utan någon operatör alls?

DSJa, i 100% av fallen kör vi PostgreSQL utan operator. Så är det för tillfället. Vi använder aktivt operatorn för Prometheus, för Redis. Vi har planer på att hitta en operator för Elasticsearch - den är den mest "brännande" eftersom vi vill installera den i Kubernetes i 100% av fallen. Precis som vi vill komma till den punkt där vi alltid installerar MongoDB i Kubernetes. Här dyker vissa önskemål upp - det finns en känsla av att något kan göras i dessa fall. Och vi har inte ens tittat på Postgres. Naturligtvis vet vi om att det finns olika alternativ, men i själva verket har vi fristående.

Databas för testning i Kubernetes

NSLåt oss gå vidare till ämnet testning. Hur man rullar ut ändringar i databasen – ur ett DevOps-perspektiv. Det finns mikrotjänster, många databaser, något förändras ständigt någonstans. Hur säkerställer man normal CI/CD så att allt är bra ur ett DBMS-perspektiv. Vad är ert tillvägagångssätt?

DSDet kan inte finnas ett svar. Det finns flera parametrar. Den första är storleken på den bas vi vill rulla ut. Du nämnde själv att företag har olika attityder till att ha en kopia av produktionsbasen på utvecklings- och scennivå.

NSOch enligt GDPR tror jag att de blir mer och mer försiktiga... Jag kan säga att i Europa har de redan börjat utfärda böter.

DSMen ofta kan man skriva programvara som skapar en dump från produktionsdata och förvränger den. Man får produktionsdata (snapshot, dump, binär kopia...), men de är anonymiserade. Istället kan det finnas genereringsskript: dessa kan vara fixturer eller bara ett skript som genererar en stor bas. Problemet är: hur lång tid tar det att skapa en basavbildning? Och hur lång tid tar det att distribuera den till den önskade miljön?

Vi kom fram till schemat: om klienten har en fixtur datamängd (en minimal version av databasen), använder vi den som standard. Om vi pratar om granskningsmiljöer, när vi skapade en gren, distribuerade vi en instans av applikationen - vi rullade ut en liten databas där. Men det gick bra och вариант, när vi tar en dump från produktionen en gång om dagen (på natten) och bygger en Docker-container med PostgreSQL och MySQL baserat på den med denna laddade data. Om vi behöver driftsätta en databas 50 gånger från denna avbildning görs detta ganska enkelt och snabbt.

NSGenom enkel kopiering?

DSData lagras direkt i Docker-avbildningen. Det vill säga, vi har en färdig avbildning, även om den är 100 GB. Tack vare lager i Docker kan vi snabbt distribuera den här avbildningen så många gånger som behövs. Metoden är dum, men den fungerar bra.

NSSen, när du testar, ändras det direkt i Docker, eller hur? Kopiera-vid-skrivning i Docker — släng det och kör igen, allt är bra. Coolt! Och du använder det redan till fullo?

DS: Under en lång tid.

NSVi gör väldigt liknande saker. Bara det att vi inte använder Dockers copy-on-write, utan något annat.

DSDet är inte generiskt. Och Docker fungerar överallt.

NSI teorin, ja. Men vi har också moduler där, man kan skapa olika moduler och arbeta med olika filsystem. Grejen är den. Vi ser på allt detta annorlunda från Postgres-sidan. Nu tittade jag från Docker-sidan och såg att allt fungerar för dig. Men om databasen är enorm, till exempel 1 TB, då tar allt lång tid: operationer på natten, och att stoppa in allt i Docker... Och om man stoppar in 5 TB i Docker... Eller är allt okej?

DSVad är skillnaden: det här är blobbar, bara bitar och byte.

NSSkillnaden är denna: gör du detta via dump och restore?

DSInte nödvändigtvis. Det kan finnas olika sätt att generera den här bilden.

NSFör vissa klienter har vi gjort det så att vi istället för att regelbundet generera en basavbildning ständigt håller den uppdaterad. Det är i huvudsak en replika, men den tar emot data inte direkt från mastern, utan via ett arkiv. Ett binärt arkiv, där WAL:er rullas varje dag, där säkerhetskopior också tas... Dessa WAL:er flyger sedan – med en liten fördröjning (bokstavligen 1–2 sekunder) – till basavbildningen. Vi klonar från den på vilket sätt som helst – nu har vi ZFS som standard.

DSMen med ZFS är du begränsad till en nod.

NSJa. Men ZFS har en annan magi sända: med den kan du skicka en ögonblicksbild och till och med (jag har inte testat detta så mycket än, men...) du kan skicka ett delta mellan två PGDATAVi har faktiskt ett annat verktyg som vi inte riktigt har övervägt för den här typen av uppgift. PostgreSQL har pg_rewind, vilket fungerar som en "smart" rsync, som hoppar över många saker som du inte behöver titta på eftersom ingenting har ändrats där. Vi kan göra en snabb synkronisering mellan två servrar och spola tillbaka på exakt samma sätt.

Så, vi försöker från den här, mer DBA-liknande, sidan att skapa ett verktyg som låter oss göra samma sak som du pratade om: vi har en databas, men vi vill testa något 50 gånger, nästan samtidigt.

DS50 gånger betyder att du behöver beställa 50 Spot-instanser.

NSNej, vi gör allt på en maskin.

DSMen hur ska du driftsätta den 50 gånger om den här databasen är, säg, en terabyte? Troligtvis behöver den, säg, 256 GB RAM?

NSJa, ibland behöver man mycket minne – det är normalt. Men här är ett exempel från livet. Produktionsmaskinen har 96 kärnor och 600 GB. Samtidigt används 32 kärnor för databasen (till och med 16 kärnor nu ibland) och 100-120 GB minne.

DSOch 50 exemplar får plats där?

NSSå det finns bara en kopia, sedan fungerar copy-on-write (ZFS)... Jag ska berätta mer.

Till exempel har vi en databas på 10 TB. Vi skapade en disk för den, ZFS komprimerade också dess storlek med 30-40 procent. Eftersom vi inte gör belastningstester är den exakta svarstiden inte viktig för oss: låt den vara upp till 2 gånger långsammare - det är okej.

Vi gör det möjligt för programmerare, QA, DBA etc. att utföra tester i 1-2 trådar. De kan till exempel köra en viss migrering. Det kräver inte 10 kärnor samtidigt - det behöver 1 Postgres-backend, 1 kärna. Migreringen kommer att köras - kanske, autovakuum Den startar om igen, sedan används den andra kärnan. Vi har 16–32 kärnor allokerade, så 10 personer kan arbeta samtidigt, inga problem.

Eftersom fysiskt PGDATA är desamma, visar det sig att vi faktiskt lurar Postgres. Tricket är: till exempel startas 10 Postgres samtidigt. Vad är det vanliga problemet? De sätter shared_buffers, låt oss säga 25 %. Följaktligen är detta 200 GB. Du kommer inte att kunna starta mer än tre av dessa, eftersom minnet då tar slut.

Men vid någon tidpunkt insåg vi att detta inte är nödvändigt: vi satte shared_buffers till 2 GB. PostgreSQL har effektiv_cache_storlek, och i verkligheten påverkar det bara planerVi lägger det i 0,5 TB. Och det spelar ingen roll att de faktiskt inte existerar: han gör planer som om de gör det.

Följaktligen, när vi testar en migrering, kan vi samla in alla planer – vi får se hur det kommer att hända i produktion. Sekunderna där kommer att vara annorlunda (långsammare), men den data vi faktiskt läser, och själva planerna (vilka JOIN:er, etc.) är exakt desamma som i produktion. Och parallellt kan man köra många sådana kontroller på en och samma maskin.

DSTycker du inte att det finns flera problem här? Det första är att lösningen bara fungerar på PostgreSQL. Den här metoden är väldigt specifik, den är inte generisk. Det andra är att Kubernetes (och allt som molntekniker nu går till) antar många noder, och dessa noder är efemära. Och i ditt fall är den tillståndskänslig, en persistent nod. Dessa saker orsakar motsägelser för mig.

NSFör det första håller jag med, det här är en ren Postgres-historia. Jag tror att om vi har direkt IO och en buffertpool för nästan allt minne, så kommer den här metoden inte att fungera – vi kommer att ha andra planer. Men vi arbetar bara med Postgres för tillfället, vi tänker inte på andra.

Angående Kubernetes. Du säger själv överallt att vi har en persistent databas. Om en instans kraschar är det viktigaste att rädda disken. Här har vi också hela plattformen i Kubernetes, och komponenten med Postgres är separat (även om den kommer att finnas där en dag). Det är därför allt är så här: instansen kraschade, men vi sparade dess persistenta databas och kopplade den helt enkelt till en annan (ny) instans, som om ingenting hade hänt.

DSUr mitt perspektiv skapar vi poddar i Kubernetes. K8s är elastiskt: noder ordnas efter behov. Uppgiften är att helt enkelt skapa en pod och säga att den behöver X resurser, och K8s kommer att lista ut resten. Men lagringsstödet i Kubernetes är fortfarande instabilt: i 1.16I 1.17 (denna utgåva kom ut av veckan tillbaka) dessa funktioner blir bara betaversioner.

Ett halvår eller ett år kommer att gå - det kommer att bli mer eller mindre stabilt, eller åtminstone deklareras som sådant. Då kommer möjligheten till snapshots och storleksändring att lösa ditt problem helt. För du har en bas. Ja, det kanske inte är särskilt snabbt, men hastigheten beror på vad som finns "under huven", eftersom vissa implementeringar kan kopiera och kopiera-vid-skrivning på nivån av diskundersystemet.

NSHär behöver vi också se till att alla sökmotorer (Amazon, Google...) har tid att börja stödja den här versionen – detta tar också lite tid.

DSVi använder dem inte än. Vi använder våra egna.

Lokal utveckling för Kubernetes

NSHar du någonsin stött på en sådan önskan, när du behöver köra alla poddar på en maskin och göra ett så litet test. Att snabbt få ett proof of concept, att se att applikationen fungerar i Kubernetes, utan att allokera en massa maskiner för detta. Du har Minikube, eller hur?

DSDet verkar för mig som att det här fallet – driftsättning på en nod – uteslutande handlar om lokal utveckling. Eller några manifestationer av ett sådant mönster. Det finns Minikube, Det finns K3S, SNÄLLVi går nu över till att använda Kubernetes IN Docker. Vi har nu börjat arbeta med det för testning.

NSJag trodde att det här var ett försök att samla alla poddar i en Docker-avbildning. Men det visade sig att det här handlar om något helt annat. Det finns fortfarande separata containrar, separata poddar – bara i Docker.

DSJa. Och det görs en ganska rolig imitation där, men poängen är denna... Vi har ett verktyg för driftsättning - werfVi vill skapa en regim i det - villkorligt werf up"Skaffa mig en lokal Kubernetes." Och kör sedan ett villkorskommando werf followDå kommer utvecklaren att kunna redigera i IDE:n, och en process startas i systemet som ser ändringarna och återskapar avbildningarna, omdistribuerar dem till de lokala K8:erna. Det är så vi vill försöka lösa problemet med lokal utveckling.

Ögonblicksbilder och databasens kloning i K8s Realities

NSOm vi går tillbaka till kopiera-vid-skrivning. Jag har lagt märke till att moln också har snapshots. De fungerar annorlunda. Till exempel, i GCP: du har en instans på flera terabyte på den amerikanska östkusten. Du gör regelbundet snapshots. Du hämtar en kopia av disken från snapshoten på västkusten - på några minuter är allt klart, det fungerar väldigt snabbt, bara cachen behöver fyllas i minnet. Men dessa kloner (snapshots) är till för att "provisionera" en ny volym. Detta är coolt när du behöver skapa många instanser.

Men för testning, verkar det som att snapshots, som du pratar om i Docker eller jag pratar om i ZFS, btrfs och till och med LVM... - låter dig inte skapa riktigt ny data på en enda maskin. I molnet måste du fortfarande betala för dem varje gång och vänta inte sekunder, utan minuter (och när det gäller lat last, möjligen en klocka).

Istället kan du hämta dessa data på en sekund eller två, köra testet och sedan slänga dem. Dessa ögonblicksbilder löser olika problem. I det första fallet för att skala och hämta nya repliker, och i det andra fallet för tester.

DSJag håller inte med. Det är molnets jobb att klona volymer korrekt. Jag har inte tittat på deras implementering, men jag vet hur vi gör det på hårdvara. Vi har Ceph, där vilken fysisk volym som helst kan (RBD) säga klona och få en andra volym med samma egenskaper på tiotals millisekunder, IOPS'ami, etc. Du måste förstå att det finns en knepig kopierings-och-skrivningsprocess inuti. Varför skulle inte molnet göra detsamma? Jag är säker på att de försöker göra det på ett eller annat sätt.

NSMen det kommer fortfarande att ta dem sekunder, tiotals sekunder att hämta en instans, ta dit Docker, etc.

DSVarför är det nödvändigt att höja en hel instans? Vi har en instans med 32 kärnor, 16... och några får plats i den - till exempel fyra. När vi beställer den femte kommer instansen redan att höjas, och sedan kommer den att tas bort.

NSJa, intressant nog är det en annan historia i Kubernetes. Vår databas finns inte i K8s, och det finns en instans. Men att klona en databas på flera terabyte tar inte mer än två sekunder.

DSDet är coolt. Men min första poäng är att detta inte är en generisk lösning. Ja, det är coolt, men det fungerar bara för Postgres och bara på en nod.

NSDet gäller inte bara Postgres: dessa planer, som jag beskrev, kommer bara att fungera i det. Men om vi inte bryr oss om planer, och bara behöver all data för funktionell testning, så kommer det att fungera för vilket databassystem som helst.

DSFör många år sedan gjorde vi något liknande med LVM-snapshots. Det är en klassiker. Den här metoden användes väldigt aktivt. Det är bara det att stateful nodes är jobbiga. För man behöver inte tappa dem, man måste alltid komma ihåg dem...

NSSer du ingen möjlighet till en hybrid här? Låt oss säga att stateful är någon sorts pod, den fungerar för flera personer (många testare). Vi har en volym, men tack vare filsystemet är klonerna lokala. Om poden kraschar finns disken kvar - poden kommer att resa sig, läsa informationen om alla kloner, resa tillbaka allt och säga: "Här är dina kloner som körs på dessa portar, fortsätt arbeta med dem."

DSTekniskt sett betyder detta att det inom Kubernetes är en pod, inuti vilken vi kör många Postgres.

NSJa. Det har en gräns: låt oss säga att högst 10 personer arbetar med det samtidigt. Om vi behöver 20 lanserar vi en andra pod. Det är fullt möjligt att klona den och få en andra full volym, som kommer att ha samma 10 "tunna" kloner. Ser du inte en sådan möjlighet?

DSVi måste lägga till säkerhetsproblem här. Den här typen av organisation innebär att den här podden har höga privilegier (funktioner), eftersom den kan utföra icke-standardiserade operationer på filsystemet... Men jag upprepar: Jag tror att på medellång sikt kommer lagring att fixas i Kubernetes, hela historien med volymer kommer att fixas i molnen - allt kommer att "bara fungera". Det kommer att bli storleksändring, kloning... Det finns en volym - vi säger: "Skapa en ny baserat på den", - och på en och en halv sekund får vi det vi behöver.

NSJag tror inte på en och en halv sekund för många terabyte. Du gör det själv på Ceph, och du pratar om moln. Gå till molnet, gör en klon av en EBS-volym på många terabyte på EC2 och se vad prestandan blir. Det tar inte några sekunder. Jag är väldigt intresserad av när de kommer att nå en sådan siffra. Jag förstår vad du pratar om, men jag tillåter mig att inte hålla med.

DSOkej, men jag sa på medellång sikt, inte kort sikt. Under loppet av flera år.

Om operatorn för PostgreSQL från Zalando

Mitt under mötet deltog även Alexey Klyukin, en tidigare utvecklare från Zalando, och berättade historien om PostgreSQL-operatorn:

Det är fantastiskt att det här ämnet ens berörs: både Postgres och Kubernetes. När vi började göra det på Zalando 2017 var det ett ämne som alla ville göra, men ingen gjorde det. Alla skaffade redan Kubernetes, men när folk frågade vad man skulle göra med databaser, till och med folk som... Kelsey Hightower, som predikade K8s, sa något i stil med:
"Gå till hanterade tjänster och använd dem, kör inte databas i Kubernetes. Annars kommer dina K8:or att bestämma sig för att till exempel uppgradera, stänga ner alla noder, och din data kommer att flyga långt, långt bort."
Vi bestämde oss för att skapa en operator som, i motsats till detta råd, skulle köra en Postgres-databas i Kubernetes. Och vi hade en god anledning — PatroniDetta är en automatisk redundansväxling för PostgreSQL, korrekt utförd, dvs. med hjälp av etcd, consul eller ZooKeeper som ett klusterinformationslager. Ett lager som ger alla som frågar, till exempel, vem som är den nuvarande ledaren, samma information - trots att vi har allt distribuerat - så att det inte finns någon split brain. Dessutom hade vi Docker-bild för honom.
Generellt sett uppstod företagets behov av automatisk redundans efter att ha migrerat från ett internt hårdvarudatacenter till molnet. Molnet baserades på en egen PaaS-lösning (Platform-as-a-Service). Det är öppen källkod, men det krävdes mycket arbete för att få igång det. Det kallades KNÖP.
Ursprungligen fanns det inget Kubernetes. Mer exakt, när vår egen lösning driftsattes, fanns K8 redan, men den var så rå att den inte var lämplig för produktion. Det var, tror jag, 2015 eller 2016. År 2017 hade Kubernetes blivit mer eller mindre moget – det fanns ett behov av att migrera dit.
Och vi hade redan en Docker-container. Det fanns en PaaS som använde Docker. Varför inte prova K8:or? Varför inte skriva din egen operator? Murat Kabilov, som kom till oss från Avito, startade detta som ett projekt på eget initiativ – ”för att leka” – och projektet ”tog fart”.
Men generellt sett ville jag prata om AWS. Varför fanns det historiskt sett kod relaterad till AWS…
När du kör något i Kubernetes måste du förstå att K8s är ett pågående arbete. Det utvecklas, förbättras och till och med bryts ner då och då. Du måste noggrant övervaka alla förändringar i Kubernetes, du måste vara redo att dyka in i det och lära dig hur det fungerar i detalj om det behövs – kanske mer än du skulle vilja. Detta är i princip fallet med alla plattformar som du kör dina databaser på...
Så, när vi skapade operatorn hade vi Postgres, som fungerade med en extern volym (i det här fallet EBS, eftersom vi arbetade i AWS). Databasen växte, vid någon tidpunkt var det nödvändigt att göra en storleksändring: till exempel, den ursprungliga storleken på EBS är 100 TB, databasen har vuxit till det, nu vill vi göra EBS 200 TB. Hur? Låt oss säga att du kan göra en dump/återställning till en ny instans, men detta är långt och innebär driftstopp.
Så vi ville ha en storleksändring som skulle utöka EBS-partitionen och sedan ange att filsystemet skulle använda det nya utrymmet. Och det gjorde vi, men vid den tidpunkten hade Kubernetes inget API för storleksändringsoperationen. Eftersom vi körde på AWS skrev vi kod för deras API.
Det finns ingen anledning att göra detsamma för andra plattformar. Det finns inget krav i operatören att det bara kan lanseras på AWS, och det kommer inte att fungera på något annat. Generellt sett är detta ett öppen källkodsprojekt: om någon vill påskynda framväxten av användningen av det nya API:et är ni välkomna. Det finns GitHub, pull requests — Zalando-teamet försöker svara på dem ganska snabbt och marknadsföra operatören. Såvitt jag vet, projektet deltog i Google Summer of Code och några andra liknande initiativ. Zalando arbetar mycket aktivt med det.

P.S. Bonus!

Om du är intresserad av ämnet PostgreSQL och Kubernetes, så vill vi också uppmärksamma dig på att förra veckan ägde nästa Postgres Tuesday rum, där Nikolay pratade Alexander Kukushkin från ZalandoVideo från den finns tillgänglig här.