I allt högre grad tas sådana förfrågningar emot från kunder: "Vi vill ha det som Amazon RDS, men billigare"; "Vi vill ha det som RDS, men överallt, i vilken infrastruktur som helst." För att implementera en sådan hanterad lösning på Kubernetes tittade vi på det aktuella läget för de mest populära operatörerna för PostgreSQL (Solon, operatörer från Crunchy Data och Zalando) och gjorde vårt val.
Den här artikeln är vår erfarenhet både ur en teoretisk synvinkel (en genomgång av lösningar) och ur en praktisk synvinkel (vad som valdes och vad som kom av det). Men först, låt oss definiera vad som är de allmänna kraven för en potentiell ersättning för RDS ...
Vad är RDS
När folk pratar om RDS menar vi enligt vår erfarenhet en hanterad DBMS-tjänst som:
- lätt att installera;
- har förmågan att arbeta med ögonblicksbilder och återhämta sig från dem (helst med stöd för );
- låter dig skapa master-slav topologier;
- har en rik lista över tillägg;
- tillhandahåller revision och användar-/åtkomsthantering.
Generellt sett kan tillvägagångssätten för genomförandet av uppgiften vara väldigt olika, men vägen med den villkorade Ansible är inte nära oss. (Kollegor från 2GIS kom till en liknande slutsats som ett resultat av skapa ett "Postgres-baserat Failover Cluster Rapid Deployment Tool".)
Det är operatörerna som är den allmänt accepterade metoden för att lösa sådana problem i Kubernetes ekosystem. Mer detaljerat om dem i relation till databaser som körs inuti Kubernetes, har Flants tekniska chef redan berättat, I .
NB: För att snabbt skapa enkla operatörer rekommenderar vi att du uppmärksammar vårt verktyg med öppen källkod . Med hjälp av det kan du göra detta utan kunskap om Go, men på mer bekanta sätt för systemadministratörer: i Bash, Python, etc.
Det finns flera populära K8s-operatörer för PostgreSQL:
- Stolon;
- Crunchy Data PostgreSQL-operatör;
- Zalando Postgres Operatör.
Låt oss titta närmare på dem.
Val av operatör
Utöver de viktiga funktioner som redan nämnts ovan, förväntade vi oss - som infrastrukturingenjörer i Kubernetes - också följande från operatörer:
- distribuera från Git och med ;
- pod anti-affinitetsstöd;
- installera nodaffinitet eller nodväljare;
- inställningstoleranser;
- tillgänglighet av inställningsalternativ;
- förståeliga tekniker och till och med kommandon.
Utan att gå in på detaljer om var och en av punkterna (fråga i kommentarerna om du fortfarande har frågor om dem efter att ha läst hela artikeln), kommer jag att notera generellt att dessa parametrar behövs för en mer subtil beskrivning av specialiseringen av klusternoder i för att beställa dem för specifika tillämpningar. På så sätt kan vi uppnå den optimala balansen mellan prestanda och kostnad.
Nu - till PostgreSQL-operatörerna själva.
1. Stolon
från det italienska företaget Sorint.lab i betraktades som en sorts standard bland operatörerna för DBMS. Det här är ett ganska gammalt projekt: dess första offentliga release ägde rum i november 2015 (!), och GitHub-förvaret har nästan 3000 stjärnor och 40+ bidragsgivare.
Stolon är faktiskt ett bra exempel på tankeväckande arkitektur:
Enheten för denna operatör kan hittas i detalj i rapporten eller . I allmänhet räcker det med att säga att den kan göra allt som beskrivs: failover, proxy för transparent klientåtkomst, säkerhetskopior ... Dessutom ger proxyar åtkomst via en slutpunktstjänst - till skillnad från de två andra lösningarna som diskuteras nedan (de har två tjänster för åtkomst bas).
Men Stolon , vilket är anledningen till att det inte kan distribueras på ett sådant sätt att det är enkelt och snabbt - "som smör" - att skapa DBMS-instanser i Kubernetes. Förvaltningen sker genom verktyget stolonctl, distribution - genom Helm-diagrammet och anpassade definieras i ConfigMap.
Å ena sidan visar det sig att operatören egentligen inte är en operatör (eftersom den inte använder CRD). Men å andra sidan är det ett flexibelt system som låter dig konfigurera resurser i K8s som du vill.
Sammanfattningsvis, för oss personligen verkade det inte vara det bästa sättet att starta ett separat diagram för varje databas. Så vi började leta efter alternativ.
2. Crunchy Data PostgreSQL-operatör
, en ung amerikansk startup, såg ut som ett logiskt alternativ. Dess offentliga historia börjar med den första releasen i mars 2017, sedan dess har GitHub-förvaret fått knappt 1300 stjärnor och 50+ bidragsgivare. Den senaste versionen från september testades för att fungera med Kubernetes 1.15-1.18, OpenShift 3.11+ och 4.4+, GKE och VMware Enterprise PKS 1.3+.
Crunchy Data PostgreSQL Operator-arkitekturen uppfyller också de angivna kraven:
Förvaltning sker genom verktyget pgo, men det genererar i sin tur anpassade resurser för Kubernetes. Därför gladde operatören oss som potentiella användare:
- det finns kontroll genom CRD;
- bekväm användarhantering (även via CRD);
- integration med andra komponenter - en specialiserad samling av containerbilder för PostgreSQL och verktyg för att arbeta med den (inklusive pgBackRest, pgAudit, tillägg från contrib, etc.).
Men försök att börja använda operatören från Crunchy Data avslöjade flera problem:
- Det fanns ingen möjlighet till toleranser - endast nodeSelector tillhandahålls.
- De skapade poddarna var en del av distributionen, trots att vi distribuerade en tillståndsfull applikation. Till skillnad från StatefulSets kan Deployments inte skapa diskar.
Det sista felet leder till roliga ögonblick: i testmiljön lyckades vi köra 3 repliker med en disk lokal lagring, som ett resultat av vilket operatören rapporterade att 3 repliker fungerade (även om så inte var fallet).
En annan egenskap hos denna operatör är dess färdiga integration med olika hjälpsystem. Det är till exempel enkelt att installera pgAdmin och pgBounce och in förkonfigurerade Grafana och Prometheus beaktas. I en nyligen noterade separat förbättrad integration med projektet , tack vare vilket operatören erbjuder en visuell visualisering av PgSQL-mått direkt.
Det udda valet av Kubernetes-genererade resurser ledde dock till att vi hittade en annan lösning.
3. Zalando Postgres Operatör
Zalandos produkter har varit kända för oss under lång tid: vi har erfarenhet av att använda Zalenium och, naturligtvis, har vi provat är deras populära HA-lösning för PostgreSQL. Om företagets sätt att skapa berättade för en av dess författare - Alexei Klyukin - i etern och vi gillade det.
Detta är den yngsta lösningen som diskuteras i artikeln: den första releasen ägde rum i augusti 2018. Men trots det lilla antalet formella utgåvor har projektet kommit långt och redan överträffat populariteten för lösningen från Crunchy Data med 1300+ stjärnor på GitHub och det maximala antalet bidragsgivare (70+).
"Under huven" på denna operatör används beprövade lösningar:
- Patroni och För att köra,
- - för säkerhetskopiering,
- - som anslutningspool.
Så här presenteras operatörsarkitekturen från Zalando:
Operatören är helt hanterad genom Custom Resources, skapar automatiskt ett StatefulSet från containrar, som sedan kan anpassas genom att lägga till olika sidvagnar till podden. Allt detta är ett betydande plus i jämförelse med operatören från Crunchy Data.
Eftersom vi valde lösningen från Zalando bland de tre övervägda alternativen kommer en ytterligare beskrivning av dess möjligheter att presenteras nedan, omedelbart tillsammans med tillämpningen.
Träna med Postgres Operator av Zalando
Operatörsdistribution är mycket enkel: ladda bara ner den senaste versionen från GitHub och använd YAML-filer från katalogen . Alternativt kan du också använda .
Efter installationen bör du ta hand om inställningarna . Det görs via ConfigMap postgres-operator i namnområdet där du ställer in operatorn. Med arkiven konfigurerade kan du distribuera ditt första PostgreSQL-kluster.
Till exempel ser vår standardinstallation ut så här:
apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
name: staging-db
spec:
numberOfInstances: 3
patroni:
synchronous_mode: true
postgresql:
version: "12"
resources:
limits:
cpu: 100m
memory: 1Gi
requests:
cpu: 100m
memory: 1Gi
sidecars:
- env:
- name: DATA_SOURCE_URI
value: 127.0.0.1:5432
- name: DATA_SOURCE_PASS
valueFrom:
secretKeyRef:
key: password
name: postgres.staging-db.credentials
- name: DATA_SOURCE_USER
value: postgres
image: wrouesnel/postgres_exporter
name: prometheus-exporter
resources:
limits:
cpu: 500m
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
teamId: staging
volume:
size: 2Gi
Detta manifest distribuerar ett kluster av 3 instanser med en sidovagn av formuläret , från vilken vi samlar in applikationsstatistik. Som du kan se är allt väldigt enkelt, och om du vill kan du skapa ett bokstavligen obegränsat antal kluster.
Det är värt att uppmärksamma webbpanel för administration - . Den följer med operatören och låter dig skapa och ta bort kluster, samt arbeta med säkerhetskopior som operatören gör.
Lista över PostgreSQL-kluster
Backuphantering
En annan intressant funktion är stödet . Denna mekanism skapar automatiskt roller i PostgreSQL, baserat på den resulterande listan med användarnamn. Efter det låter API:et dig returnera en lista över användare för vilka roller skapas automatiskt.
Problem och lösningar
Användningen av operatören visade dock snart flera betydande nackdelar:
- brist på nodeSelector-stöd;
- oförmåga att inaktivera säkerhetskopior;
- när du använder funktionen skapa baser visas inte standardprivilegier;
- periodvis finns det inte tillräckligt med dokumentation eller så är den inaktuell.
Lyckligtvis går många av dem att lösa. Låt oss börja från slutet - problem med dokumentation.
Troligtvis kommer du att stöta på det faktum att det inte alltid är klart hur man registrerar en backup och hur man ansluter en backup-bucket till operatörsgränssnittet. Detta nämns i dokumentationen i förbigående, men den verkliga beskrivningen är inne :
- du måste göra en hemlighet;
- skicka den till operatören som en parameter
pod_environment_secret_namei CRD med operatörsinställningar eller i ConfigMap (beroende på hur du väljer att installera operatören).
Men som det visade sig är detta för närvarande inte möjligt. Det är därför vi har samlat med några ytterligare utvecklingar från tredje part. Mer om det - se nedan.
Om du skickar parametrar till operatören för säkerhetskopiering, nämligen - wal_s3_bucket och åtkomstnycklar i AWS S3, sedan det kommer att säkerhetskopiera allt: inte bara baser i produktionen, utan även iscensättning. Det passade inte oss.
I beskrivningen av parametrarna till Spilo, som är den grundläggande Docker wrapper för PgSQL när man använder operatören, visade det sig att man kan skicka en parameter WAL_S3_BUCKET tom, vilket inaktiverar säkerhetskopiering. Dessutom fann jag till stor glädje , som vi genast accepterade i vår gaffel. Nu är det enkelt att lägga till enableWALArchiving: false till en PostgreSQL-klusterresurs.
Ja, det var möjligt att göra det annorlunda genom att köra två operatörer: en för iscensättning (utan säkerhetskopior) och den andra för produktion. Men vi klarade oss med en.
Ok, vi har lärt oss hur man överför åtkomst för S3 till databaserna och säkerhetskopior började komma in i lagringen. Hur får man säkerhetskopior att fungera i operatörsgränssnittet?
I operatörsgränssnittet måste du lägga till tre variabler:
-
SPILO_S3_BACKUP_BUCKET -
AWS_ACCESS_KEY_ID -
AWS_SECRET_ACCESS_KEY
Därefter kommer säkerhetskopieringshantering att bli tillgänglig, vilket i vårt fall kommer att förenkla arbetet med iscensättning, vilket gör att du kan leverera skivor från produktionen dit utan ytterligare skript.
Som ytterligare ett plus kallades arbete med Teams API och breda möjligheter att skapa databaser och roller med hjälp av operatörens verktyg. Dock framväxande roller hade inte behörigheter som standard. Följaktligen kunde en användare med läsrättigheter inte läsa nya tabeller.
Varför är det så? Även om i koden nödvändig GRANTde tillämpas inte alltid. Det finns 2 metoder: syncPreparedDatabases и syncDatabases. I syncPreparedDatabases – trots att i avsnittet preparedDatabases det finns ett villkor defaultRoles и defaultUsers för att skapa roller tillämpas inte standardrättigheter. Vi håller på att förbereda en patch så att dessa rättigheter automatiskt tillämpas.
Och sista ögonblicket i de förbättringar som är relevanta för oss - A som lägger till en nodaffinitet till den genererade StatefulSet. Våra kunder föredrar ofta att sänka kostnaderna genom att använda spot-instanser, som helt klart inte är värda att vara värd för databastjänster. Det här problemet skulle kunna lösas genom toleranser, men närvaron av Node Affinity ger mer självförtroende.
Vad hände?
Som ett resultat av att lösa ovanstående problem klaffade vi in Postgres-operatören från Zalando vart det är på väg med så användbara patchar. Och för större bekvämlighet samlade vi också in .
Lista över PR som accepteras i gaffeln:
- ;
- ;
- ;
- .
Det kommer att vara bra om samhället stöder dessa PR så att de kommer uppströms med nästa version av operatören (1.6).
Bonus! Framgångssaga för produktionsmigrering
Om du använder Patroni kan liveproduktion migreras till operatören med minimal stilleståndstid.
Spilo låter dig skapa standby-kluster genom S3-lagring med när den binära PgSQL-loggen först lagras i S3 och sedan pumpas ut av repliken. Men tänk om du har ingen används av Wal-E i gammal infrastruktur? Lösningen på detta problem finns redan på navet.
PostgreSQL logisk replikering kommer till undsättning. Vi kommer dock inte att gå in på detaljer om hur man skapar publikationer och prenumerationer, eftersom ... vår plan misslyckades.
Faktum är att databasen hade flera laddade tabeller med miljontals rader, som dessutom ständigt fylldes på och raderades. с copy_data, när den nya repliken kopierar allt innehåll från mastern, kunde den helt enkelt inte hålla jämna steg med mastern. Innehållskopiering fungerade i en vecka, men kom aldrig ikapp mästaren. Till slut hjälpte det till att lösa problemet kollegor från Avito: du kan överföra data med hjälp av pg_dump. Jag kommer att beskriva vår (något modifierade) version av denna algoritm.
Tanken är att du kan göra en inaktiverad prenumeration kopplad till en specifik replikeringsplats och sedan fixa transaktionsnumret. Det fanns repliker för produktionsarbete. Detta är viktigt eftersom repliken hjälper till att skapa en konsekvent dump och fortsätter att ta emot ändringar från mastern.
Efterföljande kommandon som beskriver migreringsprocessen kommer att använda följande notation för värdar:
- Master — källserver;
- replika1 - strömmande kopia av den gamla produktionen;
- replika2 - en ny logisk kopia.
Migrationsplan
1. Skapa en prenumeration på alla tabeller i schemat i guiden public bas dbname:
psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"
2. Skapa en replikeringsplats på mastern:
psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"
3. Stoppa replikering på den gamla repliken:
psql -h replica1 -c "select pg_wal_replay_pause();"
4. Få transaktionsnumret från mastern:
psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"
5. Dumpa från den gamla repliken. Vi kommer att göra detta i flera trådar, vilket kommer att hjälpa till att påskynda processen:
pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname
6. Ladda upp dumpen till den nya servern:
pg_restore -h replica2 -F d -j 8 -d dbname dump/
7. När du har laddat ned dumpen kan du starta replikering på strömmande repliken:
psql -h replica1 -c "select pg_wal_replay_resume();"
7. Skapa en prenumeration på en ny logisk replik:
psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"
8. Få oid prenumerationer:
psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"
9. Låt oss säga att det togs emot oid=1000. Låt oss tillämpa transaktionsnumret på prenumerationen:
psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"
10. Låt oss börja replikera:
psql -h replica2 -d dbname -c "alter subscription oldprod enable;"
11. Kontrollera prenumerationsstatus, replikering bör fungera:
psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"
12. När replikeringen har startat och databaserna är synkroniserade kan du byta.
13. När du har inaktiverat replikering måste du fixa sekvenserna. Det är väl beskrivet .
Tack vare denna plan gick övergången igenom med minimala förseningar.
Slutsats
Kubernetes-operatörer låter dig förenkla olika åtgärder genom att reducera dem till att skapa K8s resurser. Men efter att ha uppnått anmärkningsvärd automatisering med deras hjälp, är det värt att komma ihåg att det också kan ge ett antal oväntade nyanser, så välj dina operatörer klokt.
Efter att ha granskat de tre mest populära Kubernetes-operatörerna för PostgreSQL valde vi projektet från Zalando. Och vi var tvungna att övervinna vissa svårigheter med det, men resultatet var verkligen tilltalande, så vi planerar att utöka den här upplevelsen till några andra installationer av PgSQL. Om du har erfarenhet av att använda liknande lösningar ser vi gärna detaljerna i kommentarerna!
PS
Läs även på vår blogg:
- «";
- «";
- «".
Källa: will.com