I økende grad mottar klienter følgende forespørsler: "Vi vil ha det som Amazon RDS, men billigere"; "Vi vil ha det som RDS, men overalt, i hvilken som helst infrastruktur." For å implementere en slik administrert løsning på Kubernetes, så vi på den nåværende tilstanden til de mest populære operatørene for PostgreSQL (Solon, operatører fra Crunchy Data og Zalando) og tok vårt valg.
Denne artikkelen er erfaringen vi har høstet både fra et teoretisk synspunkt (gjennomgang av løsninger) og fra en praktisk side (hva som ble valgt og hva som kom ut av det). Men først, la oss finne ut hva de generelle kravene er for en potensiell erstatning for RDS...
Hva er RDS
Når folk snakker om RDS, mener vi etter vår erfaring en administrert DBMS-tjeneste som:
- enkel å konfigurere;
- har muligheten til å jobbe med øyeblikksbilder og komme seg fra dem (helst med støtte );
- lar deg lage master-slave topologier;
- har en rik liste over utvidelser;
- gir revisjon og bruker/tilgangshåndtering.
Generelt sett kan tilnærminger til å implementere oppgaven være svært forskjellige, men veien med betinget Ansible er ikke i nærheten av oss. (Kolleger fra 2GIS kom til en lignende konklusjon som et resultat lage "et verktøy for raskt å distribuere en Postgres-basert failover-klynge.")
Operatører er en vanlig tilnærming for å løse lignende problemer i Kubernetes-økosystemet. Den tekniske direktøren for "Flanta" har allerede snakket mer detaljert om dem i forhold til databaser lansert inne i Kubernetes. I .
NB: For raskt å lage enkle operatører, anbefaler vi å ta hensyn til vårt åpen kildekode-verktøy . Ved å bruke det kan du gjøre dette uten kunnskap om Go, men på måter som er mer kjent for systemadministratorer: i Bash, Python, etc.
Det er flere populære K8s-operatører for PostgreSQL:
- Stolon;
- Crunchy Data PostgreSQL-operatør;
- Zalando Postgres-operatør.
La oss se nærmere på dem.
Operatørvalg
I tillegg til de viktige funksjonene som allerede er nevnt ovenfor, forventet vi - som Kubernetes infrastrukturdriftsingeniører - også følgende fra operatører:
- distribusjon fra Git og med ;
- pod anti-affinitet støtte;
- installasjon av nodeaffinitet eller nodevelger;
- installasjon av toleranser;
- tilgjengelighet av tuning evner;
- forståelige teknologier og til og med kommandoer.
Uten å gå inn på detaljer om hvert av punktene (spør i kommentarene hvis du fortsatt har spørsmål om dem etter å ha lest hele artikkelen), vil jeg bemerke generelt at disse parameterne er nødvendige for å mer nøyaktig beskrive spesialiseringen av klyngenoder for å kunne bestille dem for spesifikke bruksområder. På denne måten kan vi oppnå den optimale balansen når det gjelder ytelse og kostnad.
La oss nå gå videre til PostgreSQL-operatørene selv.
1. Stolon
fra det italienske selskapet Sorint.lab i ble ansett som en slags standard blant operatører for DBMS. Dette er et ganske gammelt prosjekt: dets første offentlige utgivelse fant sted i november 2015 (!), og GitHub-depotet har nesten 3000 stjerner og 40+ bidragsytere.
Stolon er faktisk et utmerket eksempel på gjennomtenkt arkitektur:
Enheten til denne operatøren kan bli funnet i detalj i rapporten eller . Generelt er det nok å si at den kan gjøre alt som er beskrevet: failover, proxyer for transparent klienttilgang, sikkerhetskopier... Dessuten gir proxyer tilgang gjennom én endepunkttjeneste - i motsetning til de to andre løsningene som er omtalt nedenfor (de har hver to tjenester for tilgang til base).
Imidlertid Stolon , og det er grunnen til at det ikke kan distribueres på en slik måte at det er enkelt og raskt – «som varmt hvetebrød» – å lage DBMS-forekomster i Kubernetes. Forvaltningen utføres gjennom verktøyet stolonctl, distribusjon gjøres gjennom Helm-diagrammet, og tilpassede er definert og spesifisert i ConfigMap.
På den ene siden viser det seg at operatøren egentlig ikke er en operatør (den bruker tross alt ikke CRD). Men på den annen side er det et fleksibelt system som lar deg konfigurere ressurser i K8s etter eget ønske.
For å oppsummere, for oss personlig virket det ikke optimalt å lage et eget diagram for hver database. Derfor begynte vi å se etter alternativer.
2. Crunchy Data PostgreSQL-operatør
, en ung amerikansk oppstart, virket som et logisk alternativ. Dens offentlige historie begynner med den første utgivelsen i mars 2017, siden den gang har GitHub-depotet mottatt i underkant av 1300 stjerner og 50+ bidragsytere. Den siste utgivelsen fra september ble testet for å fungere med Kubernetes 1.15-1.18, OpenShift 3.11+ og 4.4+, GKE og VMware Enterprise PKS 1.3+.
Arkitekturen til Crunchy Data PostgreSQL Operator oppfyller også de angitte kravene:
Styring skjer gjennom verktøyet pgo, men det genererer i sin tur egendefinerte ressurser for Kubernetes. Derfor gledet operatøren oss som potensielle brukere:
- det er kontroll via CRD;
- praktisk brukeradministrasjon (også via CRD);
- integrasjon med andre komponenter — en spesialisert samling av containerbilder for PostgreSQL og verktøy for å jobbe med det (inkludert pgBackRest, pgAudit, utvidelser fra contrib, etc.).
Forsøk på å begynne å bruke operatøren fra Crunchy Data avslørte imidlertid flere problemer:
- Det var ingen mulighet for toleranser - bare nodeSelector er gitt.
- De opprettede podene var en del av Deployment, til tross for at vi distribuerte en stateful applikasjon. I motsetning til StatefulSets, kan ikke Deployments opprette disker.
Den siste ulempen fører til morsomme øyeblikk: i testmiljøet klarte vi å kjøre 3 replikaer med en disk lokal lagring, noe som får operatøren til å rapportere at 3 replikaer fungerte (selv om de ikke var det).
En annen funksjon ved denne operatøren er dens ferdige integrering med forskjellige hjelpesystemer. For eksempel er det enkelt å installere pgAdmin og pgBounce, og i forhåndskonfigurerte Grafana og Prometheus vurderes. Nylig Forbedret integrasjon med prosjektet er særskilt notert , takket være hvilket operatøren tilbyr en klar visualisering av PgSQL-målinger rett ut av boksen.
Imidlertid førte det merkelige valget av Kubernetes-genererte ressurser oss til behovet for å finne en annen løsning.
3. Zalando Postgres Operatør
Vi har kjent Zalando-produkter i lang tid: vi har erfaring med å bruke Zalenium, og selvfølgelig prøvde vi er deres populære HA-løsning for PostgreSQL. Om selskapets tilnærming til å skape en av forfatterne, Alexey Klyukin, sa på lufta , og vi likte det.
Dette er den yngste løsningen som er diskutert i artikkelen: den første utgivelsen fant sted i august 2018. Men selv til tross for det lille antallet formelle utgivelser, har prosjektet kommet langt, og har allerede overgått i popularitet løsningen fra Crunchy Data med 1300+ stjerner på GitHub og maksimalt antall bidragsytere (70+).
"Under panseret" bruker denne operatøren tidstestede løsninger:
- Patroni og For kjøring,
- - for sikkerhetskopier,
- - som tilknytningsbasseng.
Slik presenteres operatørarkitekturen fra Zalando:
Operatøren er fullstendig administrert gjennom Custom Resources, oppretter automatisk et StatefulSet fra containere, som deretter kan tilpasses ved å legge til forskjellige sidevogner til poden. Alt dette er en betydelig fordel sammenlignet med operatøren fra Crunchy Data.
Siden vi valgte løsningen fra Zalando blant de 3 alternativene som vurderes, vil en ytterligere beskrivelse av dens muligheter bli presentert nedenfor, umiddelbart sammen med applikasjonspraksis.
Øv med Postgres Operator fra Zalando
Operatørdistribusjon er veldig enkel: bare last ned den gjeldende versjonen fra GitHub og bruk YAML-filene fra katalogen . Alternativt kan du også bruke .
Etter installasjonen bør du bekymre deg for å sette opp . Dette gjøres via ConfigMap postgres-operator i navneområdet der du installerte operatøren. Når depotene er konfigurert, kan du distribuere din første PostgreSQL-klynge.
Standardimplementeringen vår ser for eksempel slik ut:
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 manifestet distribuerer en klynge med 3 forekomster med en sidevogn i skjemaet , som vi henter applikasjonsberegninger fra. Som du kan se, er alt veldig enkelt, og hvis du ønsker det, kan du lage et bokstavelig talt ubegrenset antall klynger.
Det er verdt å ta hensyn til webadministrasjonspanel - . Den følger med operatøren og lar deg opprette og slette klynger, samt jobbe med sikkerhetskopier laget av operatøren.
Liste over PostgreSQL-klynger
Sikkerhetskopiering
En annen interessant funksjon er støtten . Denne mekanismen oppretter automatisk roller i PostgreSQL, basert på den resulterende listen over brukernavn. API-en lar deg deretter returnere en liste over brukere som roller opprettes automatisk for.
Problemer og løsninger
Imidlertid avslørte bruken av operatøren snart flere betydelige mangler:
- mangel på nodeSelector-støtte;
- manglende evne til å deaktivere sikkerhetskopier;
- når du bruker databaseopprettingsfunksjonen, vises ikke standardrettigheter;
- Noen ganger mangler dokumentasjon eller er utdatert.
Heldigvis kan mange av dem løses. La oss starte fra slutten - problemer med dokumentasjon.
Mest sannsynlig vil du støte på det faktum at det ikke alltid er klart hvordan du registrerer en sikkerhetskopi og hvordan du kobler sikkerhetskopibøtten til operatørgrensesnittet. Dokumentasjonen snakker om dette i forbifarten, men den virkelige beskrivelsen er inne :
- trenger å gjøre en hemmelighet;
- sende den til operatøren som en parameter
pod_environment_secret_namei CRD med operatørinnstillinger eller i ConfigMap (avhengig av hvordan du bestemmer deg for å installere operatøren).
Men, som det viser seg, er dette foreløpig umulig. Derfor samlet vi med noen ytterligere tredjepartsutviklinger. For mer informasjon om det, se nedenfor.
Hvis du sender parametrene for sikkerhetskopiering til operatøren, nemlig - wal_s3_bucket og tilgangsnøkler i AWS S3, så det vil sikkerhetskopiere alt: ikke bare baser i produksjon, men også iscenesettelse. Dette passet ikke oss.
I beskrivelsen av parameterne for Spilo, som er den grunnleggende Docker-innpakningen for PgSQL når du bruker operatøren, viste det seg: du kan sende en parameter WAL_S3_BUCKET tom, og dermed deaktiverer sikkerhetskopier. Dessuten fant jeg til stor glede , som vi umiddelbart aksepterte i vår gaffel. Nå trenger du bare å legge til enableWALArchiving: false til en PostgreSQL klyngressurs.
Ja, det var en mulighet til å gjøre det annerledes ved å kjøre 2 operatører: en for iscenesettelse (uten sikkerhetskopier), og den andre for produksjon. Men vi klarte å nøye oss med en.
Ok, vi lærte hvordan vi overfører tilgang til databasene for S3 og sikkerhetskopier begynte å bli lagret. Hvordan få backup-sider til å fungere i operatørgrensesnittet?
Du må legge til 3 variabler til operatørgrensesnittet:
-
SPILO_S3_BACKUP_BUCKET -
AWS_ACCESS_KEY_ID -
AWS_SECRET_ACCESS_KEY
Etter dette vil styring av backup bli tilgjengelig, noe som i vårt tilfelle vil forenkle arbeidet med iscenesettelse, slik at vi kan levere skiver fra produksjonen der uten ekstra skript.
En annen fordel var arbeidet med Teams API og store muligheter for å lage databaser og roller ved hjelp av operatørverktøy. Imidlertid opprettet roller hadde ingen rettigheter som standard. Følgelig kunne ikke en bruker med leserettigheter lese nye tabeller.
Hvorfor det? Til tross for at i koden nødvendig GRANT, de brukes ikke alltid. Det er 2 metoder: syncPreparedDatabases и syncDatabases. I syncPreparedDatabases - til tross for at i avsnittet preparedDatabases det er en betingelse defaultRoles и defaultUsers for å opprette roller brukes ikke standardrettigheter. Vi er i ferd med å utarbeide en oppdatering slik at disse rettighetene blir tatt i bruk automatisk.
Og det siste punktet i forbedringene som er relevante for oss - , som legger til Node Affinity til det opprettede StatefulSet. Kundene våre foretrekker ofte å redusere kostnadene ved å bruke spot-instanser, og de er tydeligvis ikke verdt å være vert for databasetjenester. Dette problemet kan løses gjennom toleranser, men tilstedeværelsen av Node Affinity gir større tillit.
Hva skjedde?
Basert på resultatene av å løse problemene ovenfor, ga vi Postgres Operator fra Zalando inn , hvor det er samlet med slike nyttige lapper. Og for større bekvemmelighet samlet vi også .
Liste over PR-er som er akseptert i gaffelen:
- ;
- ;
- ;
- .
Det vil være flott om fellesskapet støtter disse PR-ene slik at de kommer oppstrøms med neste versjon av operatøren (1.6).
Bonus! Suksesshistorie for produksjonsmigrering
Hvis du bruker Patroni, kan levende produksjon migreres til operatøren med minimal nedetid.
Spilo lar deg lage standby-klynger via S3-lagring med , når den binære PgSQL-loggen først lagres i S3 og deretter pumpes ut av replikaen. Men hva skal du gjøre hvis du har no brukt av Wal-E på gammel infrastruktur? Løsningen på dette problemet er allerede på navet.
PostgreSQL logisk replikering kommer til unnsetning. Vi vil imidlertid ikke gå i detalj om hvordan du oppretter publikasjoner og abonnementer, fordi ... planen vår var en fiasko.
Faktum er at databasen hadde flere lastede tabeller med millioner av rader, som dessuten stadig ble etterfylt og slettet. с copy_data, når den nye replikaen kopierer alt innholdet fra masteren, kan den rett og slett ikke holde tritt med masteren. Kopiering av innhold fungerte i en uke, men tok aldri opp masteren. Til slutt hjalp det meg med å løse problemet kolleger fra Avito: du kan overføre data ved hjelp av pg_dump. Jeg vil beskrive vår (litt modifiserte) versjon av denne algoritmen.
Tanken er at du kan lage et deaktivert abonnement knyttet til et spesifikt replikeringsspor, og deretter korrigere transaksjonsnummeret. Det var kopier tilgjengelig for produksjonsarbeid. Dette er viktig fordi replikaen vil bidra til å skape en konsistent dump og fortsette å motta endringer fra masteren.
Påfølgende kommandoer som beskriver migreringsprosessen vil bruke følgende vertsnotasjoner:
- Master — kildeserver;
- replika 1 — streaming replika på den gamle produksjonen;
- replika 2 - ny logisk kopi.
Migrasjonsplan
1. Opprett et abonnement på masteren for alle tabellene i skjemaet public utgangspunkt dbname:
psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"
2. Opprett et replikeringsspor på masteren:
psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"
3. Stopp replikering på den gamle replikaen:
psql -h replica1 -c "select pg_wal_replay_pause();"
4. Få transaksjonsnummeret fra masteren:
psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"
5. Fjern dumpen fra den gamle kopien. Vi vil gjøre dette i flere tråder, som vil bidra til å fremskynde prosessen:
pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname
6. Last opp dumpen til den nye serveren:
pg_restore -h replica2 -F d -j 8 -d dbname dump/
7. Etter å ha lastet ned dumpen, kan du starte replikering på streaming-replikaen:
psql -h replica1 -c "select pg_wal_replay_resume();"
7. La oss opprette 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. La oss få oid abonnementer:
psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"
9. La oss si at den ble mottatt oid=1000. La oss bruke transaksjonsnummeret på abonnementet:
psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"
10. La oss starte replikering:
psql -h replica2 -d dbname -c "alter subscription oldprod enable;"
11. Sjekk abonnementsstatusen, replikering skal fungere:
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. Etter at replikering er startet og databasene er synkronisert, kan du bytte over.
13. Etter å ha deaktivert replikering, må du korrigere sekvensene. Dette er godt beskrevet .
Takket være denne planen skjedde overgangen med minimale forsinkelser.
Konklusjon
Kubernetes-operatører lar deg forenkle ulike handlinger ved å redusere dem til å lage K8s ressurser. Men etter å ha oppnådd bemerkelsesverdig automatisering med deres hjelp, er det verdt å huske at det også kan gi en rekke uventede nyanser, så velg operatørene dine med omhu.
Etter å ha vurdert de tre mest populære Kubernetes-operatørene for PostgreSQL, valgte vi prosjektet fra Zalando. Og vi måtte overvinne visse vanskeligheter med det, men resultatet var virkelig gledelig, så vi planlegger å utvide denne opplevelsen til noen andre PgSQL-installasjoner. Hvis du har erfaring med å bruke lignende løsninger, vil vi gjerne se detaljene i kommentarene!
PS
Les også på bloggen vår:
- «";
- «";
- «'.
Kilde: www.habr.com