I stigende grad modtager kunderne følgende anmodninger: "Vi vil have det som Amazon RDS, men billigere"; "Vi vil have det som RDS, men overalt, i enhver infrastruktur." For at implementere en sådan administreret løsning på Kubernetes kiggede vi på den aktuelle tilstand for de mest populære operatører til PostgreSQL (Solon, operatører fra Crunchy Data og Zalando) og traf vores valg.
Denne artikel er den erfaring, vi har gjort os både fra et teoretisk synspunkt (gennemgang af løsninger) og fra en praktisk side (hvad der blev valgt, og hvad der kom ud af det). Men lad os først bestemme, hvad de generelle krav er til en potentiel erstatning for RDS...
Hvad er RDS
Når folk taler om RDS, mener vi efter vores erfaring en administreret DBMS-tjeneste, der:
- let at konfigurere;
- har evnen til at arbejde med snapshots og komme sig fra dem (helst med support );
- giver dig mulighed for at skabe master-slave topologier;
- har en rig liste over udvidelser;
- leverer revision og bruger/adgangsstyring.
Generelt kan tilgange til implementering af opgaven være meget forskellige, men vejen med betinget Ansible er ikke tæt på os. (Kolleger fra 2GIS kom til en lignende konklusion som et resultat opret "et værktøj til hurtigt at implementere en Postgres-baseret failover-klynge."
Operatører er en fælles tilgang til at løse lignende problemer i Kubernetes-økosystemet. Den tekniske direktør for "Flanta" har allerede talt mere detaljeret om dem i forhold til databaser lanceret inde i Kubernetes. I .
NB: For hurtigt at oprette enkle operatører anbefaler vi, at du er opmærksom på vores Open Source-værktøj . Ved at bruge det kan du gøre dette uden kendskab til Go, men på måder, der er mere velkendte for systemadministratorer: i Bash, Python osv.
Der er flere populære K8s-operatører til PostgreSQL:
- Stolon;
- Crunchy Data PostgreSQL-operatør;
- Zalando Postgres operatør.
Lad os se nærmere på dem.
Valg af operatør
Ud over de vigtige funktioner, der allerede er nævnt ovenfor, forventede vi - som Kubernetes infrastrukturdriftsingeniører - også følgende fra operatørerne:
- udrulning fra Git og med ;
- pod anti-affinitet støtte;
- installation af nodeaffinitet eller nodevælger;
- installation af tolerancer;
- tilgængelighed af tuning kapaciteter;
- forståelige teknologier og endda kommandoer.
Uden at gå i detaljer om hvert af punkterne (spørg i kommentarerne, hvis du stadig har spørgsmål til dem efter at have læst hele artiklen), vil jeg generelt bemærke, at disse parametre er nødvendige for mere præcist at beskrive specialiseringen af klyngeknuder mhp. bestille dem til specifikke applikationer. På denne måde kan vi opnå den optimale balance i forhold til ydeevne og omkostninger.
Lad os nu gå videre til selve PostgreSQL-operatørerne.
1. Stolon
fra det italienske firma Sorint.lab i blev betragtet som en slags standard blandt operatører for DBMS. Dette er et ret gammelt projekt: Dets første offentlige udgivelse fandt sted tilbage i november 2015(!), og GitHub-lageret kan prale af næsten 3000 stjerner og 40+ bidragydere.
Faktisk er Stolon et glimrende eksempel på tankevækkende arkitektur:
Enheden af denne operatør kan findes i detaljer i rapporten eller . Generelt er det tilstrækkeligt at sige, at den kan gøre alt, hvad der er beskrevet: failover, proxyer til gennemsigtig klientadgang, sikkerhedskopier... Ydermere giver proxyer adgang gennem én slutpunktstjeneste - i modsætning til de to andre løsninger, der diskuteres nedenfor (de har hver to tjenester til adgang til base).
Dog Stolon , hvorfor det ikke kan implementeres på en sådan måde, at det er nemt og hurtigt – “som varmt brød” – at oprette DBMS-instanser i Kubernetes. Ledelsen udføres gennem forsyningen stolonctl, udrulningen udføres gennem Helm-diagrammet, og brugerdefinerede defineres og specificeres i ConfigMap.
På den ene side viser det sig, at operatøren ikke rigtig er en operatør (den bruger trods alt ikke CRD). Men på den anden side er det et fleksibelt system, der giver dig mulighed for at konfigurere ressourcer i K8s, som du finder passende.
For at opsummere, for os personligt virkede det ikke optimalt at lave et separat diagram for hver database. Derfor begyndte vi at lede efter alternativer.
2. Crunchy Data PostgreSQL-operatør
, en ung amerikansk startup, virkede som et logisk alternativ. Dens offentlige historie begynder med den første udgivelse i marts 2017, siden da har GitHub-lageret modtaget lige under 1300 stjerner og 50+ bidragydere. Den seneste udgivelse fra september blev testet til at fungere med Kubernetes 1.15-1.18, OpenShift 3.11+ og 4.4+, GKE og VMware Enterprise PKS 1.3+.
Arkitekturen af Crunchy Data PostgreSQL Operator opfylder også de angivne krav:
Styring sker gennem værktøjet pgo, men det genererer til gengæld brugerdefinerede ressourcer til Kubernetes. Derfor glædede operatøren os som potentielle brugere:
- der er kontrol via CRD;
- bekvem brugerstyring (også via CRD);
- integration med andre komponenter — en specialiseret samling af containerbilleder til PostgreSQL og værktøjer til at arbejde med det (inklusive pgBackRest, pgAudit, udvidelser fra contrib osv.).
Forsøg på at begynde at bruge operatøren fra Crunchy Data afslørede dog flere problemer:
- Der var ingen mulighed for tolerancer - kun nodeSelector leveres.
- De oprettede pods var en del af Deployment, på trods af at vi implementerede en stateful applikation. I modsætning til StatefulSets kan Deployments ikke oprette diske.
Den sidste ulempe fører til sjove øjeblikke: i testmiljøet lykkedes det at køre 3 replikaer med én disk lokal opbevaring, hvilket får operatøren til at rapportere, at 3 replikaer virkede (selvom de ikke var).
En anden egenskab ved denne operatør er dens færdige integration med forskellige hjælpesystemer. For eksempel er det nemt at installere pgAdmin og pgBounce, og i forudkonfigurerede Grafana og Prometheus overvejes. For nylig Forbedret integration med projektet er særskilt noteret , takket være hvilket operatøren tilbyder en klar visualisering af PgSQL-metrikker ud af boksen.
Men det mærkelige valg af Kubernetes-genererede ressourcer førte os til behovet for at finde en anden løsning.
3. Zalando Postgres Operatør
Vi har kendt Zalando-produkter i lang tid: Vi har erfaring med at bruge Zalenium, og selvfølgelig prøvede vi er deres populære HA-løsning til PostgreSQL. Om virksomhedens tilgang til at skabe en af dens forfattere, Alexey Klyukin, sagde i luften , og vi kunne lide det.
Dette er den yngste løsning, der diskuteres i artiklen: den første udgivelse fandt sted i august 2018. Men selv på trods af det lille antal formelle udgivelser, er projektet nået langt og har allerede overgået i popularitet løsningen fra Crunchy Data med 1300+ stjerner på GitHub og det maksimale antal bidragydere (70+).
"Under emhætten" bruger denne operatør gennemtestede løsninger:
- Patroni og Til kørsel,
- - til sikkerhedskopier,
- - som tilslutningspulje.
Sådan præsenteres operatørarkitekturen fra Zalando:
Operatøren styres fuldt ud gennem Custom Resources, opretter automatisk et StatefulSet fra containere, som derefter kan tilpasses ved at tilføje forskellige sidevogne til poden. Alt dette er en væsentlig fordel i forhold til operatøren fra Crunchy Data.
Da vi valgte løsningen fra Zalando blandt de 3 muligheder, der overvejes, vil en yderligere beskrivelse af dens muligheder blive præsenteret nedenfor, umiddelbart sammen med applikationspraksis.
Øv med Postgres Operator fra Zalando
Operatør-implementering er meget enkel: bare download den aktuelle udgivelse fra GitHub og anvend YAML-filerne fra mappen . Alternativt kan du også bruge .
Efter installationen bør du bekymre dig om opsætning . Dette gøres via ConfigMap postgres-operator i det navneområde, hvor du installerede operatøren. Når lagrene er konfigureret, kan du implementere din første PostgreSQL-klynge.
For eksempel ser vores standardimplementering sådan ud:
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
Dette manifest implementerer en klynge af 3 forekomster med en sidevogn i formen , hvorfra vi tager applikationsmetrics. Som du kan se, er alt meget enkelt, og hvis du ønsker det, kan du oprette et bogstaveligt talt ubegrænset antal klynger.
Det er værd at være opmærksom på webadministrationspanel — . Den følger med operatøren og giver dig mulighed for at oprette og slette klynger, samt arbejde med sikkerhedskopier lavet af operatøren.
Liste over PostgreSQL-klynger
Backup styring
En anden interessant funktion er supporten . Denne mekanisme opretter automatisk roller i PostgreSQL, baseret på den resulterende liste over brugernavne. API'en giver dig derefter mulighed for at returnere en liste over brugere, for hvem roller oprettes automatisk.
Problemer og deres løsninger
Brugen af operatøren afslørede dog snart flere væsentlige mangler:
- mangel på nodeSelector-understøttelse;
- manglende evne til at deaktivere sikkerhedskopier;
- når du bruger funktionen til oprettelse af database, vises standardrettigheder ikke;
- Nogle gange mangler dokumentation eller er forældet.
Heldigvis kan mange af dem løses. Lad os starte fra slutningen - problemer med dokumentation.
Mest sandsynligt vil du støde på det faktum, at det ikke altid er klart, hvordan man registrerer en sikkerhedskopi, og hvordan man forbinder backup-bøtten til operatørbrugergrænsefladen. Dokumentationen taler om dette i forbifarten, men den rigtige beskrivelse er inde :
- behov for at gøre en hemmelighed;
- videregive det til operatøren som en parameter
pod_environment_secret_namei CRD'en med operatørindstillinger eller i ConfigMap (afhængigt af hvordan du beslutter dig for at installere operatøren).
Men som det viser sig, er dette i øjeblikket umuligt. Derfor samlede vi ind med nogle yderligere tredjepartsudviklinger. For mere information om det, se nedenfor.
Hvis du videregiver parametrene for backup til operatøren, nemlig - wal_s3_bucket og adgangsnøgler i AWS S3, så det vil tage backup af alt: ikke kun baser i produktionen, men også iscenesættelse. Det her passede os ikke.
I beskrivelsen af parametrene for Spilo, som er den grundlæggende Docker-indpakning for PgSQL ved brug af operatøren, viste det sig: du kan videregive en parameter WAL_S3_BUCKET tom, hvorved sikkerhedskopiering deaktiveres. Desuden fandt jeg til stor glæde , som vi straks tog imod i vores gaffel. Nu skal du bare tilføje enableWALArchiving: false til en PostgreSQL-klyngressource.
Ja, der var mulighed for at gøre det anderledes ved at køre 2 operatører: en til iscenesættelse (uden backups), og den anden til produktion. Men på denne måde kunne vi nøjes med en.
Ok, vi lærte, hvordan man overfører adgang til databaserne for S3, og sikkerhedskopier begyndte at blive lagret. Hvordan får man backup-sider til at fungere i Operator UI?
Du skal tilføje 3 variabler til brugergrænsefladen:
-
SPILO_S3_BACKUP_BUCKET -
AWS_ACCESS_KEY_ID -
AWS_SECRET_ACCESS_KEY
Herefter vil styring af backups blive tilgængelig, hvilket i vores tilfælde vil forenkle arbejdet med iscenesættelse, så vi kan levere skiver fra produktionen der uden yderligere scripts.
En anden fordel var arbejdet med Teams API og rige muligheder for at skabe databaser og roller ved hjælp af operatørværktøjer. Det skabte dog roller havde som standard ingen rettigheder. Derfor kunne en bruger med læserettigheder ikke læse nye tabeller.
Hvorfor det? På trods af at i koden nødvendig GRANT, bliver de ikke altid brugt. Der er 2 metoder: syncPreparedDatabases и syncDatabases. I syncPreparedDatabases - på trods af, at der i pkt preparedDatabases der er en betingelse defaultRoles и defaultUsers for at oprette roller anvendes standardrettigheder ikke. Vi er i gang med at udarbejde en patch, så disse rettigheder automatisk anvendes.
Og det sidste punkt i de forbedringer, der er relevante for os - , som tilføjer Node Affinity til det oprettede StatefulSet. Vores kunder foretrækker ofte at reducere omkostningerne ved at bruge spot-instanser, og de er tydeligvis ikke værd at hoste databasetjenester. Dette problem kunne løses gennem tolerancer, men tilstedeværelsen af Node Affinity giver større tillid.
Hvad er der sket?
Baseret på resultaterne af løsningen af ovenstående problemer fordelte vi Postgres Operator fra Zalando , hvor det er samlet med sådanne nyttige plastre. Og for større bekvemmelighed samlede vi også .
Liste over PR'er accepteret i gaflen:
- ;
- ;
- ;
- .
Det vil være fantastisk, hvis samfundet støtter disse PR'er, så de kommer opstrøms med den næste version af operatøren (1.6).
Bonus! Succeshistorie om produktionsmigrering
Hvis du bruger Patroni, kan liveproduktion migreres til operatøren med minimal nedetid.
Spilo giver dig mulighed for at oprette standby-klynger via S3-lager med , når den binære PgSQL-log først gemmes i S3 og derefter pumpes ud af replikaen. Men hvad skal du gøre, hvis du har nej brugt af Wal-E på gammel infrastruktur? Løsningen på dette problem er allerede på navet.
PostgreSQL logisk replikering kommer til undsætning. Vi vil dog ikke gå i detaljer om, hvordan man opretter publikationer og abonnementer, fordi ... vores plan var en fiasko.
Faktum er, at databasen havde flere indlæste tabeller med millioner af rækker, som desuden konstant blev genopfyldt og slettet. с copy_data, når den nye replika kopierer alt indholdet fra masteren, kan den simpelthen ikke følge med masteren. Kopiering af indhold virkede i en uge, men indhentede aldrig mesteren. I sidste ende hjalp det mig med at løse problemet kolleger fra Avito: du kan overføre data vha pg_dump. Jeg vil beskrive vores (let modificerede) version af denne algoritme.
Ideen er, at du kan lave et deaktiveret abonnement knyttet til en specifik replikeringsplads og derefter rette transaktionsnummeret. Der var kopier til rådighed til produktionsarbejde. Dette er vigtigt, fordi replikaen vil hjælpe med at skabe en ensartet dump og fortsætte med at modtage ændringer fra masteren.
Efterfølgende kommandoer, der beskriver migreringsprocessen, vil bruge følgende værtsnotationer:
- Master — kildeserver;
- replika 1 — streaming replika af den gamle produktion;
- replika 2 - ny logisk kopi.
Migrationsplan
1. Opret et abonnement på masteren for alle tabeller i skemaet public basen dbname:
psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"
2. Opret en replikeringsplads på masteren:
psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"
3. Stop replikering på den gamle replika:
psql -h replica1 -c "select pg_wal_replay_pause();"
4. Få transaktionsnummeret fra masteren:
psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"
5. Fjern lossepladsen fra den gamle replika. Vi vil gøre dette i flere tråde, som vil hjælpe med at fremskynde processen:
pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname
6. Upload dumpet til den nye server:
pg_restore -h replica2 -F d -j 8 -d dbname dump/
7. Når du har downloadet dumpet, kan du starte replikering på streaming-replikaen:
psql -h replica1 -c "select pg_wal_replay_resume();"
7. Lad os oprette et abonnement på en ny logisk replika:
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. Lad os få oid abonnementer:
psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"
9. Lad os sige, at den blev modtaget oid=1000. Lad os anvende transaktionsnummeret på abonnementet:
psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"
10. Lad os starte replikering:
psql -h replica2 -d dbname -c "alter subscription oldprod enable;"
11. Tjek abonnementsstatus, replikering burde virke:
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. Efter replikering er startet, og databaserne er synkroniseret, kan du skifte over.
13. Når du har deaktiveret replikering, skal du rette sekvenserne. Dette er godt beskrevet .
Takket være denne plan skete overgangen med minimale forsinkelser.
Konklusion
Kubernetes-operatører giver dig mulighed for at forenkle forskellige handlinger ved at reducere dem til oprettelsen af K8s ressourcer. Men efter at have opnået bemærkelsesværdig automatisering med deres hjælp, er det værd at huske, at det også kan bringe en række uventede nuancer, så vælg dine operatører med omtanke.
Efter at have overvejet de tre mest populære Kubernetes-operatører til PostgreSQL, valgte vi projektet fra Zalando. Og vi var nødt til at overvinde visse vanskeligheder med det, men resultatet var virkelig glædeligt, så vi planlægger at udvide denne oplevelse til nogle andre PgSQL-installationer. Hvis du har erfaring med at bruge lignende løsninger, vil vi være glade for at se detaljerne i kommentarerne!
PS
Læs også på vores blog:
- «";
- «";
- «'.
Kilde: www.habr.com