{"id":55467,"date":"2020-01-21T00:00:00","date_gmt":"2020-01-20T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya"},"modified":"2020-02-18T14:03:35","modified_gmt":"2020-02-18T11:03:35","slug":"postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres-tirsdag nr. 5: \u00abPostgreSQL og Kubernetes. CI\/CD. Automatisering av testing\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres-tirsdag
\n
\nI slutten av fjor\u00e5ret ble det avholdt et nytt direktesendt program for det russiske PostgreSQL-samfunnet #RuPostgres<\/a><\/noindex>, der medgrunnlegger Nikolai Samokhvalov snakket med teknisk direkt\u00f8r for \u00abFlant\u00bb Dmitry Stolyarov om denne DBMS i konteksten av Kubernetes.<\/p>\n

Vi publiserer transkriptet av hoveddelen av denne diskusjonen, og p\u00e5 YouTube-kanalen til samfunnet<\/a><\/noindex> er den fullstendige videoopptaket publisert:<\/a><\/noindex><\/p>\n

\r\n \"Spill\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Databaser og Kubernetes<\/h2>\n

\nNS<\/b>: Vi skal ikke snakke om VACUUM og CHECKPOINT’er i dag. Vi vil snakke om Kubernetes. Jeg vet at du har mange \u00e5rs erfaring allerede. Jeg har sett videoene dine og har til og med sett noen av dem flere ganger... La oss g\u00e5 rett til saken: hvorfor i det hele tatt bruke Postgres eller MySQL i K8s?<\/i><\/p>\n

DS<\/b>: Det er ikke noe entydig svar p\u00e5 dette sp\u00f8rsm\u00e5let, og det kan ikke finnes. Men generelt handler det om enkelhet og bekvemmelighet... potensielt. Alle vil jo ha managed tjenester.<\/p>\n

NS<\/b>: Som RDS<\/a><\/noindex>, bare hos seg selv?<\/i><\/p>\n

DS<\/b>: Ja: som RDS, bare hvor som helst.<\/p>\n

NS<\/b>: \u00abHvor som helst\u00bb \u2014 det er et godt poeng. I store selskaper er alt fordelt over flere steder. Men hvorfor velge et ferdig l\u00f8sning hvis det er et stort selskap? For eksempel har Nutanix sine egne utviklinger, og andre selskaper (VMware...) \u2014 den samme \u00abRDS, bare hos seg selv\u00bb.<\/i><\/p>\n

DS<\/b>: Men dette snakker vi om en spesifikk implementering som bare vil fungere under bestemte forhold. N\u00e5r vi snakker om Kubernetes, er det et enormt mangfold av infrastruktur (som kan v\u00e6re i K8s). Dette er i essens en standard for API til skyen...<\/p>\n

NS<\/b>: Og det er gratis!<\/i><\/p>\n

DS<\/b>: Det er ikke s\u00e5 viktig. Gratishet er ikke s\u00e5 viktig for et lite segment av markedet. Det andre er viktigere... Du husker sikkert foredraget \u00abDatabaser og Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

NS<\/b>: Ja.<\/i><\/p>\n

DS<\/b>: Jeg forsto at budskapet mitt ble mottatt veldig blandet. Noen tenkte at jeg mente: \u00abLa oss alle bruke databaser i Kubernetes!\u00bb, mens andre trodde det var en fryktelig feil. Men det jeg egentlig \u00f8nsket \u00e5 si var: \u00abSe hva som skjer, hvilke problemer finnes, og hvordan kan vi l\u00f8se dem. Er det n\u00e5 lurt \u00e5 kj\u00f8re databaser i Kubernetes? Produksjon? Bare hvis du elsker... \u00e5 drive med visse ting. Men for dev’er, derimot, vil jeg si at jeg anbefaler det. For dev’ere er det veldig viktig med dynamikk i oppretting\/\u00f8delegging av milj\u00f8er.\u00bb<\/p>\n

NS: Mener du med dev’er alle milj\u00f8er som ikke er prod? Staging, QA...<\/i><\/p>\n

DS<\/b>: Hvis vi snakker om perf-stativer, s\u00e5 er det vel neppe det, fordi kravene der er spesifikke. Hvis vi snakker om spesielle tilfeller hvor det p\u00e5 staging er behov for en veldig stor DB, s\u00e5 er svaret ogs\u00e5 neppe\u2026 Hvis det er et statisk milj\u00f8 som lever lenge, hvilken fordel er det at databasen ligger i K8s?<\/p>\n

NS<\/b>: Ingen. Men hvor ser vi statiske milj\u00f8er? Et statisk milj\u00f8 er allerede utdatert i morgen.<\/i><\/p>\n

DS<\/b>: Staging kan v\u00e6re statisk. Vi har kunder\u2026<\/p>\n

NS<\/b>: Ja, jeg har ogs\u00e5 noen. Det er et stort problem hvis du har en database p\u00e5 10 TB, men staging er 200 GB\u2026<\/i><\/p>\n

DS<\/b>: Jeg har en veldig kul case! P\u00e5 staging har vi produksjonsdatabasen, hvor det gj\u00f8res endringer. Det er en knapp der: \u00abKj\u00f8r ut i produksjon\u00bb. Disse endringene - deltas - blir lagt til (ser ut til \u00e5 synkroniseres via API’et) i produksjonen. Det er et ganske eksotisk alternativ.<\/p>\n

NS<\/b>: Jeg har sett oppstartsselskaper i dalen som bruker RDS eller til og med Heroku fortsatt - det er historier fra 2-3 \u00e5r tilbake - og de laster ned dumpen til laptopen sin. Fordi databasen er bare 80 GB, og det er plass p\u00e5 laptopen. Deretter kj\u00f8per de disker til hverandre for \u00e5 ha 3 databaser for \u00e5 drive forskjellige utviklinger. S\u00e5nt skjer ogs\u00e5. Jeg har ogs\u00e5 sett at de ikke er redde for \u00e5 kopiere fra prod til staging - det avhenger veldig av selskapet. Men jeg har sett at mange er redde, og ofte mangler tid og ressurser. Men f\u00f8r vi g\u00e5r videre til dette temaet, vil jeg gjerne h\u00f8re om Kubernetes. Forst\u00e5r jeg det rett at ingen har det i prod enn\u00e5?<\/i><\/p>\n

DS<\/b>: Vi har sm\u00e5 databaser i prod. Det snakkes om volum p\u00e5 titalls gigabyte og ikke-kritiske tjenester, for hvilke det var for mye jobb \u00e5 lage replikater (og det er ikke behov for det). Og forutsetter at det finnes normal lagring under Kubernetes. Denne databasen kj\u00f8rte p\u00e5 en virtuell maskin - som i VMware, p\u00e5 toppen av lagringssystemet. Vi plasserte den i PV<\/a><\/noindex> og n\u00e5 kan vi flytte den fra maskin til maskin.<\/p>\n

NS<\/b>: Databaser av den st\u00f8rrelsen, opp til 100 GB, p\u00e5 gode disker og med godt nettverk kan rulles ut p\u00e5 noen f\u00e5 minutter, ikke sant? En hastighet p\u00e5 1 GB per sekund er ikke lenger eksotisk.<\/i><\/p>\n

DS<\/b>: Ja, for en line\u00e6r operasjon er det ikke et problem.<\/p>\n

NS<\/b>: Ok, vi m\u00e5 bare tenke p\u00e5 prod. Men hvis vi vurderer Kubernetes for ikke-prod-milj\u00f8er \u2014 hvordan g\u00e5r vi frem? Jeg ser at Zalando lager en operat\u00f8r<\/a><\/noindex>, i Crunchy jobber de med det<\/a><\/noindex>, det finnes ogs\u00e5 andre alternativer. Og det er OnGres<\/a><\/noindex> \u2014 det er v\u00e5r gode bekjent Alvaro fra Spania: de lager ikke bare operator<\/a><\/noindex>, men en hel distribusjon (StackGres<\/a><\/noindex>), hvor vi ogs\u00e5 bestemte oss for \u00e5 pakke inn backupen, proxy Envoy...<\/i><\/p>\n

DS<\/b>: Envoy til hva? Lastbalansering av Postgres-trafikk?<\/p>\n

NS<\/b>: Ja. De ser p\u00e5 det som: hvis man tar en Linux-distribusjon og kjernen, s\u00e5 er vanlig PostgreSQL kjernen, og de vil lage en distribusjon som er vennlig mot skyer og kan kj\u00f8re i Kubernetes. De kobler sammen komponenter (backups osv.) og finjusterer for at de skal fungere godt.<\/i><\/p>\n

DS<\/b>: Veldig kult! I bunn og grunn er dette programvare for \u00e5 lage sin egen managed Postgres.<\/p>\n

NS<\/b>: Linux-distribusjoner har evige problemer: hvordan lage drivere slik at alt maskinvare st\u00f8ttes. Og deres id\u00e9 er at de skal fungere i Kubernetes. Jeg vet at vi i Zalando-opponenten nylig s\u00e5 en tilknytning til AWS, og det er ikke spesielt bra. Det burde ikke v\u00e6re knyttet til en spesifikk infrastruktur \u2014 hva er da meningen?<\/i><\/p>\n

DS<\/b>: Jeg vet ikke i hvilken situasjon Zalando konkret ble knyttet, men i Kubernetes er lagring n\u00e5 laget slik at man ikke kan ta diskbackup p\u00e5 en generell m\u00e5te. Nylig i standarden \u2014 i siste versjon CSI-spesifikasjonen<\/a><\/noindex> \u2014 laget muligheten for snapshots, men hvor er det implementert? \u00c6rlig talt, det er fortsatt s\u00e5 r\u00e5tt\u2026 Vi pr\u00f8ver CSI over AWS, GCE, Azure, vSphere, men s\u00e5 snart man begynner \u00e5 bruke det, ser man at det fortsatt ikke er klart.<\/p>\n

NS<\/b>: Derfor m\u00e5 man noen ganger knytte seg til infrastrukturen. Jeg tror dette fortsatt er en tidlig fase \u2014 vekstproblemer. Sp\u00f8rsm\u00e5let er: hva ville du anbefale nybegynnere som \u00f8nsker \u00e5 pr\u00f8ve PgSQL i K8s? Hvilken operator, kanskje?<\/i><\/p>\n

DS<\/b>: Problemet er at Postgres for oss er bare 3%. Vi har en veldig lang liste med forskjellige programvare i Kubernetes, jeg vil ikke engang begynne \u00e5 liste dem opp. For eksempel Elasticsearch. Det finnes mange operat\u00f8rer: noen utvikles aktivt, andre ikke. Vi har laget kravene for hva som m\u00e5 v\u00e6re i en operat\u00f8r for at vi skal ta den seri\u00f8st. Operat\u00f8ren for Kubernetes \u2014 ikke i \u00aboperat\u00f8ren for \u00e5 gj\u00f8re noe under Amazon'... I praksis bruker vi i stor grad (= nesten alle kunder) den eneste operat\u00f8ren \u2014 for Redis<\/a><\/noindex> (vi vil snart publisere en artikkel om den ogs\u00e5)<\/i>.<\/p>\n

NS<\/b>: Men for MySQL finnes det ikke? Jeg vet at Percona\u2026 siden de n\u00e5 jobber med b\u00e5de MySQL, MongoDB og Postgres, b\u00f8r de lage en slags universell l\u00f8sning: for alle databaser, for alle skytjenesteleverand\u00f8rer.<\/i><\/p>\n

DS<\/b>: Vi rakk ikke \u00e5 se p\u00e5 operat\u00f8rene for MySQL. For oss er det ikke hovedfokuset n\u00e5. MySQL fungerer fint p\u00e5 egen h\u00e5nd. Hva trenger vi en operat\u00f8r for, n\u00e5r vi kan bare starte databasen\u2026 Vi kan starte en Docker-container med Postrges, eller vi kan gj\u00f8re det p\u00e5 en enkel m\u00e5te.<\/p>\n

NS<\/b>: Det var ogs\u00e5 et sp\u00f8rsm\u00e5l om dette. Kanskje helt uten operat\u00f8r?<\/i><\/p>\n

DS<\/b>: Ja, vi har PostgreSQL kj\u00f8rende uten operat\u00f8r 100%. S\u00e5nn er det forel\u00f8pig. Vi bruker aktivt operat\u00f8r for Prometheus, for Redis. Vi har planer om \u00e5 finne en operat\u00f8r for Elasticsearch \u2014 det er mest presserende, siden vi \u00f8nsker \u00e5 ha det installert i Kubernetes i 100% av tilfellene. P\u00e5 samme m\u00e5te \u00f8nsker vi \u00e5 s\u00f8rge for at MongoDB alltid installeres i Kubernetes. Det dukker opp visse \u00f8nsker \u2014 det f\u00f8les som man kan gj\u00f8re noe her. Men vi har ikke engang sett p\u00e5 Postgres. Vi vet selvsagt om de ulike alternativene, men i praksis er vi p\u00e5 standalone.<\/p>\n

Database for testing i Kubernetes<\/h2>\n

\nNS<\/b>: La oss g\u00e5 videre til temaet testing. Hvordan rulle ut endringer i databasen \u2014 fra et DevOps-perspektiv. Det finnes mikrotjenester, mange databaser, og det endres hele tiden noe. Hvordan kan vi s\u00f8rge for en skikkelig CI\/CD slik at alt fungerer som det skal fra databasen sin side. Hva er din tiln\u00e6rming?<\/i><\/p>\n

DS<\/b>: Det er ingen enkelt svar. Det finnes flere parametere. Den f\u00f8rste er st\u00f8rrelsen p\u00e5 databasen vi \u00f8nsker \u00e5 rulle ut. Du nevnte selv at selskaper har ulike holdninger til om en kopi av produksjonsdatabasen skal v\u00e6re i utvikling og staging.<\/p>\n

NS<\/b>: Og under GDPR tror jeg de blir mer og mer forsiktige\u2026 Jeg kan si at i Europa har de allerede begynt \u00e5 ilegge b\u00f8ter.<\/i><\/p>\n

DS<\/b>: Men ofte kan man skrive programvare som tar et dump fra produksjon og obfuskerer det. Man f\u00e5r produksjonsdata (snapshot, dump, bin\u00e6r kopi...), men de blir anonymisert. I stedet kan det finnes generasjonskripter: det kan v\u00e6re fixtures eller bare et skript som genererer en stor database. Problemet er: hvor lang tid tar det \u00e5 lage grunnbildet? Og hvor lang tid tar det \u00e5 implementere det i det n\u00f8dvendige milj\u00f8et?<\/p>\n

Vi har kommet frem til en plan: hvis kunden har et sett med fixturedata (minimumsversjon av databasen), bruker vi dem som standard. Hvis det gjelder review-milj\u00f8er, n\u00e5r vi har opprettet en gren og deployet en instans av applikasjonen \u2014 da ruller vi ut en liten database der. variant<\/a><\/noindex>, n\u00e5r vi tar et dump fra produksjon en gang om dagen (om natten) og bygger et Docker-container basert p\u00e5 det dumpet med PostgreSQL og MySQL med disse innlastede dataene. Hvis man m\u00e5 implementere databasen 50 ganger fra dette bildet, kan det gj\u00f8res ganske enkelt og raskt.<\/p>\n

NS<\/b>: Bare ved \u00e5 kopiere?<\/i><\/p>\n

DS<\/b>: Dataene lagres rett i Docker-bildet. Det vil si at vi har et klart bilde, la oss si p\u00e5 100 Gb. Takket v\u00e6re lagene i Docker kan vi raskt implementere dette bildet s\u00e5 mange ganger vi trenger. Metoden er enkel, men fungerer ganske bra.<\/p>\n

NS<\/b>: Videre, n\u00e5r du tester, endres det direkte inne i Docker, ikke sant? Copy-on-write inne i Docker \u2014 vi kaster bort det og starter p\u00e5 nytt, alt er bra. Flott! Og bruker du dette allerede p\u00e5 fullt?<\/i><\/p>\n

DS<\/b>: Ja, lenge.<\/p>\n

NS<\/b>: Vi gj\u00f8r veldig lignende ting. Bare at vi ikke bruker Docker's copy-on-write, men en eller annen annen metode.<\/i><\/p>\n

DS<\/b>: Den er ikke generell. Docker's l\u00f8sning fungerer overalt.<\/p>\n

NS<\/b>: I teorien, ja. Men vi har ogs\u00e5 moduler, man kan lage forskjellige moduler og arbeide med ulike filsystemer. Her er poenget. Vi ser p\u00e5 alt dette fra PostgreSQLs perspektiv. N\u00e5 har jeg sett fra Docker's perspektiv og sett at alt fungerer for dere. Men hvis databasen er stor, for eksempel 1 TB, da tar det lengre tid: b\u00e5de operasjoner om natten og \u00e5 putte alt i Docker... Og hva med \u00e5 putte 5 TB i Docker... Eller g\u00e5r det greit?<\/i><\/p>\n

DS<\/b>: Hva gj\u00f8r det? Det er bare blobs, bare biter og bytes.<\/p>\n

NS<\/b>: Forskjellen er: gj\u00f8r dere det via dump og restore?<\/i><\/p>\n

DS<\/b>: Det er overhodet ikke n\u00f8dvendig. Metoder for \u00e5 generere dette bildet kan v\u00e6re forskjellige.<\/p>\n

NS<\/b>: For some clients, we have arranged that instead of regularly generating a basic image, we keep it updated continuously. Essentially, it\u2019s a replica, but the data is not fetched directly from the master; it comes through an archive. A binary archive where WALs are applied every day, and backups are taken there\u2026 These WALs then travel\u2014 with a slight delay (literally 1-2 seconds)\u2014 to the basic image. From it, we clone in any way\u2014 by default, we now use ZFS.<\/i><\/p>\n

DS<\/b>: Men med ZFS er du begrenset til \u00e9n node.<\/p>\n

NS<\/b>: Ja. Men ZFS har en magisk send<\/a><\/noindex>: med det kan du sende et snapshot og til og med (jeg har ikke testet dette s\u00e5 mye, men\u2026) kan du sende endringene mellom to PGDATA<\/code>. Faktisk har vi et annet verkt\u00f8y som vi ikke har vurdert s\u00e5 mye for slike oppgaver. I PostgreSQL finnes det pg_rewind<\/a><\/noindex>, som fungerer som en \u00absmart\u00bb rsync, og hopper over mye av det som ikke trenger \u00e5 bli sett p\u00e5, fordi det ikke har endret seg i det hele tatt. Vi kan gj\u00f8re en rask synkronisering mellom to servere og rulle tilbake p\u00e5 samme m\u00e5te.<\/i><\/p>\n

So, we are trying to create a tool from this more DBA side that allows us to do the same thing you mentioned: we have one database, but we want to test something 50 times, almost simultaneously.<\/i><\/p>\n

DS<\/b>: 50 times means that you need to order 50 Spot instances.<\/p>\n

NS<\/b>: Nei, vi gj\u00f8r alt p\u00e5 \u00e9n maskin.<\/i><\/p>\n

DS<\/b>: Men hvordan skal du distribuere det 50 ganger, hvis denne ene databasen er for eksempel terabyte stor? Den trenger sannsynligvis omtrent 256 GB RAM?<\/p>\n

NS<\/b>: Ja, noen ganger trenger du mye minne \u2014 det er normalt. Men her er et eksempel fra virkeligheten. P\u00e5 produksjonsmaskinen er det 96 kjerner og 600 GB. For databasen brukes 32 kjerner (noen ganger til og med 16 kjerner n\u00e5) og 100-120 GB minne.<\/i><\/p>\n

DS<\/b>: F\u00e5r du plass til 50 kopier der?<\/p>\n

NS<\/b>: So, there\u2019s only one copy, then copy-on-write (ZFS) works\u2026 I\u2019ll explain in more detail.<\/i><\/p>\n

For eksempel, vi har en database p\u00e5 10 TB. Disken for den er laget, ZFS komprimerte st\u00f8rrelsen med 30-40 prosent. Siden vi ikke gj\u00f8r belastningstesting, er faktisk responstid ikke viktig for oss: hvis det er opptil 2 ganger tregere \u2014 det er greit.<\/i><\/p>\n

We provide programmers, QA, DBAs, etc., the possibility to perform testing in 1-2 streams. For example, they can launch some migration. It doesn\u2019t require all 10 cores at once \u2014 it needs 1 backend of Postgres, 1 core. The migration will start\u2014 maybe, autovacuum<\/a><\/noindex> den vil starte igjen, da blir den andre kjernen aktivert. Vi har avsatt 16-32 kjerner, s\u00e5 10 personer kan arbeide samtidig, det er ingen problemer.<\/i><\/p>\n

Siden fysisk PGDATA<\/code> it turns out to be identical, so we are actually deceiving Postgres. The trick is this: for example, 10 Postgres instances are launched simultaneously. What\u2019s usually the problem? They set up shared_buffers<\/a><\/noindex>, la oss si, til 25%. Dermed er det 200 GB. Mer enn tre slike kan du ikke starte fordi minnet vil ta slutt.<\/i><\/p>\n

Men vi inns\u00e5 p\u00e5 et tidspunkt at det ikke var n\u00f8dvendig: vi setter shared_buffers til 2 GB. PostgreSQL har en effective_cache_size<\/a><\/noindex>, og i virkeligheten p\u00e5virker bare den planene<\/a><\/noindex>. Den setter vi til 0,5 TB. Og det er ikke engang viktig at de faktisk ikke er der: den bygger planer som om de er der.<\/i><\/p>\n

Accordingly, when we test some migration, we can gather all the plans \u2014 we will see how it will happen in production. The seconds will be different (slower), but the data we actually read, and the plans themselves (what JOINs there are, etc.) are exactly the same as in production. And at the same time, we can run many such checks on one machine.<\/i><\/p>\n

DS<\/b>: Mener du ikke at det her er flere problemer? Det f\u00f8rste \u2013 dette er en l\u00f8sning som kun fungerer p\u00e5 PostgreSQL. En s\u00e5nn tiln\u00e6rming er veldig spesifikk, den er ikke generisk. Det andre \u2013 Kubernetes (og alt som n\u00e5 skjer med skyteknologi) forutsetter mange noder, og disse nodene er flyktige. I ditt tilfelle er det en stateful, vedvarende node. Disse tingene gir meg motstridende f\u00f8lelser.<\/p>\n

NS<\/b>: First \u2014 I agree, this is purely a Postgres story. I think if we have any direct IO and a buffer pool almost under all the memory, this approach won\u2019t work\u2014 the plans will be different. But we are currently only working with Postgres; we\u2019re not thinking about others.<\/i><\/p>\n

N\u00e5r det gjelder Kubernetes. Du forteller jo selv overalt at vi har en vedvarende database. Hvis instansen faller, er det viktigste \u00e5 bevare disken. V\u00e5r plattform er ogs\u00e5 i Kubernetes, og komponenten med Postgres er separat (selv om den en dag ogs\u00e5 vil v\u00e6re der). S\u00e5nn er det: instansen har falt, men vi har bevart dens PV og bare koblet den til en annen (ny) instans, som om ingenting har skjedd.<\/i><\/p>\n

DS<\/b>: From my perspective, we are creating pods in Kubernetes. K8s is elastic: nodes are ordered as needed. The task is simply to create a pod and specify that it needs X resources, and then K8s will manage it itself. However, storage support in Kubernetes remains unstable: in 1.16<\/a><\/noindex>, i 1.17<\/a><\/noindex> (denne utgaven kom ut uker<\/i> siden) disse funksjonene blir bare beta.<\/p>\n

Det vil g\u00e5 et halvt \u00e5r til et \u00e5r - da blir det mer eller mindre stabilt, eller i det minste vil det bli erkl\u00e6rt slik. Da vil muligheten for snapshots og resize l\u00f8se oppgaven din helt. For du har en database. Ja, den kan v\u00e6re ikke s\u00e5 veldig rask, men hastigheten avhenger av hva som er \"under panseret\", for noen implementeringer kan h\u00e5ndtere kopiering og copy-on-write p\u00e5 niv\u00e5et til diskunderlaget.<\/p>\n

NS<\/b>: Her m\u00e5 vi ogs\u00e5 s\u00f8rge for at alle motorer (Amazon, Google\u2026) har begynt \u00e5 st\u00f8tte denne versjonen \u2013 det tar jo ogs\u00e5 litt tid.<\/i><\/p>\n

DS<\/b>: Vi bruker dem ikke enn\u00e5. Vi bruker v\u00e5rt eget.<\/p>\n

Lokal utvikling p\u00e5 Kubernetes<\/h2>\n

\nNS<\/b>: Har du noen gang opplevd et \u00f8nske om \u00e5 heve alle pod-er p\u00e5 en maskin og gj\u00f8re en liten testing? For raskt \u00e5 f\u00e5 et proof of concept, sjekke at applikasjonen fungerer i Kubernetes, uten \u00e5 reservere en haug med maskiner. Det finnes Minikube, ikke sant?<\/i><\/p>\n

DS<\/b>: Jeg mener, denne saken \u2013 \u00e5 deploye p\u00e5 \u00e9n node \u2013 handler utelukkende om lokal utvikling. Eller noen manifestasjoner av dette m\u00f8nsteret. Det finnes Minikube<\/a><\/noindex>, det finnes k3s<\/a><\/noindex>, KIND<\/a><\/noindex>. Vi g\u00e5r mot \u00e5 bruke Kubernetes IN Docker. Vi har akkurat begynt \u00e5 jobbe med det for tester.<\/p>\n

NS<\/b>: Jeg trodde tidligere at dette var et fors\u00f8k p\u00e5 \u00e5 pakke alle pod-er inn i et Docker-bilde. Men det viste seg \u00e5 v\u00e6re noe helt annet. Fortsatt har du separate containere, separate pod-er - bare i Docker.<\/i><\/p>\n

DS<\/b>: Ja. Og der er det laget en ganske morsom simulering, men poenget er slik \u2026 Vi har et verkt\u00f8y for deploy \u2013 werf<\/a><\/noindex>. Vi \u00f8nsker \u00e5 lage en modus i den \u2013 la oss si werf up<\/code>: \u00abSette opp en lokal Kubernetes for meg\u00bb. Og deretter kj\u00f8re en bestemt werf follow<\/code>. Da kan utvikleren gj\u00f8re endringer i IDE, mens det g\u00e5r en prosess i systemet som ser endringene og bygger bildene p\u00e5 nytt, deployer dem i lokal K8s. Det er slik vi \u00f8nsker \u00e5 fors\u00f8ke \u00e5 l\u00f8se problemet med lokal utvikling.<\/p>\n

Snapshots og kloning av databaser i K8s<\/h2>\n

\nNS<\/b>: Hvis vi g\u00e5r tilbake til copy-on-write. Jeg har lagt merke til at skytjenester ogs\u00e5 har snapshots. De fungerer forskjellig. For eksempel i GCP: du har en fler-terabyte instans p\u00e5 \u00f8stkysten av USA. Du tar snapshots med jevne mellomrom. Du hever en kopi av disken fra et snapshot p\u00e5 vestkysten - etter noen f\u00e5 minutter er alt klart, det fungerer veldig raskt, bare cache m\u00e5 fylles opp i minnet. Men disse klonene (snapshots) er ment for \u00e5 \"provision\" et nytt volum. Det er flott n\u00e5r du trenger \u00e5 opprette mange instanser.<\/i><\/p>\n

Men for tester, synes jeg at snapshots, som du snakker om i Docker, eller jeg snakker om i ZFS, btrfs, og til og med LVM\u2026 - de lar deg faktisk unng\u00e5 \u00e5 lage reelle nye data p\u00e5 en maskin. I skyen m\u00e5 du ogs\u00e5 betale for dem hver gang og vente ikke lenger sekunder, men minutter (og i tilfelle lazy load<\/a><\/noindex>).<\/i><\/p>\n

I stedet kan man f\u00e5 disse dataene p\u00e5 ett til to sekunder, kj\u00f8re testen og s\u00e5 kaste dem. Disse snapshotene l\u00f8ser forskjellige oppgaver. I det f\u00f8rste tilfellet \u2013 for \u00e5 skalere opp og f\u00e5 nye kopier, i det andre \u2013 for tester.<\/i><\/p>\n

DS<\/b>: Jeg er ikke enig. \u00c5 gj\u00f8re volumkloning skikkelig er en oppgave for skyen. Jeg har ikke sett implementeringen deres, men jeg vet hvordan vi gj\u00f8r det p\u00e5 maskinvaren v\u00e5r. Vi har Ceph, hvor man kan si til ethvert fysisk volum (RBD<\/a><\/noindex>) klon<\/i> og f\u00e5 et nytt volum med de samme egenskapene p\u00e5 bare noen titalls millisekunder, IOPS<\/a><\/noindex>og s\u00e5 videre. Man m\u00e5 forst\u00e5 at det er en smart copy-on-write der inne. Hvorfor kan ikke skyen gj\u00f8re det samme? Jeg er sikker p\u00e5 at de pr\u00f8ver \u00e5 f\u00e5 det til p\u00e5 en eller annen m\u00e5te.<\/p>\n

NS<\/b>: Men de vil fortsatt bruke sekunder, titalls sekunder, p\u00e5 \u00e5 starte opp en instans, sette opp Docker, osv.<\/i><\/p>\n

DS<\/b>: Hvorfor m\u00e5 man n\u00f8dvendigvis starte en hel instans? Vi har jo en instans med 32 kjerner, 16 kjerner\u2026 og den kan h\u00e5ndtere en viss mengde \u2014 for eksempel fire. N\u00e5r vi bestiller den femte, vil det allerede bli startet en instans, og s\u00e5 vil den bli slettet.<\/p>\n

NS<\/b>: Ja, interessant, i Kubernetes er det en annen historie. Vi har ikke databasen i K8s, og bruker bare \u00e9n instans. Men \u00e5 klone en multi-terabyte database tar ikke mer enn to sekunder.<\/i><\/p>\n

DS<\/b>: Det er kult. Men mitt opprinnelige poeng er at dette ikke er et generisk l\u00f8sningen. Ja, det er bra, men passer kun for Postgres og bare p\u00e5 \u00e9n node.<\/p>\n

NS<\/b>: Det er ikke bare for Postgres: disse planene, som jeg beskrev, vil fungere slik kun i det. Men hvis man ikke bryr seg om planer, og vi bare trenger alle dataene til funksjonell testing, da er det passende for enhver DBMS.<\/i><\/p>\n

DS<\/b>: For mange \u00e5r siden gjorde vi noe lignende med LVM-snapshots. Det er klassisk. Denne tiln\u00e6rmingen ble brukt veldig aktivt. Bare stateful-noder er et problem. Fordi de m\u00e5 ikke krasje, man m\u00e5 alltid huske p\u00e5 dem\u2026<\/p>\n

NS<\/b>: Ser du ikke her en mulighet for et hybridopplegg? La oss si, stateful er en pod, den fungerer for flere mennesker (mange testere). Vi har \u00e9n volum, men takket v\u00e6re filsystemet er klonene lokale. Hvis podden krasjer, blir disken v\u00e6rende \u2014 podden blir gjenopprettet, tar informasjon om alle klonene, gjenoppretter alt og sier: \u00abHer er klonene deres p\u00e5 disse portene, fortsett \u00e5 jobbe med dem\u00bb.<\/i><\/p>\n

DS<\/b>: Tekniskt sett betyr det at innenfor Kubernetes er dette en pod, der vi kj\u00f8rer mange Postgres-er.<\/p>\n

NS<\/b>: Ja. Den har en grense: la oss si, samtidig jobber ikke mer enn 10 personer med den. Hvis man trenger 20 \u2014 starter vi en ny slik pod. Det er helt mulig \u00e5 klone den, og f\u00e5 et fullt volum, hvor det vil v\u00e6re ti \u00abtynne\u00bb kloner av den. Ser du ikke muligheten her?<\/i><\/p>\n

DS<\/b>: M\u00e5 legge til sikkerhetssp\u00f8rsm\u00e5l her. Denne organisasjonsvarianten inneb\u00e6rer at denne pod’en har h\u00f8ye privilegier (capabilities), fordi den kan utf\u00f8re ikke-standardoperasjoner p\u00e5 filsystemet\u2026 Men jeg gjentar: jeg tror at p\u00e5 mellomlang sikt vil Kubernetes fikse lagring, og i skyene vil de ordne alt som har med volumer \u00e5 gj\u00f8re - alt vil \u00abbare fungere\u00bb. Det vil bli resize, kloning\u2026 Det finnes et volum - vi sier: \u00abLag en ny basert p\u00e5 den\u00bb, - og etter halvannet sekund f\u00e5r vi det vi trenger.<\/p>\n

NS<\/b>: Jeg tror ikke p\u00e5 ett og et halvt sekund for mange terabyte. P\u00e5 Ceph gj\u00f8r du det selv, men du snakker om skyene. G\u00e5 til skyen, p\u00e5 EC2 gj\u00f8r et klon av EBS-volumet p\u00e5 mange terabyte og se hvilken ytelse det f\u00e5r. Det vil ikke ta flere sekunder. Jeg er veldig interessert i n\u00e5r de vil n\u00e5 et slikt m\u00e5l. Jeg forst\u00e5r hva du snakker om, men jeg lar meg selv v\u00e6re uenig.<\/i><\/p>\n

DS<\/b>: Ok, men jeg sa at p\u00e5 mellomlang sikt, ikke kortsiktig. I l\u00f8pet av noen \u00e5r.<\/p>\n

Om operatoren for PostgreSQL fra Zalando<\/h2>\n

\nMidt i dette m\u00f8tet koblet ogs\u00e5 Alexey Klyukin seg til, en tidligere utvikler fra Zalando, som fortalte om historien til PostgreSQL-operatoren:<\/p>\n

Det er flott at dette emnet i det hele tatt ble tatt opp: b\u00e5de Postgres og Kubernetes. Da vi begynte \u00e5 jobbe med det i Zalando i 2017, var dette et emne som alle ville jobbe med, men ingen gjorde det. Alle hadde allerede f\u00e5tt Kubernetes, men n\u00e5r de spurte hvordan de skulle h\u00e5ndtere databasene, var til og med folk som Kelsey Hightower<\/a><\/noindex>, som forkynte K8s, omtrent sa f\u00f8lgende:<\/p>\n

\u00abG\u00e5 til managed-tjenester og bruk dem, ikke kj\u00f8r databaser i Kubernetes. Ellers vil K8s ditt for eksempel bestemme seg for \u00e5 oppgradere, slukke alle noder, og dataene dine vil fly langt, langt bort\u00bb.<\/i><\/p>\n

Vi bestemte oss for \u00e5 lage en operator som, til tross for dette r\u00e5det, ville kj\u00f8re Postgres-databaser i Kubernetes. Og vi hadde et godt grunnlag - Patroni<\/a><\/noindex>. Dette er automatisk failover for PostgreSQL, gjort riktig, det vil si ved hjelp av etcd, consul eller ZooKeeper som lagringsl\u00f8sning for informasjon om klyngen. En slik lagringsl\u00f8sning som vil gi alle som sp\u00f8r, for eksempel, hvem som for \u00f8yeblikket er lederen, den samme informasjonen - til tross for at vi har alt distribuert - for \u00e5 unng\u00e5 split brain’. I tillegg hadde vi Docker-image<\/a><\/noindex> for det.<\/p>\n

Generelt oppstod behovet for auto failover etter migrasjonen fra et internt datacenter med fysisk infrastruktur til skyen. Skyen var basert p\u00e5 en egen PaaS (Platform-as-a-Service) l\u00f8sning. Den er Open Source’, men for \u00e5 sette den opp m\u00e5tte man legge ned mye arbeid. Den ble kalt STUPS<\/a><\/noindex>.<\/p>\n

Opprinnelig fantes det ikke noe Kubernetes’er. Mer spesifikt, da den egenutviklede l\u00f8sningen ble rullet ut, fantes K8s allerede, men det var s\u00e5 umodent at det ikke var egnet for produksjon. Dette var, etter min mening, i 2015 eller 2016. Innen 2017 hadde Kubernetes blitt mer eller mindre modent - det oppstod et behov for migrering dit.<\/p>\n

Og vi hadde allerede en Docker-container. Det var en PaaS som brukte Docker. Hvorfor ikke pr\u00f8ve K8s? Hvorfor ikke skrive en egen operator? Murat Kabilov, som kom til oss fra Avito, startet dette som et prosjekt p\u00e5 egenh\u00e5nd \u2014 for \u00e5 'lekke', \u2014 og prosjektet 'fl\u00f8y'.<\/p>\n

Men jeg \u00f8nsket egentlig \u00e5 fortelle om AWS. Hvorfor det historisk var kode knyttet til AWS...<\/p>\n

N\u00e5r du kj\u00f8rer noe i Kubernetes, m\u00e5 du forst\u00e5 at K8s er et work in progress. Det utvikles stadig, forbedres og noen ganger til og med bryter ned. Man m\u00e5 f\u00f8lge med p\u00e5 alle endringer i Kubernetes, v\u00e6re klar til \u00e5 dykke ned i det om n\u00f8dvendig og finne ut hvordan det fungerer i detalj \u2014 kanskje mer enn du \u00f8nsket. Dette gjelder generelt for enhver plattform der du kj\u00f8rer databasene dine...<\/p>\n

S\u00e5, da vi laget operatoren, hadde vi Postgres som jobbet med en ekstern volum (i dette tilfellet \u2014 EBS, siden vi jobbet i AWS). Databasen vokste, og p\u00e5 et tidspunkt ble det n\u00f8dvendig \u00e5 gj\u00f8re en resize: for eksempel, den opprinnelige st\u00f8rrelsen p\u00e5 EBS var 100 TB, databasen vokste til denne st\u00f8rrelsen, n\u00e5 vil vi gj\u00f8re EBS til 200 TB. Hvordan? La oss si at man kan lage dump\/restore til en ny instans, men det er tidkrevende og med nedetid.<\/p>\n

Derfor \u00f8nsket vi en resize som ville \u00f8ke EBS’en og deretter fortelle filsystemet \u00e5 bruke det nye rommet. Og vi gjorde det, men p\u00e5 den tiden hadde ikke Kubernetes noe API for resize-operasjonen. Siden vi arbeidet p\u00e5 AWS, skrev vi kode for API-en.<\/p>\n

Ingen hindrer \u00e5 gj\u00f8re det samme for andre plattformer. I operatoren er det ingen binding som sier at den kun kan kj\u00f8res p\u00e5 AWS, og at den ikke vil fungere p\u00e5 alt annet. Generelt er dette et Open Source-prosjekt: hvis noen \u00f8nsker \u00e5 forkorte introduksjonen av den nye API-en \u2014 v\u00e6r s\u00e5 god. GitHub<\/a><\/noindex>, pull-foresp\u00f8rslene \u2014 Zalando-teamet fors\u00f8ker ganske raskt \u00e5 reagere p\u00e5 dem og fremme operat\u00f8ren. S\u00e5 vidt jeg vet, deltok prosjektet i<\/a><\/noindex> Google Summer of Code og andre lignende initiativer. Zalando jobber veldig aktivt med det.\n<\/p><\/blockquote>\n

<\/p>\n

P.S. Bonus!<\/h2>\n

\nHvis du er interessert i temaet PostgreSQL og Kubernetes, vil vi ogs\u00e5 henlede oppmerksomheten p\u00e5 at forrige uke ble den neste Postgres-tirsdagen holdt, hvor Nikolai snakket med Alexander Kukushkin fra Zalando<\/b>. Videoen er tilgjengelig her<\/a><\/noindex>.<\/p>\n

P.P.S.<\/h2>\n

\nAlso read in our blog:<\/p>\n