{"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\/da\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Postgres-tirsdag nr. 5: \u00abPostgreSQL og Kubernetes. CI\/CD. Automatisering af test\u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Postgres-tirsdag
\n
\nI slutningen af det forgangne \u00e5r fandt endnu et direkte livestream af det russiske PostgreSQL-f\u00e6llesskab sted #RuPostgres<\/a><\/noindex>, hvor dens medstifter Nikolaj Samokhvalov talte med den tekniske direkt\u00f8r for \u00abFlant\u00bb, Dmitrij Stolyarov, om denne database i konteksten af Kubernetes.<\/p>\n

Vi offentligg\u00f8r nu transkriptet af hoveddelen af denne diskussion, og p\u00e5 YouTube-kanalen for f\u00e6llesskabet<\/a><\/noindex> er den fulde video optagelse offentliggjort:<\/a><\/noindex><\/p>\n

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

Databaser og Kubernetes<\/h2>\n

\nNS<\/b>: Vi vil ikke tale om VACUUM og CHECKPOINTs i dag. Vi vil gerne tale om Kubernetes. Jeg ved, at du har mange \u00e5rs erfaring. Jeg har set dine videoer, og nogle af dem har jeg endda set flere gange\u2026 Lad os komme direkte til sagen: hvorfor overhovedet Postgres eller MySQL i K8s?<\/i><\/p>\n

DS<\/b>: Der er ikke et entydigt svar p\u00e5 dette sp\u00f8rgsm\u00e5l. Men generelt, det er enkelheden og bekvemmeligheden\u2026 potentielt. Alle \u00f8nsker jo managed-tjenester.<\/p>\n

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

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

NS<\/b>: \u00abHvor som helst\u00bb \u2014 det er et godt punkt. I store virksomheder er alt placeret forskellige steder. Hvorfor s\u00e5 ikke tage en f\u00e6rdig l\u00f8sning, hvis det er en stor virksomhed? For eksempel har Nutanix sine egne udviklinger, og andre virksomheder (VMware\u2026) har den samme \u00abRDS, bare hos sig selv\u00bb.<\/i><\/p>\n

DS<\/b>: Men det taler vi om en specifik implementering, der kun vil fungere under bestemte forhold. Hvis det handler om Kubernetes, s\u00e5 er der enorme variationer af infrastruktur (som kan v\u00e6re i K8s). I bund og grund er det en standard for API til skyen\u2026<\/p>\n

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

DS<\/b>: Det er ikke s\u00e5 vigtigt. Gratis er ikke s\u00e5 vigtigt for et stort segment af markedet. Det vigtigste er noget andet\u2026 Du husker m\u00e5ske mit foredrag \u00abDatabaser og Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

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

DS<\/b>: Jeg forstod, at det blev opfattet meget ambivalent. Nogle mennesker troede, at jeg sagde: \u00abLad os k\u00f8re alle databaser i Kubernetes!\u00bb, - mens andre mente, at det hele var frygtelige cykler. Men det, jeg ville sige, var noget helt andet: \u00abSe, hvad der sker, hvilke problemer der er, og hvordan de kan l\u00f8ses. Er det en god id\u00e9 at k\u00f8re databaser i Kubernetes? Production? Kun hvis du elsker\u2026 at lave visse ting. Men for dev? Jeg kan sige, at jeg anbefaler det. For dev er det meget vigtigt at kunne oprette\/fjerne milj\u00f8er dynamisk.<\/p>\n

NS: Mener du ved dev alle milj\u00f8er, der ikke er prod? Staging, QA\u2026<\/i><\/p>\n

DS<\/b>: Hvis vi taler om perf-stande, s\u00e5 er det nok ikke muligt, fordi kravene her er specifikke. Hvis vi taler om s\u00e6rlige tilf\u00e6lde, hvor der er brug for en meget stor database p\u00e5 staging, s\u00e5 er det ogs\u00e5 nok ikke muligt... Hvis det er et statisk milj\u00f8, der lever l\u00e6nge, hvad er s\u00e5 fordelen ved, at databasen er placeret i K8s?<\/p>\n

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

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

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

DS<\/b>: Jeg har en rigtig fed case! P\u00e5 staging er der en prod-database, hvor der laves \u00e6ndringer. Der er en knap: \u00abUdgiv til production\u00bb. Disse \u00e6ndringer, deltas, integreres (det ser ud til, at de bare synkroniseres via API) i produktion. Dette er en meget eksotisk l\u00f8sning.<\/p>\n

NS<\/b>: Jeg har set startups i Dalley, som stadig k\u00f8rer p\u00e5 RDS eller endda i Heroku - det er historier fra 2-3 \u00e5r tilbage - og de downloader en dump til deres laptop. Fordi databasen kun er 80 GB, og der er plads p\u00e5 laptoppen. Derefter k\u00f8ber de diske til hver, s\u00e5 de kan have 3 databaser at arbejde med p\u00e5 forskellige projekter. S\u00e5dan kan det ogs\u00e5 ske. Jeg har ogs\u00e5 set, at nogle ikke er bange for at kopiere prod til staging - det afh\u00e6nger meget af virksomheden. Men jeg har ogs\u00e5 set, at nogle er udsatte for frygt, og at der ofte ikke er tid og h\u00e6nder nok. Men f\u00f8r vi g\u00e5r videre til dette emne, vil jeg gerne h\u00f8re om Kubernetes. Forst\u00e5r jeg det korrekt, at der ikke er nogen i prod endnu?<\/i><\/p>\n

DS<\/b>: Vi har nogle sm\u00e5 databaser i prod. Der er tale om volumener i titusinder af gigabyte og ikke-kritiske services, for hvilke det var for besv\u00e6rligt at lave replikater (og der er egentlig ikke behov for det). Og forudsat, at der er en ordentlig lagring under Kubernetes. Denne database k\u00f8rte p\u00e5 en virtuel maskine - betingelsesvis i VMware, oven p\u00e5 storage. Vi placerede den i PV<\/a><\/noindex> og nu kan vi flytte den fra maskine til maskine.<\/p>\n

NS<\/b>: Databaser af denne st\u00f8rrelse, op til 100 GB, p\u00e5 gode diske og med et godt netv\u00e6rk kan udrulles p\u00e5 f\u00e5 minutter, er det ikke korrekt? En hastighed p\u00e5 1 GB i sekundet er ikke l\u00e6ngere eksotisk.<\/i><\/p>\n

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

NS<\/b>: Okay, vi skal kun t\u00e6nke p\u00e5 produktionen. Men hvis vi overvejer Kubernetes til ikke-produktionsmilj\u00f8er - hvordan g\u00f8r man s\u00e5? Jeg ser, at Zalando laver en operat\u00f8r<\/a><\/noindex>, i Crunchy bygger de<\/a><\/noindex>, der er ogs\u00e5 nogle andre muligheder. Og der er OnGres<\/a><\/noindex> - det er vores gode ven Alvaro fra Spanien: de laver ikke bare en operat\u00f8r<\/a><\/noindex>, men en hel distribution (StackGres<\/a><\/noindex>), hvor vi besluttede at placere en backup udover selve Postgres, proxy Envoy\u2026<\/i><\/p>\n

DS<\/b>: Hvad er Envoy til? Til belastningsfordeling af Postgres-trafik?<\/p>\n

NS<\/b>: Ja. Alts\u00e5, de ser det som: hvis vi tager en Linux-distribution og kernen, s\u00e5 er den almindelige PostgreSQL kernen, og de \u00f8nsker at lave en distribution, der er venlig mod cloud og kan k\u00f8re i Kubernetes. De forbinder komponenter (backup osv.) og justerer dem, s\u00e5 de fungerer godt.<\/i><\/p>\n

DS<\/b>: Meget godt! Grundl\u00e6ggende er det software til at lave sin egen managed Postgres.<\/p>\n

NS<\/b>: Linux-distributioner har evige problemer: hvordan man laver drivere, s\u00e5 alt hardware underst\u00f8ttes. Og deres id\u00e9 er, at de vil fungere i Kubernetes. Jeg ved, at vi for nylig s\u00e5 en binding til AWS i Zalando-operationssystemet, og det er ikke s\u00e5 godt. Der burde ikke v\u00e6re binding til en specifik infrastruktur \u2013 hvad er meningen s\u00e5?<\/i><\/p>\n

DS<\/b>: Jeg ved ikke, under hvilke forhold Zalando er bundet, men i Kubernetes er storage nu lavet s\u00e5dan, at man ikke kan tage en diskbackup p\u00e5 en generisk m\u00e5de. For nylig i standarden \u2013 i den seneste version specifikationen CSI<\/a><\/noindex> \u2013 har de gjort det muligt at tage snapshots, men hvor er det implementeret? \u00c6rligt talt, det er stadig s\u00e5 ufuldst\u00e6ndigt... Vi pr\u00f8ver CSI ovenp\u00e5 AWS, GCE, Azure, vSphere, men s\u00e5 snart man begynder at bruge det, kan man se, at det ikke er klar endnu.<\/p>\n

NS<\/b>: Derfor m\u00e5 man nogle gange binde sig til infrastrukturen. Jeg tror, det stadig er i en tidlig fase \u2013 v\u00e6kstproblemer. Sp\u00f8rgsm\u00e5l: hvad ville du anbefale nybegyndere, der \u00f8nsker at pr\u00f8ve PgSQL i K8s? Hvilken operator, m\u00e5ske?<\/i><\/p>\n

DS<\/b>: Problemet er, at Postgres kun udg\u00f8r 3% for os. Vi har en meget stor liste af forskellig software i Kubernetes, og jeg vil ikke engang opremse alt. For eksempel, Elasticsearch. Der er mange operat\u00f8rer: nogle udvikler sig aktivt, andre g\u00f8r ikke. Vi har defineret kravene til, hvad der skal v\u00e6re i en operat\u00f8r, for at vi kan tage den alvorligt. I operat\u00f8ren specifikt for Kubernetes \u2013 ikke i 'operat\u00f8ren til at g\u00f8re noget i Amazon'... Faktisk bruger vi ret massivt (= n\u00e6sten alle kunder) den samme operat\u00f8r \u2013 til Redis<\/a><\/noindex> (snart udgiver vi en artikel om den)<\/i>.<\/p>\n

NS<\/b>: Men til MySQL er der heller ikke? Jeg ved, at Percona... da de nu besk\u00e6ftiger sig med b\u00e5de MySQL, MongoDB og Postgres, m\u00e5 de have en slags universel l\u00f8sning: for alle databaser, for alle cloud-udbydere.<\/i><\/p>\n

DS<\/b>: Vi har ikke haft tid til at se p\u00e5 operat\u00f8rer for MySQL. For os er det ikke det prim\u00e6re fokus lige nu. MySQL fungerer fint i stand-alone. Hvorfor have en operat\u00f8r, hvis man bare kan k\u00f8re databasen\u2026 Man kan k\u00f8re en Docker-container med Postgres, eller man kan g\u00f8re det p\u00e5 den enkel m\u00e5de.<\/p>\n

NS<\/b>: Det sp\u00f8rgsm\u00e5l kom ogs\u00e5 op. Slet ingen operat\u00f8r?<\/i><\/p>\n

DS<\/b>: Ja, vi k\u00f8rer 100% PostgreSQL uden operat\u00f8r. Lige nu er det s\u00e5dan. Vi bruger aktivt operat\u00f8ren til Prometheus og til Redis. Vi planl\u00e6gger at finde en operat\u00f8r til Elasticsearch \u2014 det er det, der 'br\u00e6nder' mest, fordi vi vil have det i 100% af tilf\u00e6ldene i Kubernetes. P\u00e5 samme m\u00e5de vil vi gerne have MongoDB til altid at blive installeret i Kubernetes. Her opst\u00e5r der visse \u00f8nsker \u2014 der er en f\u00f8lelse af, at der kan g\u00f8res noget i disse tilf\u00e6lde. Og hvad ang\u00e5r Postgres, har vi ikke engang kigget p\u00e5 det. Selvf\u00f8lgelig er vi klar over, at der findes forskellige muligheder, men faktum er, at vi har stand-alone.<\/p>\n

Database til test i Kubernetes<\/h2>\n

\nNS<\/b>: Lad os g\u00e5 videre til emnet testning. Hvordan ruller man \u00e6ndringer i databasen ud \u2014 fra et DevOps-perspektiv? Der er mikrotjenester, mange databaser, alt \u00e6ndrer sig hele tiden. Hvordan sikrer man en ordentlig CI\/CD, s\u00e5 alt er i orden fra databaseperspektiv? Hvad er din tilgang?<\/i><\/p>\n

DS<\/b>: Der kan ikke v\u00e6re \u00e9t svar. Der er flere parametre. Det f\u00f8rste er st\u00f8rrelsen p\u00e5 databasen, som vi \u00f8nsker at rulle ud. Du n\u00e6vnte selv, at virksomheder forholder sig forskelligt til, at en kopi af prod-databasen er p\u00e5 dev og stage.<\/p>\n

NS<\/b>: Og under GDPR, tror jeg, de er meget mere forsigtige... Jeg kan sige, at der allerede er begyndt at komme b\u00f8der i Europa.<\/i><\/p>\n

DS<\/b>: Men ofte kan man skrive software, der laver en dump fra produktionen og obfuskerer det. Det resulterer i produktionsdata (snapshot, dump, bin\u00e6r kopi\u2026), men de er anonymiserede. I stedet kan der v\u00e6re scripts til generation: det kan v\u00e6re fixtures eller blot et script, der genererer en stor database. Problemet er: hvor lang tid tager det at skabe en basal image? Og hvor lang tid tager det at deployere det i det \u00f8nskede milj\u00f8?<\/p>\n

Vi er kommet frem til en model: hvis kunden har et fixtures\u00e6t (minimumsversion af databasen), bruger vi dem som standard. Hvis det handler om review-milj\u00f8er, n\u00e5r vi har oprettet en branch, og vi har f\u00e5et udrullet en instans af applikationen \u2014 s\u00e5 udruller vi en lille database der. variant<\/a><\/noindex>, n\u00e5r vi om natten (\u00e9n gang dagligt) laver et dump fra produktionen og bygger en Docker-container med PostgreSQL og MySQL med disse indl\u00e6ste data. Hvis man skal deployere databasen 50 gange fra dette image, er det relativt simpelt og hurtigt.<\/p>\n

NS<\/b>: Er det bare ved simpel kopiering?<\/i><\/p>\n

DS<\/b>: Dataene opbevares direkte i Docker-billedet. Det vil sige, at vi har et f\u00e6rdigt billede, lad os sige 100 GB. Takket v\u00e6re lagene i Docker kan vi hurtigt deploye dette billede det n\u00f8dvendige antal gange. Metoden er simpel, men fungerer ret godt.<\/p>\n

NS<\/b>: Dern\u00e6st, n\u00e5r du tester, \u00e6ndrer det sig direkte inde i Docker, ikke? Copy-on-write inden for Docker \u2013 vi smider det ud og starter forfra, alt er godt. Klasse! Og bruger I allerede det fuldt ud?<\/i><\/p>\n

DS<\/b>: L\u00e6nge.<\/p>\n

NS<\/b>: Vi arbejder med meget lignende ting. Bare vi bruger ikke Docker's copy-on-write, men noget andet.<\/i><\/p>\n

DS<\/b>: Det er ikke generisk. Men Docker's virker overalt.<\/p>\n

NS<\/b>: I teorien, ja. Men vi har ogs\u00e5 moduler d\u00e9r, man kan lave forskellige moduler og arbejde med forskellige filsystemer. Her er punktet. Vi ser p\u00e5 det hele fra Postgres' perspektiv p\u00e5 en anden m\u00e5de. Nu har jeg set det fra Docker's synspunkt og set, at alt fungerer for jer. Men hvis databasen er k\u00e6mpe, for eksempel 1 TB, s\u00e5 er det allerede langt: b\u00e5de operationer om natten og at proppe alt ind i Docker... Eller er det helt i orden at proppe 5 TB ind i Docker?<\/i><\/p>\n

DS<\/b>: Hvad betyder det: det er jo blobs, bare bits og bytes.<\/p>\n

NS<\/b>: Forskellen er: g\u00f8r I det via dump og restore?<\/i><\/p>\n

DS<\/b>: Det er slet ikke n\u00f8dvendigt. Metoderne til at generere dette billede kan v\u00e6re forskellige.<\/p>\n

NS<\/b>: For some clients, we have set it up so that instead of regular base image generation, we keep it constantly updated. It essentially acts as a replica, but the data is not received directly from the master, but through an archive. A binary archive where WALs are applied daily, and backups are created there... These WALs then travel \u2014 with a slight delay (literally 1-2 seconds) \u2014 to the base image. From it, we clone in any way \u2014 currently, we default to ZFS.<\/i><\/p>\n

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

NS<\/b>: Ja. Men ZFS har ogs\u00e5 en magisk send<\/a><\/noindex>: med den kan du sende et snapshot, og endda (jeg har ikke rigtig testet det endnu, men\u2026) kan du sende forskellen mellem to PGDATA<\/code>. Faktisk har vi ogs\u00e5 et andet v\u00e6rkt\u00f8j, som vi ikke har overvejet meget til s\u00e5danne opgaver. I PostgreSQL er der pg_rewind<\/a><\/noindex>, der fungerer som \u00abintelligent\u00bb rsync og springer meget over, eftersom der ikke er sket nogen \u00e6ndringer. Vi kan lave en hurtig synkronisering mellem to servere og g\u00e5 tilbage p\u00e5 samme m\u00e5de.<\/i><\/p>\n

So we are trying to create a tool from this more DBA perspective, which 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 you need to order 50 Spot instances.<\/p>\n

NS<\/b>: Nej, vi g\u00f8r alt p\u00e5 \u00e9n maskine.<\/i><\/p>\n

DS<\/b>: Men hvordan vil du deploye 50 gange, hvis denne ene database, lad os sige, er terabyte stor? Den har sandsynligvis brug for 256 Gb RAM?<\/p>\n

NS<\/b>: Ja, nogle gange har man brug for meget hukommelse \u2013 det er normalt. Men s\u00e5dan et eksempel fra virkeligheden. P\u00e5 produktionsmaskinen er der 96 kerner og 600 Gb. For databasen bruges 32 kerner (endda nogle gange 16 kerner nu) og 100-120 Gb hukommelse.<\/i><\/p>\n

DS<\/b>: Og kan der v\u00e6re 50 kopier derinde?<\/p>\n

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

For eksempel har vi en database p\u00e5 10 Tb. Vi lavede en disk til den, ZFS komprimerede dens st\u00f8rrelse med 30-40%. Da vi ikke laver belastningstest, er den pr\u00e6cise svartid ikke vigtig: det kan v\u00e6re op til 2 gange langsommere \u2013 det er okay.<\/i><\/p>\n

We allow programmers, QA, DBAs, etc. to perform testing in 1-2 streams. For example, they can initiate some migration. It doesn\u2019t require 10 cores right away \u2014 it needs 1 backend of Postgres, 1 core. The migration will start \u2014 maybe, autovacuum<\/a><\/noindex> vil starte op, s\u00e5 den anden kerne aktiveres. Vi har 16-32 kerner tildelt, s\u00e5 10 personer kan arbejde samtidig, ingen problemer.<\/i><\/p>\n

Da 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. The usual problem is that they set up shared_buffers<\/a><\/noindex>, lad os sige, til 25%. Det vil sige, det er 200 Gb. Mere end tre af dem kan man ikke starte, fordi hukommelsen l\u00f8ber t\u00f8r.<\/i><\/p>\n

Men vi inds\u00e5 p\u00e5 et tidspunkt, at det ikke er n\u00f8dvendigt: vi s\u00e6tter shared_buffers til 2 Gb. PostgreSQL har effective_cache_size<\/a><\/noindex>, og i virkeligheden p\u00e5virker kun det planerne<\/a><\/noindex>. Det s\u00e6tter vi til 0,5 Tb. Og det er ikke engang vigtigt, at de ikke reelt er der: den bygger planer, som om de er.<\/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 there will be different (slower), but the data that we are really reading, and the plans themselves (what JOINs, etc.) turn out to be exactly the same as in production. And we can simultaneously run many such checks on one machine.<\/i><\/p>\n

DS<\/b>: T\u00e6nker du ikke, at der er flere problemer her? Det f\u00f8rste - det er en l\u00f8sning, der kun virker p\u00e5 PostgreSQL. Denne tilgang er meget specifik, den er ikke generisk. Det andet - Kubernetes (og alt, hvad cloud-teknologierne bev\u00e6ger sig imod) indeb\u00e6rer mange noder, og disse noder er efem\u00e6re. I dit tilf\u00e6lde er det en stateful, vedholdende node. Disse ting giver mig modstridende f\u00f8lelser.<\/p>\n

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

Om Kubernetes. Du fort\u00e6ller jo selv overalt, at vores database er vedholdende. Hvis en instans fejler, er det vigtigste at bevare disken. Vores platform er ogs\u00e5 i Kubernetes, men komponenten med Postgres er separat (selvom den en dag vil v\u00e6re der). Derfor er det s\u00e5dan: instansen fejler, men vi har bevaret dens PV og tilsluttet det til en anden (ny) instans, som om intet var sket.<\/i><\/p>\n

DS<\/b>: From my point of view, we create 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 handle the rest. But storage support in Kubernetes is still unstable: in 1.16<\/a><\/noindex>, i 1.17<\/a><\/noindex> (denne version blev udgivet uger<\/i> siden) disse funktioner er kun i beta.<\/p>\n

Det tager et halvt \u00e5r til et \u00e5r, f\u00f8r det bliver nogenlunde stabilt, eller i det mindste bliver deklareret som s\u00e5dan. S\u00e5 muligheden for snapshots og resize l\u00f8ser helt dit problem. Fordi du har en database. Ja, den kan v\u00e6re lidt langsom, men hastigheden afh\u00e6nger af, hvad der er 'under motorhjelmen', da nogle implementationer kan udf\u00f8re kopiering og copy-on-write p\u00e5 diskunderlaget.<\/p>\n

NS<\/b>: Her skal alle engine (Amazon, Google\u2026) ogs\u00e5 n\u00e5 at begynde at underst\u00f8tte denne version - det tager ogs\u00e5 lidt tid.<\/i><\/p>\n

DS<\/b>: Indtil videre bruger vi dem ikke. Vi bruger vores eget.<\/p>\n

Lokal udvikling under Kubernetes<\/h2>\n

\nNS<\/b>: Har du nogensinde st\u00f8dt p\u00e5 et s\u00e5dant \u00f8nske, n\u00e5r du skal k\u00f8re alle pods p\u00e5 \u00e9n maskine og lave s\u00e5dan en lille test? For hurtigt at f\u00e5 proof of concept, se om applikationen fungerer i Kubernetes uden at allokere en masse maskiner. Finnes der ikke Minikube?<\/i><\/p>\n

DS<\/b>: Jeg synes, denne sag \u2013 at deployere p\u00e5 \u00e9n node \u2013 handler udelukkende om lokal udvikling. Eller nogle manifestationer af s\u00e5dan et m\u00f8nster. Der er Minikube<\/a><\/noindex>, der er k3s<\/a><\/noindex>, KIND<\/a><\/noindex>. Vi er p\u00e5 vej mod at bruge Kubernetes IN Docker. Vi er netop begyndt at arbejde med det til tests.<\/p>\n

NS<\/b>: Jeg troede tidligere, at det var et fors\u00f8g p\u00e5 at pakke alle pods ind i et enkelt Docker-billede. Men det viste sig at v\u00e6re noget helt andet. Der er stadig separate containere, separate pods \u2014 bare i Docker.<\/i><\/p>\n

DS<\/b>: Ja. Der er lavet en ret sjov simulering, men meningen er s\u00e5dan... Vi har et v\u00e6rkt\u00f8j til deployment \u2013 werf<\/a><\/noindex>. Vi vil gerne lave en tilstand \u2013 s\u00e5 at sige werf up<\/code>: \u00abStart mig en lokal Kubernetes\u00bb. Og derefter k\u00f8re en hypotetisk werf follow<\/code>. S\u00e5 vil udvikleren kunne redigere i IDE'en, mens der k\u00f8rer en proces i systemet, der ser \u00e6ndringerne og bygger billederne om og redeployerer dem til den lokale K8s. S\u00e5dan vil vi fors\u00f8ge at l\u00f8se problemet med lokal udvikling.<\/p>\n

Snapshots og kloning af databaser i K8s-reality<\/h2>\n

\nNS<\/b>: Hvis vi g\u00e5r tilbage til copy-on-write. Jeg har bem\u00e6rket, at cloud-l\u00f8sninger ogs\u00e5 har snapshots. De fungerer forskelligt. For eksempel i GCP: du har en multiterabyte-instans p\u00e5 \u00f8stkysten af USA. Du tager periodiske snapshots. Du l\u00f8fter en kopi af disken fra snapshotet p\u00e5 vestkysten \u2014 efter et par minutter er alt klar, det fungerer meget hurtigt, det kr\u00e6ver bare, at cachen skal fyldes i hukommelsen. Men disse kloner (snapshots) er til at 'provision' et nyt volum. Det er sej, n\u00e5r der skal oprettes mange instanser.<\/i><\/p>\n

Men til test, synes jeg, at de snapshots, du taler om i Docker, eller som jeg taler om i ZFS, btrfs og endda LVM... de g\u00f8r det muligt at undg\u00e5 at skabe nye data p\u00e5 \u00e9n maskine. I clouden skal du ogs\u00e5 betale for dem hver gang og vente ikke sekunder, men minutter (og i tilf\u00e6lde af lazy load<\/a><\/noindex>, muligvis timer).<\/i><\/p>\n

I stedet kan du p\u00e5 f\u00e5 sekunder f\u00e5 disse data, k\u00f8re testen og smide dem v\u00e6k. Disse snapshots l\u00f8ser forskellige opgaver. I det f\u00f8rste tilf\u00e6lde \u2013 til at skalere og f\u00e5 nye replikaer, og i det andet \u2013 til tests.<\/i><\/p>\n

DS<\/b>: Jeg er uenig. At klone volumener korrekt er en opgave for skyen. Jeg har ikke set deres implementering, men jeg kender m\u00e5den, vi g\u00f8r det p\u00e5 hardware. Vi har Ceph, der kan klone et hvilket som helst fysisk volumen (RBD<\/a><\/noindex>) ved at sige clone<\/i> og f\u00e5 et andet volumen med de samme egenskaber p\u00e5 f\u00e6rre millisekunder, IOPS<\/a><\/noindex>og lignende. Man skal forst\u00e5, at der indeni er en smart copy-on-write. Hvorfor skulle clouden ikke g\u00f8re det samme? Jeg er sikker p\u00e5, de fors\u00f8ger at g\u00f8re det p\u00e5 en eller anden m\u00e5de.<\/p>\n

NS<\/b>: Men de vil stadig bruge sekunder, titusinder af sekunder, p\u00e5 at starte en instans, installere Docker osv.<\/i><\/p>\n

DS<\/b>: Hvorfor skal man n\u00f8dvendigvis starte en hel instans? Vi har en instans med 32 kerner, 16\u2026 og der kan v\u00e6re et vist antal inde \u2014 for eksempel fire. N\u00e5r vi bestiller den femte, vil der allerede oprettes en instans, som derefter vil blive slettet.<\/p>\n

NS<\/b>: Ja, det er interessant, i Kubernetes er det en anden historie. Vi har ikke databaser i K8s og \u00e9n instans. Men p\u00e5 kloning af en multiterabyte database tager det ikke mere end to sekunder.<\/i><\/p>\n

DS<\/b>: Det er fantastisk. Men mit oprindelige budskab er, at dette ikke er en generisk l\u00f8sning. Ja, det er fantastisk, men det passer kun til Postgres og kun p\u00e5 \u00e9n node.<\/p>\n

NS<\/b>: Det passer ikke kun til Postgres: de planer, jeg har beskrevet, vil kun fungere p\u00e5 den. Men hvis man ikke bekymrer sig om planerne, og vi bare har brug for alle data til funktionel test, s\u00e5 er det passende til enhver DBMS.<\/i><\/p>\n

DS<\/b>: For mange \u00e5r siden lavede vi noget lignende med LVM-snapshots. Det er klassisk. Denne tilgang blev meget aktivt brugt. Stateful-noder er bare besv\u00e6rligt. Fordi de ikke m\u00e5 falde ned, man skal altid huske dem\u2026<\/p>\n

NS<\/b>: Ser du ikke her en mulighed for en hybrid? Antag, at stateful er en pod, der fungerer for flere personer (mange testere). Vi har \u00e9t volumen, men takket v\u00e6re filsystemet er klonerne lokale. Hvis pod'en falder, forbliver disken \u2014 pod'en vil stige op, beregne informationen om alle kloner, starte det hele op igen og sige: 'Her er dine kloner p\u00e5 disse porte, arbejd videre med dem'.<\/i><\/p>\n

DS<\/b>: Teknisk set betyder det, at inden for Kubernetes er det \u00e9n pod, hvor vi k\u00f8rer mange Postgres.<\/p>\n

NS<\/b>: Ja. Den har en gr\u00e6nse: lad os sige, at ikke mere end 10 personer arbejder med den samtidig. Hvis der er brug for 20 \u2014 s\u00e5 starter vi en anden s\u00e5dan pod. Det er helt muligt at klone den, s\u00e5 vi f\u00e5r et andet komplet volumen, som vil have de samme 10 'tynde' kloner. Ser du ikke s\u00e5dan en mulighed?<\/i><\/p>\n

DS<\/b>: Her skal tilf\u00f8jes sikkerhedssp\u00f8rgsm\u00e5l. Denne organisatoriske model indeb\u00e6rer, at denne pod har h\u00f8je privilegier (capabilities), da den kan udf\u00f8re us\u00e6dvanlige operationer p\u00e5 filsystemet\u2026 Men jeg gentager: jeg mener, at Kubernetes p\u00e5 l\u00e6ngere sigt vil l\u00f8se storage-problemet, og at skyerne vil f\u00e5 orden p\u00e5 hele historien med volumener - alt vil \u00abbare fungere\u00bb. Der vil v\u00e6re resize, kloning\u2026 Der er et volumen - vi siger: \u00abOpret en ny baseret p\u00e5 den\u00bb, - og efter halvandet sekund f\u00e5r vi det, vi har brug for.<\/p>\n

NS<\/b>: Jeg tror ikke p\u00e5 halvandet sekund for mange terabyte. P\u00e5 Ceph g\u00f8r du det selv, men du taler om skyen. G\u00e5 til skyen, lav en klon af EBS-volumen p\u00e5 EC2, mange terabyte, og se hvilken ydeevne du f\u00e5r. Det vil ikke tage et par sekunder. Jeg er meget interesseret i, hvorn\u00e5r de n\u00e5r til s\u00e5dan et niveau. Jeg forst\u00e5r, hvad du taler om, men jeg tillader mig at v\u00e6re uenig.<\/i><\/p>\n

DS<\/b>: Okay, men jeg sagde, at det var p\u00e5 mellemlang sigt, ikke kortsigtet. I l\u00f8bet af de n\u00e6ste par \u00e5r.<\/p>\n

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

\nI midten af dette m\u00f8de tilsluttede Alexey Klyukin, tidligere udvikler fra Zalando, sig ogs\u00e5, og han fortalte om historien bag PostgreSQL-operatoren:<\/p>\n

Det er fantastisk, at dette emne overhovedet er blevet ber\u00f8rt: b\u00e5de Postgres og Kubernetes. Da vi begyndte at arbejde med dette i Zalando i 2017, var det et emne, som alle ville besk\u00e6ftige sig med, men ingen gjorde. Alle havde allerede begyndt at bruge Kubernetes, men n\u00e5r man spurgte, hvordan man skulle forholde sig til databaser, s\u00e5 sagde selv s\u00e5danne personer som Kelsey Hightower<\/a><\/noindex>, som pr\u00e6dikede K8s, omtrent f\u00f8lgende:<\/p>\n

\u00abG\u00e5 til managed-services og brug dem, ikke k\u00f8r databaser i Kubernetes. Ellers vil din K8s beslutte sig for at opgradere, slukke for alle noder, og s\u00e5 vil dine data forsvinde langt v\u00e6k.\u00bb<\/i><\/p>\n

Vi besluttede at lave en operator, der p\u00e5 trods af dette r\u00e5d ville k\u00f8re Postgres-databaser i Kubernetes. Og vi havde et godt grundlag \u2014 Patroni<\/a><\/noindex>. Dette er automatisk failover for PostgreSQL, lavet korrekt, dvs. ved at bruge etcd, consul eller ZooKeeper som lager for information om klyngen. Et s\u00e5dant lager, som vil give alle, der sp\u00f8rger, f.eks. hvilken leder vi har nu, den samme information - p\u00e5 trods af at alt er distribueret - for at undg\u00e5 split brain. Derudover havde vi Docker-billede<\/a><\/noindex> til det.<\/p>\n

Generelt opstod behovet for auto failover i virksomheden efter migrationen fra et internt hardwarudatacenter til skyen. Skyen var baseret p\u00e5 en egen PaaS-l\u00f8sning (Platform-as-a-Service). Den var open source, men for at kunne ops\u00e6tte den, skulle der g\u00f8res et stort arbejde. Den blev kaldt STUPS<\/a><\/noindex>.<\/p>\n

Der var oprindeligt ikke noget Kubernetes. Mere pr\u00e6cist, da den egen l\u00f8sning blev implementeret, var K8s allerede til stede, men var s\u00e5 uj\u00e6vn, at den ikke var egnet til produktion. Det var, mener jeg, i 2015 eller 2016. I 2017 var Kubernetes blevet mere eller mindre modent - der var behov for migration dertil.<\/p>\n

Og vi havde allerede en Docker-container. Der var PaaS, der brugte Docker. Hvorfor ikke pr\u00f8ve K8s? Hvorfor ikke skrive vores egen operator? Murat Kabilov, som kom til os fra Avito, startede dette som et initiativ \u2014 'for sjov' \u2014 og projektet fik succes.<\/p>\n

Men jeg ville egentlig fort\u00e6lle om AWS. Hvorfor der historisk set var kode relateret til AWS...<\/p>\n

N\u00e5r du lancerer noget i Kubernetes, er det vigtigt at forst\u00e5, at K8s er et work in progress. Det udvikler sig konstant, forbedres og kan periodevis endda bryde sammen. Det er n\u00f8dvendigt at holde n\u00f8je \u00f8je med alle \u00e6ndringer i Kubernetes, og man skal v\u00e6re klar til i tilf\u00e6lde af problemer at dykke ned i det og forst\u00e5, hvordan det fungerer i detaljer \u2014 muligvis mere end man \u00f8nsker. Det g\u00e6lder generelt for enhver platform, hvor du k\u00f8rer dine databaser...<\/p>\n

S\u00e5 da vi lavede operatoren, havde vi Postgres, der arbejdede med en ekstern volume (i dette tilf\u00e6lde EBS, da vi arbejdede p\u00e5 AWS). Databasen voksede, og p\u00e5 et tidspunkt blev det n\u00f8dvendigt at lave en resize: for eksempel, den oprindelige st\u00f8rrelse af EBS var 100 TB, databasen voksede til den st\u00f8rrelse, nu ville vi lave EBS til 200 TB. Hvordan? Man kan lave dump\/restore p\u00e5 en ny instans, men det er langsomt og indeb\u00e6rer nedetid.<\/p>\n

Derfor \u00f8nskede vi en resize, der ville \u00f8ge EBS-partitionen og derefter fort\u00e6lle filsystemet at bruge det nye rum. Og det gjorde vi, men p\u00e5 det tidspunkt havde Kubernetes ikke nogen API til resize-operationer. Da vi arbejdede p\u00e5 AWS, skrev vi kode til dens API.<\/p>\n

Ingen forhindrer dig i at g\u00f8re det samme for andre platforme. I operatoren er der ingen binding, som siger, at den kun kan k\u00f8re p\u00e5 AWS, og at den ikke vil fungere andre steder. Det er i det hele taget et Open Source-projekt: hvis nogen \u00f8nsker at fremskynde brugen af det nye API \u2014 er I alle sammen velkomne. GitHub<\/a><\/noindex>, pull-foresp\u00f8rgsler \u2013 Zalando-teamet fors\u00f8ger at reagere p\u00e5 dem ret hurtigt og fremme operat\u00f8ren. Hvad jeg ved, involverede projektet deltog<\/a><\/noindex> i Google Summer of Code og nogle andre lignende initiativer. Zalando arbejder meget aktivt p\u00e5 det.\n<\/p><\/blockquote>\n

<\/p>\n

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

\nHvis du er interesseret i emnet PostgreSQL og Kubernetes, vil vi ogs\u00e5 gerne p\u00e5pege, at der i sidste uge fandt sted f\u00f8lgende Postgres-tirsdag, hvor Nikolaj talte med Alexander Kukushkin fra Zalando<\/b>. Videoen er tilg\u00e6ngelig her<\/a><\/noindex>.<\/p>\n

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

\nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n