Trosolwg Byr o Ddatganiadau PostgreSQL ar gyfer Kubernetes, Ein Dewisiadau a'n Profiad

Yn gynyddol, mae cleientiaid yn derbyn y ceisiadau canlynol: “Rydym am ei gael fel Amazon RDS, ond yn rhatach”; “Rydyn ni ei eisiau fel RDS, ond ym mhobman, mewn unrhyw seilwaith.” Er mwyn gweithredu datrysiad wedi'i reoli o'r fath ar Kubernetes, gwnaethom edrych ar gyflwr presennol y gweithredwyr mwyaf poblogaidd ar gyfer PostgreSQL (Stolon, gweithredwyr o Crunchy Data a Zalando) a gwneud ein dewis.

Yr erthygl hon yw'r profiad a gawsom o safbwynt damcaniaethol (adolygiad o atebion) ac o ochr ymarferol (yr hyn a ddewiswyd a beth a ddaeth ohono). Ond yn gyntaf, gadewch i ni benderfynu beth yw'r gofynion cyffredinol ar gyfer amnewidiad posibl ar gyfer RDS...

Beth yw RDS

Pan fydd pobl yn siarad am RDS, yn ein profiad ni, maent yn golygu gwasanaeth DBMS a reolir sydd:

1. hawdd ei ffurfweddu;
2. â'r gallu i weithio gyda chipluniau a gwella ohonynt (gyda chymorth yn ddelfrydol PITR);
3. yn eich galluogi i greu topolegau meistr-gaethweision;
4. mae ganddo restr gyfoethog o estyniadau;
5. yn darparu archwilio a rheoli defnyddwyr/mynediad.

Yn gyffredinol, gall dulliau gweithredu'r dasg dan sylw fod yn wahanol iawn, ond nid yw'r llwybr ag Ansible amodol yn agos atom ni. (Daeth cydweithwyr o 2GIS i gasgliad tebyg o ganlyniad ei ymgais creu "offeryn ar gyfer defnyddio clwstwr methu yn seiliedig ar Postgres yn gyflym.")

Mae gweithredwyr yn ddull cyffredin o ddatrys problemau tebyg yn ecosystem Kubernetes. Mae cyfarwyddwr technegol “Flanta” eisoes wedi siarad yn fwy manwl amdanynt mewn perthynas â chronfeydd data a lansiwyd y tu mewn i Kubernetes. distolYn un o'i adroddiadau.

NB: Er mwyn creu gweithredwyr syml yn gyflym, rydym yn argymell rhoi sylw i'n cyfleustodau Ffynhonnell Agored cregyn-weithredwr. Gan ei ddefnyddio, gallwch wneud hyn heb wybodaeth am Go, ond mewn ffyrdd sy'n fwy cyfarwydd i weinyddwyr system: yn Bash, Python, ac ati.

Mae yna sawl gweithredwr K8s poblogaidd ar gyfer PostgreSQL:

• Stolon;
• Gweithredwr PostgreSQL Data Crunchy;
• Gweithredwr Zalando Postgres.

Gadewch i ni edrych arnynt yn agosach.

Dewis gweithredwr

Yn ogystal â'r nodweddion pwysig a grybwyllwyd eisoes uchod, roeddem ni - fel peirianwyr gweithrediadau seilwaith Kubernetes - hefyd yn disgwyl y canlynol gan weithredwyr:

• lleoli gan Git a gyda Adnoddau Custom;
• cefnogaeth gwrth-affinedd pod;
• gosod affinedd nod neu ddewiswr nodau;
• gosod goddefiannau;
• argaeledd galluoedd tiwnio;
• technolegau dealladwy a hyd yn oed gorchmynion.

Heb fynd i fanylion ar bob un o'r pwyntiau (gofynnwch yn y sylwadau a oes gennych gwestiynau amdanynt o hyd ar ôl darllen yr erthygl gyfan), nodaf yn gyffredinol bod angen y paramedrau hyn i ddisgrifio'n fwy cywir arbenigedd nodau clwstwr er mwyn eu harchebu ar gyfer ceisiadau penodol. Fel hyn gallwn gyflawni'r cydbwysedd gorau posibl o ran perfformiad a chost.

Nawr, gadewch i ni symud ymlaen at y gweithredwyr PostgreSQL eu hunain.

1. Stolon

Stolon gan y cwmni Eidalaidd Sorint.lab yn adroddiad a grybwyllwyd eisoes cael ei ystyried fel math o safon ymhlith gweithredwyr ar gyfer DBMS. Mae hwn yn brosiect eithaf hen: digwyddodd ei ryddhad cyhoeddus cyntaf yn ôl ym mis Tachwedd 2015 (!), ac mae gan ystorfa GitHub bron i 3000 o sêr a 40+ o gyfranwyr.

Yn wir, mae Stolon yn enghraifft wych o bensaernïaeth feddylgar:

Gellir dod o hyd i ddyfais y gweithredwr hwn yn fanwl yn yr adroddiad neu dogfennaeth prosiect. Yn gyffredinol, digon yw dweud y gall wneud popeth a ddisgrifir: methiant, dirprwyon ar gyfer mynediad tryloyw i gleientiaid, copïau wrth gefn... At hynny, mae dirprwyon yn darparu mynediad trwy un gwasanaeth pwynt terfyn - yn wahanol i'r ddau ateb arall a drafodir isod (mae gan bob un ohonynt ddau wasanaeth ar gyfer cyrchu sylfaen).

Fodd bynnag, Stolon dim Adnoddau Custom, a dyna pam na ellir ei ddefnyddio yn y fath fodd fel ei bod yn hawdd ac yn gyflym - “fel cacennau poeth” - i greu enghreifftiau DBMS yn Kubernetes. Cyflawnir rheolaeth trwy'r cyfleustodau stolonctl, gwneir defnydd trwy'r siart Helm, ac mae rhai arfer yn cael eu diffinio a'u nodi yn ConfigMap.

Ar y naill law, mae'n ymddangos nad yw'r gweithredwr yn weithredwr mewn gwirionedd (wedi'r cyfan, nid yw'n defnyddio CRD). Ond ar y llaw arall, mae'n system hyblyg sy'n eich galluogi i ffurfweddu adnoddau mewn K8s fel y gwelwch yn dda.

I grynhoi, i ni yn bersonol nid oedd yn ymddangos yn optimaidd creu siart ar wahân ar gyfer pob cronfa ddata. Felly, dechreuasom chwilio am ddewisiadau eraill.

2. Data Crunchy Gweithredwr PostgreSQL

Gweithredwr o Crunchy Data, busnes newydd Americanaidd ifanc, yn ymddangos fel dewis arall rhesymegol. Mae ei hanes cyhoeddus yn dechrau gyda'r datganiad cyntaf ym mis Mawrth 2017, ers hynny mae ystorfa GitHub wedi derbyn ychydig llai na 1300 o sêr a 50+ o gyfranwyr. Profwyd y datganiad diweddaraf o fis Medi i weithio gyda Kubernetes 1.15-1.18, OpenShift 3.11+ a 4.4+, GKE a VMware Enterprise PKS 1.3+.

Mae pensaernïaeth Gweithredwr PostgreSQL Data Crunchy hefyd yn bodloni'r gofynion a nodir:

Mae rheolaeth yn digwydd trwy'r cyfleustodau pgo, fodd bynnag, mae yn ei dro yn cynhyrchu Custom Resources ar gyfer Kubernetes. Felly, roedd y gweithredwr yn ein plesio ni fel darpar ddefnyddwyr:

• mae rheolaeth trwy CRD;
• rheoli defnyddwyr cyfleus (hefyd trwy CRD);
• integreiddio â chydrannau eraill Swît Cynhwysydd Data crensiog — casgliad arbenigol o ddelweddau cynhwysydd ar gyfer PostgreSQL a chyfleustodau ar gyfer gweithio gydag ef (gan gynnwys pgBackRest, pgAudit, estyniadau o gyfraniad, ac ati).

Fodd bynnag, datgelodd ymdrechion i ddechrau defnyddio'r gweithredwr o Crunchy Data sawl problem:

• Nid oedd unrhyw bosibilrwydd o oddefiadau - dim ond nodeSelector a ddarperir.
• Roedd y codennau a grëwyd yn rhan o Deployment, er gwaethaf y ffaith ein bod wedi defnyddio cais wladwriaethol. Yn wahanol i StatefulSets, ni all Deployments greu disgiau.

Mae'r anfantais olaf yn arwain at eiliadau doniol: ar yr amgylchedd prawf fe wnaethom lwyddo i redeg 3 replicas gydag un ddisg storfa leol, gan achosi i'r gweithredwr adrodd bod 3 atgynhyrchiad yn gweithio (er nad oeddent).

Nodwedd arall o'r gweithredwr hwn yw ei integreiddio parod â systemau ategol amrywiol. Er enghraifft, mae'n hawdd gosod pgAdmin a pgBounce, ac yn dogfennaeth ystyrir Grafana a Prometheus sydd wedi'u ffurfweddu ymlaen llaw. Yn ddiweddar rhyddhau 4.5.0-beta1 Mae gwell integreiddio gyda'r prosiect yn cael ei nodi ar wahân pgMonitor, diolch y mae'r gweithredwr yn cynnig delweddu clir o fetrigau PgSQL allan o'r bocs.

Fodd bynnag, arweiniodd y dewis rhyfedd o adnoddau a gynhyrchwyd gan Kubernetes ni at yr angen i ddod o hyd i ateb gwahanol.

3. Gweithredwr Zalando Postgres

Rydym wedi adnabod cynhyrchion Zalando ers amser maith: mae gennym brofiad o ddefnyddio Zalenium ac, wrth gwrs, fe wnaethom geisio Patroni yw eu datrysiad HA poblogaidd ar gyfer PostgreSQL. Ynglŷn ag ymagwedd y cwmni at greu Gweithredwr Postgres meddai un o'i hawduron, Alexey Klyukin, ar yr awyr Postgres-Dydd Mawrth #5, ac roeddem yn ei hoffi.

Dyma'r ateb ieuengaf a drafodir yn yr erthygl: cynhaliwyd y datganiad cyntaf ym mis Awst 2018. Fodd bynnag, hyd yn oed er gwaethaf y nifer fach o ddatganiadau ffurfiol, mae'r prosiect wedi dod yn bell, gan ragori eisoes mewn poblogrwydd yr ateb o Crunchy Data gyda 1300+ o sêr ar GitHub a'r nifer uchaf o gyfranwyr (70+).

“O dan y cwfl” mae'r gweithredwr hwn yn defnyddio datrysiadau â phrawf amser:

• Patroni a Spilo Ar gyfer gyrru,
• WAL-E - ar gyfer copïau wrth gefn,
• PgBouncer - fel pwll cysylltiad.

Dyma sut mae pensaernïaeth y gweithredwr o Zalando yn cael ei chyflwyno:

Mae'r gweithredwr yn cael ei reoli'n llawn trwy Custom Resources, yn awtomatig yn creu StatefulSet o gynwysyddion, y gellir wedyn ei addasu trwy ychwanegu ceir ochr amrywiol i'r pod. Mae hyn i gyd yn fantais sylweddol o'i gymharu â'r gweithredwr o Crunchy Data.

Gan i ni ddewis yr ateb gan Zalando ymhlith y 3 opsiwn sy'n cael eu hystyried, bydd disgrifiad pellach o'i alluoedd yn cael ei gyflwyno isod, yn syth ynghyd â'r arfer o gymhwyso.

Ymarferwch gyda Gweithredwr Postgres o Zalando

Mae defnyddio gweithredwr yn syml iawn: lawrlwythwch y datganiad cyfredol o GitHub a chymhwyso'r ffeiliau YAML o'r cyfeiriadur yn amlygu. Fel arall, gallwch hefyd ddefnyddio gweithredwrhub.

Ar ôl gosod, dylech boeni am sefydlu storfa ar gyfer boncyffion a chopïau wrth gefn. Gwneir hyn trwy ConfigMap postgres-operator yn y gofod enw lle gosodoch y gweithredwr. Unwaith y bydd yr ystorfeydd wedi'u ffurfweddu, gallwch chi ddefnyddio'ch clwstwr PostgreSQL cyntaf.

Er enghraifft, mae ein defnydd safonol yn edrych fel hyn:

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

Mae'r maniffest hwn yn defnyddio clwstwr o 3 achos gyda char ochr ar ei ffurf postgres_allforiwr, yr ydym yn cymryd metrigau cais ohonynt. Fel y gwelwch, mae popeth yn syml iawn, ac os dymunwch, gallwch greu nifer anghyfyngedig o glystyrau.

Mae'n werth talu sylw i panel gweinyddu gwe - postgres-weithredwr-ui. Mae'n dod gyda'r gweithredwr ac yn caniatáu ichi greu a dileu clystyrau, yn ogystal â gweithio gyda chopïau wrth gefn a wneir gan y gweithredwr.

Rhestr o glystyrau PostgreSQL

Rheoli copi wrth gefn

Nodwedd ddiddorol arall yw'r gefnogaeth Teams API. Mae'r mecanwaith hwn yn creu yn awtomatig rolau yn PostgreSQL, yn seiliedig ar y rhestr canlyniadol o enwau defnyddwyr. Yna mae'r API yn caniatáu ichi ddychwelyd rhestr o ddefnyddwyr y mae rolau'n cael eu creu ar eu cyfer yn awtomatig.

Problemau ac atebion

Fodd bynnag, yn fuan datgelodd defnydd y gweithredwr nifer o ddiffygion sylweddol:

1. diffyg cefnogaeth nodeSelector;
2. anallu i analluogi copïau wrth gefn;
3. wrth ddefnyddio'r swyddogaeth creu cronfa ddata, nid yw breintiau rhagosodedig yn ymddangos;
4. Weithiau mae dogfennaeth ar goll neu wedi dyddio.

Yn ffodus, gellir datrys llawer ohonynt. Gadewch i ni ddechrau o'r diwedd - problemau gyda dogfennaeth.

Yn fwyaf tebygol, byddwch yn dod ar draws y ffaith nad yw bob amser yn glir sut i gofrestru copi wrth gefn a sut i gysylltu'r bwced wrth gefn i'r UI Gweithredwr. Mae'r ddogfennaeth yn sôn am hyn wrth fynd heibio, ond mae'r disgrifiad go iawn i mewn PR:

1. angen gwneud cyfrinach;
2. ei drosglwyddo i'r gweithredwr fel paramedr pod_environment_secret_name yn y CRD gyda gosodiadau gweithredwr neu yn ConfigMap (yn dibynnu ar sut rydych chi'n penderfynu gosod y gweithredwr).

Fodd bynnag, fel y mae'n digwydd, mae hyn yn amhosibl ar hyn o bryd. Dyna pam y gwnaethom gasglu eich fersiwn chi o'r gweithredwr gyda rhai datblygiadau trydydd parti ychwanegol. Am ragor o wybodaeth amdano, gweler isod.

Os byddwch chi'n trosglwyddo'r paramedrau ar gyfer copi wrth gefn i'r gweithredwr, sef - wal_s3_bucket ac allweddi mynediad yn AWS S3, yna mae'n bydd copi wrth gefn o bopeth: nid yn unig seiliau mewn cynhyrchu, ond hefyd llwyfannu. Nid oedd hyn yn addas i ni.

Yn y disgrifiad o'r paramedrau ar gyfer Spilo, sef y peiriant lapio Docker sylfaenol ar gyfer PgSQL wrth ddefnyddio'r gweithredwr, fe ddaeth yn amlwg: gallwch chi basio paramedr WAL_S3_BUCKET wag, a thrwy hynny analluogi copïau wrth gefn. Ar ben hynny, i lawenydd mawr, canfyddais PR parod, a dderbyniasom ar unwaith i'n fforf. Nawr does ond angen i chi ychwanegu enableWALArchiving: false i adnodd clwstwr PostgreSQL.

Do, roedd cyfle i'w wneud yn wahanol trwy redeg 2 weithredwr: un ar gyfer llwyfannu (heb wrth gefn), a'r ail ar gyfer cynhyrchu. Ond roeddem yn gallu gwneud do ag un.

Iawn, dysgon ni sut i drosglwyddo mynediad i'r cronfeydd data ar gyfer S3 a dechreuwyd storio copïau wrth gefn. Sut i wneud i dudalennau wrth gefn weithio yn Operator UI?

Bydd angen i chi ychwanegu 3 newidyn i UI y Gweithredwr:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Ar ôl hyn, bydd rheolaeth wrth gefn ar gael, a fydd yn ein hachos ni yn symleiddio'r gwaith gyda llwyfannu, gan ganiatáu inni ddosbarthu tafelli o'r cynhyrchiad yno heb sgriptiau ychwanegol.

Mantais arall oedd y gwaith gyda’r Teams API a digon o gyfleoedd i greu cronfeydd data a rolau gan ddefnyddio offer gweithredwr. Fodd bynnag, mae'r creu nid oedd gan rolau unrhyw hawliau yn ddiofyn. Yn unol â hynny, ni allai defnyddiwr â hawliau darllen ddarllen tablau newydd.

Pam hynny? Er gwaethaf y ffaith bod yn y cod mae angenrheidiol GRANT, nid ydynt bob amser yn cael eu defnyddio. Mae 2 ddull: syncPreparedDatabases и syncDatabases. Yn syncPreparedDatabases - er gwaethaf y ffaith bod yn yr adran preparedDatabases mae mae cyflwr defaultRoles и defaultUsers i greu rolau, ni chaiff hawliau diofyn eu cymhwyso. Rydym yn y broses o baratoi darn fel bod yr hawliau hyn yn cael eu gweithredu'n awtomatig.

A'r pwynt olaf yn y gwelliannau sy'n berthnasol i ni - clwt, sy'n ychwanegu Node Affinity i'r StatefulSet a grëwyd. Yn aml mae'n well gan ein cleientiaid leihau costau trwy ddefnyddio achosion yn y fan a'r lle, ac mae'n amlwg nad ydynt yn werth cynnal gwasanaethau cronfa ddata. Gellid datrys y mater hwn trwy oddefiadau, ond mae presenoldeb Node Affinity yn rhoi mwy o hyder.

Beth ddigwyddodd?

Yn seiliedig ar ganlyniadau datrys y problemau uchod, fe wnaethom fforchio Gweithredwr Postgres o Zalando i mewn eich ystorfa, lle mae'n cael ei gasglu gyda chlytiau defnyddiol o'r fath. Ac er hwylustod mwy, rydym hefyd yn casglu Delwedd docwr.

Rhestr o gysylltiadau cyhoeddus a dderbyniwyd i'r fforc:

• adeiladu delwedd ysgafn ddiogel ar gyfer y gweithredwr yn Docker;
• analluogi copïau wrth gefn;
• diweddaru fersiynau adnoddau ar gyfer fersiynau cyfredol o k8s;
• gweithredu Node Affinity.

Bydd yn wych os yw'r gymuned yn cefnogi'r cysylltiadau cyhoeddus hyn fel eu bod yn dod i fyny'r afon gyda fersiwn nesaf y gweithredwr (1.6).

Bonws! Llwyddiant ymfudo cynhyrchu

Os ydych chi'n defnyddio Patroni, gellir mudo cynhyrchiad byw i'r gweithredwr heb fawr o amser segur.

Mae Spilo yn caniatáu ichi greu clystyrau wrth gefn trwy storfa S3 gyda Wal-E, pan fydd y log deuaidd PgSQL yn cael ei storio gyntaf yn S3 ac yna ei bwmpio allan gan y replica. Ond beth i'w wneud os oes gennych chi dim a ddefnyddir gan Wal-E ar hen seilwaith? Mae'r ateb i'r broblem hon eisoes awgrymwyd ar y canolbwynt.

Daw atgynhyrchu rhesymegol PostgreSQL i'r adwy. Fodd bynnag, ni fyddwn yn manylu ar sut i greu cyhoeddiadau a thanysgrifiadau, oherwydd... fiasco oedd ein cynllun.

Y ffaith yw bod gan y gronfa ddata nifer o dablau wedi'u llwytho gyda miliynau o resi, a oedd, ar ben hynny, yn cael eu hailgyflenwi a'u dileu yn gyson. Tanysgrifiad syml с copy_data, pan fydd y replica newydd yn copïo'r holl gynnwys gan y meistr, ni all gadw i fyny â'r meistr. Gweithiodd copïo cynnwys am wythnos, ond ni ddal i fyny gyda'r meistr. Yn y diwedd, fe helpodd fi i ddatrys y broblem erthygl cydweithwyr o Avito: gallwch drosglwyddo data gan ddefnyddio pg_dump. Byddaf yn disgrifio ein fersiwn (wedi'i haddasu ychydig) o'r algorithm hwn.

Y syniad yw y gallwch chi wneud tanysgrifiad anabl ynghlwm wrth slot atgynhyrchu penodol, ac yna cywiro rhif y trafodiad. Roedd copïau ar gael ar gyfer gwaith cynhyrchu. Mae hyn yn bwysig oherwydd bydd y replica yn helpu i greu dymp cyson a pharhau i dderbyn newidiadau gan y meistr.

Bydd gorchmynion dilynol sy'n disgrifio'r broses fudo yn defnyddio'r nodiannau gwesteiwr canlynol:

1. meistr - gweinydd ffynhonnell;
2. atgynhyrchiad 1 — replica ffrydio ar yr hen gynhyrchiad;
3. atgynhyrchiad 2 - atgynhyrchiad rhesymegol newydd.

Cynllun mudo

1. Creu tanysgrifiad ar y meistr ar gyfer yr holl dablau yn y sgema public sylfaen dbname:

psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"

2. Creu slot atgynhyrchu ar y meistr:

psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"

3. Stopiwch ddyblygu ar yr hen replica:

psql -h replica1 -c "select pg_wal_replay_pause();"

4. Cael y rhif trafodiad gan y meistr:

psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"

5. Tynnwch y dymp o'r hen replica. Byddwn yn gwneud hyn mewn sawl trywydd, a fydd yn helpu i gyflymu'r broses:

pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname

6. Llwythwch y dymp i'r gweinydd newydd:

pg_restore -h replica2 -F d -j 8 -d dbname dump/

7. Ar ôl llwytho i lawr y dymp, gallwch ddechrau dyblygu ar y replica ffrydio:

psql -h replica1 -c "select pg_wal_replay_resume();"

7. Gadewch i ni greu tanysgrifiad ar atgynhyrchiad rhesymegol newydd:

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. Gadewch i ni gael oid tanysgrifiadau:

psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"

9. Gadewch i ni ddweud iddo gael ei dderbyn oid=1000. Gadewch i ni gymhwyso rhif y trafodiad i'r tanysgrifiad:

psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"

10. Gadewch i ni ddechrau dyblygu:

psql -h replica2 -d dbname -c "alter subscription oldprod enable;"

11. Gwiriwch statws y tanysgrifiad, dylai atgynhyrchu weithio:

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. Ar ôl i'r atgynhyrchu ddechrau a'r cronfeydd data yn cael eu cysoni, gallwch newid drosodd.

13. Ar ôl analluogi dyblygu, mae angen i chi gywiro'r dilyniannau. Disgrifir hyn yn dda yn yr erthygl ar wiki.postgresql.org.

Diolch i'r cynllun hwn, bu'r newid i ddigidol heb fawr o oedi.

Casgliad

Mae gweithredwyr Kubernetes yn caniatáu ichi symleiddio gwahanol gamau gweithredu trwy eu lleihau i greu adnoddau K8s. Fodd bynnag, ar ôl cyflawni awtomeiddio rhyfeddol gyda'u cymorth, mae'n werth cofio y gall hefyd ddod â nifer o arlliwiau annisgwyl, felly dewiswch eich gweithredwyr yn ddoeth.

Ar ôl ystyried y tri gweithredwr Kubernetes mwyaf poblogaidd ar gyfer PostgreSQL, dewisom y prosiect gan Zalando. Ac roedd yn rhaid i ni oresgyn rhai anawsterau ag ef, ond roedd y canlyniad yn wirioneddol ddymunol, felly rydym yn bwriadu ehangu'r profiad hwn i rai gosodiadau PgSQL eraill. Os oes gennych brofiad o ddefnyddio atebion tebyg, byddwn yn falch o weld y manylion yn y sylwadau!

PS

Darllenwch hefyd ar ein blog:

• «Cronfeydd data a Kubernetes (adroddiad adolygu a fideo)";
• «Postgres Dydd Mawrth #5: PostgreSQL a Kubernetes. CI/CD. Profi awtomeiddio";
• «Un stori gyda gweithredwr Redis yn K8s ac adolygiad bach o gyfleustodau ar gyfer dadansoddi data o'r gronfa ddata hon'.

Ffynhonnell: hab.com