Kubernetes үшін PostgreSQL мәлімдемелеріне қысқаша шолу, біздің таңдауымыз және тәжірибеміз

Клиенттерге келесі сұраулар жиі түсуде: «Біз оны Amazon RDS сияқты қалаймыз, бірақ арзанырақ»; «Біз оны RDS сияқты қалаймыз, бірақ барлық жерде, кез келген инфрақұрылымда». Kubernetes-те осындай басқарылатын шешімді енгізу үшін біз PostgreSQL үшін ең танымал операторлардың (Stolon, Crunchy Data және Zalando операторлары) ағымдағы жағдайын қарап, өз таңдауымызды жасадық.

Бұл мақала теориялық тұрғыдан (шешімдерді шолу) және практикалық жағынан (не таңдалды және одан не пайда болды) алған тәжірибеміз. Бірақ алдымен RDS үшін ықтимал ауыстыруға қойылатын жалпы талаптар қандай екенін анықтайық...

RDS дегеніміз не

Адамдар RDS туралы айтқанда, біздің тәжірибемізде олар басқарылатын ДҚБЖ қызметін білдіреді, ол:

1. конфигурациялау оңай;
2. лездік суреттермен жұмыс істеу және олардан қалпына келтіру мүмкіндігі бар (қолдау арқылы жақсырақ PITR);
3. басты-бағдарлы топологияларды құруға мүмкіндік береді;
4. кеңейтімдердің бай тізімі бар;
5. аудитті және пайдаланушыны/қолжетімділікті басқаруды қамтамасыз етеді.

Жалпы айтқанда, тапсырманы жүзеге асыру тәсілдері өте әртүрлі болуы мүмкін, бірақ шартты Ansible жолы бізге жақын емес. (Нәтижесінде 2GIS әріптестері осындай қорытындыға келді оның әрекеті «Postgres негізіндегі ауыстырып қосу кластерін жылдам орналастыру құралын» жасаңыз.)

Операторлар - Kubernetes экожүйесіндегі ұқсас мәселелерді шешудің жалпы тәсілі. «Фланта» техникалық директоры олар туралы Kubernetes ішінде іске қосылған дерекқорларға қатысты толығырақ айтып берді. дистол, in оның есептерінің бірі.

NB: Қарапайым операторларды жылдам жасау үшін біз Open Source утилитасына назар аударуды ұсынамыз қабық операторы. Оны пайдалану арқылы сіз мұны Go қолданбасын білмей-ақ жасай аласыз, бірақ жүйелік әкімшілерге көбірек таныс әдістермен: Bash, Python және т.б.

PostgreSQL үшін бірнеше танымал K8s операторлары бар:

• Столон;
• Crunchy Data PostgreSQL операторы;
• Zalando Postgres операторы.

Оларды толығырақ қарастырайық.

Операторды таңдау

Жоғарыда айтылған маңызды мүмкіндіктерден басқа, біз - Kubernetes инфрақұрылымдық операциялар инженерлері ретінде - операторлардан келесілерді күттік:

• Git және көмегімен орналастыру Пайдаланушы ресурстары;
• подъезд антифинитті қолдау;
• түйіннің ұқсастығын немесе түйін селекторын орнату;
• төзімділіктерді орнату;
• баптау мүмкіндіктерінің болуы;
• түсінікті технологиялар және тіпті командалар.

Әрбір тармаққа егжей-тегжейлі тоқталмай-ақ (бүкіл мақаланы оқығаннан кейін олар туралы әлі де сұрақтарыңыз болса, түсініктемелерде сұраңыз), мен бұл параметрлер кластерлік түйіндердің мамандануын дәлірек сипаттау үшін қажет екенін атап өтемін. оларды арнайы қолданбалар үшін тапсырыс беріңіз. Осылайша біз өнімділік пен шығын тұрғысынан оңтайлы теңгерімге қол жеткізе аламыз.

Енді PostgreSQL операторларының өздеріне көшейік.

1. Столон

Столон итальяндық Sorint.lab компаниясынан бұрын айтылған есеп ДҚБЖ үшін операторлар арасында өзіндік стандарт ретінде қарастырылды. Бұл өте ескі жоба: оның бірінші жалпыға ортақ шығарылымы 2015 жылдың қарашасында болды(!) және GitHub репозиторийінде 3000 40-ға жуық жұлдыз және XNUMX-тан астам қатысушы бар.

Шынында да, Столон - ойластырылған архитектураның тамаша үлгісі:

Бұл оператордың құрылғысын есепте немесе егжей-тегжейлі табуға болады жобалық құжаттама. Тұтастай алғанда, оның сипатталғанның барлығын орындай алатынын айтсақ жеткілікті: ауыстырып қосу, клиентке мөлдір қол жеткізу үшін проксилер, сақтық көшірмелер... Сонымен қатар, проксилер бір соңғы нүкте қызметі арқылы қол жеткізуді қамтамасыз етеді - төменде талқыланған басқа екі шешімнен айырмашылығы (олардың әрқайсысында екі қызмет бар). базаға қол жеткізу).

Дегенмен, Столон пайдаланушы ресурстары жоқ, сондықтан оны Kubernetes жүйесінде ДҚБЖ даналарын жасау оңай және жылдам болатындай етіп орналастыру мүмкін емес – «ыстық пирожныйлар сияқты». Басқару утилита арқылы жүзеге асырылады stolonctl, орналастыру Helm диаграммасы арқылы орындалады және теңшелетіндер ConfigMap ішінде анықталады және орнатылады.

Бір жағынан, оператор шын мәнінде оператор емес екені белгілі болды (ақыр соңында ол CRD қолданбайды). Бірақ екінші жағынан, бұл K8-де ресурстарды өз қалауыңыз бойынша конфигурациялауға мүмкіндік беретін икемді жүйе.

Қорытындылай келе, жеке біз үшін әрбір дерекқор үшін жеке диаграмма құру оңтайлы болып көрінбеді. Сондықтан біз балама іздей бастадық.

2. Crunchy Data PostgreSQL операторы

Crunchy Data операторы, жас американдық стартап логикалық балама болып көрінді. Оның жалпыға ортақ тарихы 2017 жылдың наурызындағы бірінші шығарылымнан басталады, содан бері GitHub репозиторийі 1300-ден аз жұлдызды және 50+ салымшыны алды. Қыркүйек айындағы соңғы шығарылым Kubernetes 1.15-1.18, OpenShift 3.11+ және 4.4+, GKE және VMware Enterprise PKS 1.3+ нұсқаларымен жұмыс істеу үшін сыналған.

Crunchy Data PostgreSQL Операторының архитектурасы да көрсетілген талаптарға жауап береді:

Басқару утилита арқылы жүзеге асады pgoдегенмен, ол өз кезегінде Kubernetes үшін пайдаланушы ресурстарын жасайды. Сондықтан оператор бізді әлеуетті пайдаланушылар ретінде қуантты:

• CRD арқылы басқару бар;
• пайдаланушыны ыңғайлы басқару (CRD арқылы да);
• басқа компоненттермен интеграция Crunchy Data Container Suite — PostgreSQL үшін контейнерлік кескіндердің мамандандырылған жинағы және онымен жұмыс істеуге арналған утилиталар (соның ішінде pgBackRest, pgAudit, contrib кеңейтімдері және т.б.).

Дегенмен, Crunchy Data операторын пайдалануды бастау әрекеттері бірнеше мәселені анықтады:

• Төзімділік мүмкіндігі болмады - тек nodeSelector қамтамасыз етілген.
• Біз күйі бар қолданбаны орналастырғанымызға қарамастан, жасалған подкасттар Орналастыру бөлігі болды. StatefulSets-тен айырмашылығы, Deployments дискілерді жасай алмайды.

Соңғы кемшілік күлкілі сәттерге әкеледі: сынақ ортасында біз бір дискімен 3 репликаны іске қостық. жергілікті сақтау, оператордың 3 көшірменің жұмыс істеп тұрғаны туралы хабарлауына себепші болады (олар болмаса да).

Бұл оператордың тағы бір ерекшелігі - оның әртүрлі қосалқы жүйелермен дайын интеграциясы. Мысалы, pgAdmin және pgBounce орнату оңай құжаттама алдын ала конфигурацияланған Графана мен Прометей қарастырылады. Жақында 4.5.0-бета1 шығарылымы Жобамен интеграцияның жақсаруы бөлек атап өтілген pgMonitor, соның арқасында оператор қораптан тыс PgSQL метрикасының нақты визуализациясын ұсынады.

Дегенмен, Кубернетес жасаған ресурстардың таңқаларлық таңдауы бізді басқа шешім табу қажеттілігіне әкелді.

3. Zalando Postgres операторы

Біз Zalando өнімдерін бұрыннан білеміз: бізде Zalenium қолдану тәжірибеміз бар және, әрине, тырыстық Патрони олардың PostgreSQL үшін танымал HA шешімі болып табылады. Компанияның құру тәсілі туралы Postgres операторы Оның авторларының бірі Алексей Клюкин эфирде айтты Postgres-сейсенбі №5, және бізге ұнады.

Бұл мақалада талқыланған ең жас шешім: бірінші шығарылым 2018 жылдың тамызында болды. Дегенмен, ресми шығарылымдардың аздығына қарамастан, жоба танымалдығы бойынша GitHub-та 1300+ жұлдызы және салымшылардың ең көп саны (70+) бар Crunchy Data шешімінен асып түсіп, ұзақ жолдан өтті.

«Көрменің астында» бұл оператор уақытпен тексерілген шешімдерді пайдаланады:

• Патрони және Spilo Көлік жүргізу үшін,
• WAL-E - сақтық көшірмелер үшін,
• PgBouncer - қосылу пулы ретінде.

Zalando операторының архитектурасы осылай ұсынылған:

Оператор толығымен теңшелетін ресурстар арқылы басқарылады, контейнерлерден автоматты түрде StatefulSet жасайды, содан кейін оны подкастқа әртүрлі жанамаларды қосу арқылы теңшеуге болады. Мұның бәрі Crunchy Data операторымен салыстырғанда айтарлықтай артықшылық болып табылады.

Біз қарастырылып жатқан 3 нұсқаның ішінен Заландоның шешімін таңдағандықтан, оның мүмкіндіктерінің қосымша сипаттамасы төменде бірден қолдану тәжірибесімен бірге ұсынылатын болады.

Заландодан келген Postgres операторымен тәжірибе жасаңыз

Операторды орналастыру өте қарапайым: GitHub сайтынан ағымдағы шығарылымды жүктеп алыңыз және каталогтан YAML файлдарын қолданыңыз. көрінеді. Сонымен қатар, сіз де пайдалана аласыз operatorhub.

Орнатқаннан кейін орнату туралы алаңдау керек журналдар мен сақтық көшірмелерді сақтау. Бұл ConfigMap арқылы жасалады postgres-operator операторды орнатқан аттар кеңістігінде. Репозиторийлер конфигурацияланғаннан кейін сіз бірінші PostgreSQL кластерін қолдана аласыз.

Мысалы, біздің стандартты орналастыруымыз келесідей көрінеді:

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

Бұл манифест пішіндегі бүйірлік тақтасы бар 3 дана кластерін орналастырады postgres_exporter, одан біз қолданба көрсеткіштерін аламыз. Көріп отырғаныңыздай, бәрі өте қарапайым және қаласаңыз, сіз кластерлердің шексіз санын жасай аласыз.

Оған назар аударған жөн веб-басқару тақтасы - postgres-оператор-ui. Ол оператормен бірге келеді және кластерлерді жасауға және жоюға, сонымен қатар оператор жасаған сақтық көшірмелермен жұмыс істеуге мүмкіндік береді.

PostgreSQL кластерлерінің тізімі

Сақтық көшірмелерді басқару

Тағы бір қызықты мүмкіндік - бұл қолдау Teams API. Бұл механизм автоматты түрде жасалады PostgreSQL-дегі рөлдер, пайдаланушы аттарының нәтижесінде алынған тізімге негізделген. Содан кейін API рөлдері автоматты түрде жасалған пайдаланушылар тізімін қайтаруға мүмкіндік береді.

Мәселелер мен шешімдер

Алайда, операторды пайдалану көп ұзамай бірнеше маңызды кемшіліктерді анықтады:

1. nodeSelector қолдауының болмауы;
2. сақтық көшірмелерді өшіру мүмкін емес;
3. дерекқорды құру функциясын пайдаланған кезде әдепкі артықшылықтар пайда болмайды;
4. Кейде құжаттар жоқ немесе ескірген.

Бақытымызға орай, олардың көпшілігін шешуге болады. Соңынан бастайық - проблемалар құжаттама.

Сірә, сіз сақтық көшірмені қалай тіркеу және сақтық көшірме шелегін Оператор UI-ге қалай қосу керектігі әрқашан анық емес фактіге тап болуыңыз мүмкін. Құжаттамада бұл туралы қысқаша айтылады, бірақ нақты сипаттама бар PR:

1. құпияны ашу керек;
2. оны параметр ретінде операторға жіберіңіз pod_environment_secret_name оператор параметрлері бар CRD немесе ConfigMap (операторды орнату туралы шешіміңізге байланысты).

Алайда, белгілі болғандай, бұл қазіргі уақытта мүмкін емес. Сондықтан жинадық оператордың нұсқасы кейбір қосымша үшінші тарап әзірлемелерімен. Бұл туралы қосымша ақпаратты төменде қараңыз.

Сақтық көшірме үшін параметрлерді операторға жіберсеңіз, атап айтқанда - wal_s3_bucket және AWS S3 жүйесіндегі кіру кілттері, содан кейін ол барлығының сақтық көшірмесін жасайды: өндірістегі негіздер ғана емес, сонымен қатар сахналау. Бұл бізге сәйкес келмеді.

Операторды пайдалану кезінде PgSQL үшін негізгі Docker ораушысы болып табылатын Spilo параметрлерінің сипаттамасында келесідей болды: сіз параметрді жібере аласыз. WAL_S3_BUCKET бос, осылайша сақтық көшірмелерді өшіреді. Оның үстіне, мен үлкен қуаныш таптым дайын пиар, біз оны бірден шанышқыға қабылдадық. Енді сізге тек қосу керек enableWALArchiving: false PostgreSQL кластер ресурсына.

Иә, 2 операторды іске қосу арқылы мұны басқаша жасауға мүмкіндік болды: біреуі сахналау үшін (сақтық көшірмесіз), екіншісі өндіріс үшін. Бірақ біз біреуін жасай алдық.

Жарайды, біз S3 үшін дерекқорларға кіруді қалай беру керектігін білдік және сақтық көшірмелер жадқа түсе бастады. Сақтық көшірме беттерін Operator UI жүйесінде қалай жұмыс істеуге болады?

Оператор интерфейсіне 3 айнымалы қосу керек:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Осыдан кейін резервтік көшірмелерді басқару қол жетімді болады, бұл біздің жағдайда қойылыммен жұмысты жеңілдетеді, бұл бізге өндірістен үзінділерді қосымша сценарийлерсіз жеткізуге мүмкіндік береді.

Тағы бір артықшылығы - Teams API-мен жұмыс және оператор құралдары арқылы дерекқорлар мен рөлдерді құрудың кең мүмкіндіктері. Дегенмен, құрылған рөлдердің әдепкі бойынша құқықтары болмады. Сәйкесінше, оқу құқығы бар пайдаланушы жаңа кестелерді оқи алмады.

Неге бұлай? Кодексте болғанына қарамастан болып табылады қажет GRANT, олар әрқашан қолданыла бермейді. 2 әдіс бар: syncPreparedDatabases и syncDatabases. The syncPreparedDatabases - бөлімінде болғанына қарамастан preparedDatabases болып табылады шарты бар defaultRoles и defaultUsers рөлдерді жасау үшін әдепкі құқықтар қолданылмайды. Бұл құқықтар автоматты түрде қолданылатын етіп патч дайындау үстіндеміз.

Бізге қатысты жақсартулардың соңғы нүктесі - патч, ол жасалған StatefulSet жүйесіне Түйіннің жақындығын қосады. Біздің клиенттер көбінесе спот даналарын пайдалану арқылы шығындарды азайтуды қалайды және олар дерекқор қызметтерін орналастыруға тұрарлық емес. Бұл мәселені шыдамдылық арқылы шешуге болады, бірақ Түйіннің жақындығы болуы үлкен сенімділік береді.

Не болды?

Жоғарыда аталған мәселелерді шешу нәтижелеріне сүйене отырып, біз Postgres операторын Заландодан қостық сіздің репозиторий, ол осындай пайдалы патчтармен жиналған жерде. Көбірек ыңғайлы болу үшін біз де жинадық Докер кескіні.

Шанышқыға қабылданған PR тізімі:

• Docker-те оператор үшін қауіпсіз жеңіл кескінді құру;
• сақтық көшірмелерді өшіру;
• k8s ағымдағы нұсқалары үшін ресурс нұсқаларын жаңарту;
• Node Affinity іске асыру.

Егер қауымдастық оператордың келесі нұсқасымен (1.6) жоғары ағынды алу үшін осы PR-ға қолдау көрсетсе, тамаша болады.

Бонус! Өндірістік көші-қон табысының тарихы

Patroni пайдалансаңыз, тірі өнімді операторға ең аз тоқтау уақытымен көшіруге болады.

Spilo S3 жады арқылы күту кластерлерін жасауға мүмкіндік береді Уол-Е, PgSQL екілік журналы алдымен S3 ішінде сақталғанда, содан кейін реплика арқылы шығарылады. Бірақ бар болса не істеу керек емес Wal-E ескі инфрақұрылымда пайдаланады ма? Бұл мәселенің шешімі қазірдің өзінде ұсынылды хабта.

PostgreSQL логикалық репликациясы көмекке келеді. Дегенмен, біз басылымдар мен жазылымдарды қалай жасауға болатынын егжей-тегжейлі қарастырмаймыз, өйткені... біздің жоспарымыз сәтсіз болды.

Мәліметтер базасында миллиондаған жолдармен бірнеше жүктелген кестелер болды, сонымен қатар олар үнемі толықтырылып, жойылып отырды. Қарапайым жазылым с copy_data, жаңа көшірме негізгіден барлық мазмұнды көшіргенде, ол жай ғана шеберге ілесе алмайды. Мазмұнды көшіру бір апта бойы жұмыс істеді, бірақ ешқашан шеберді қуып жетпеді. Ақырында бұл мәселені шешуге көмектесті мақала Avito әріптестері: көмегімен деректерді тасымалдауға болады pg_dump. Мен бұл алгоритмнің біздің (аздап өзгертілген) нұсқасын сипаттаймын.

Идея мынада: сіз белгілі бір репликация ұяшығына байланысты өшірілген жазылымды жасай аласыз, содан кейін транзакция нөмірін түзете аласыз. Өндірістік жұмыс үшін қол жетімді көшірмелер болды. Бұл маңызды, себебі көшірме дәйекті дампты жасауға көмектеседі және шеберден өзгертулерді қабылдауды жалғастырады.

Тасымалдау процесін сипаттайтын келесі пәрмендер келесі хост белгілерін пайдаланады:

1. мастер — бастапқы сервер;
2. көшірме 1 — ескі өндірістегі ағынды көшірме;
3. көшірме 2 - жаңа логикалық көшірме.

Көші-қон жоспары

1. Схемадағы барлық кестелер үшін мастерде жазылым жасаңыз public негіз dbname:

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

2. Шеберде репликация ұясын жасаңыз:

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

3. Ескі репликада репликацияны тоқтату:

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

4. Шеберден транзакция нөмірін алыңыз:

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

5. Ескі көшірмеден дампты алып тастаңыз. Біз мұны бірнеше ағындарда жасаймыз, бұл процесті жылдамдатуға көмектеседі:

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

6. Дампты жаңа серверге жүктеп салыңыз:

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

7. Дампты жүктеп алғаннан кейін ағындық репликада репликацияны бастауға болады:

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

7. Жаңа логикалық репликада жазылым жасайық:

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. Алайық oid жазылымдар:

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

9. Алды делік oid=1000. Жазылымға транзакция нөмірін қолданайық:

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

10. Репликацияны бастайық:

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

11. Жазылым күйін тексеріңіз, репликация жұмыс істеуі керек:

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. Репликация іске қосылғаннан және дерекқорлар үндестірілгеннен кейін ауысуға болады.

13. Репликацияны өшіргеннен кейін реттіліктерді түзету керек. Бұл жақсы сипатталған wiki.postgresql.org сайтындағы мақалада.

Осы жоспардың арқасында ауысу аз кідіріспен өтті.

қорытынды

Kubernetes операторлары әртүрлі әрекеттерді K8s ресурстарын жасауға дейін азайту арқылы жеңілдетуге мүмкіндік береді. Дегенмен, олардың көмегімен керемет автоматтандыруға қол жеткізгеннен кейін, ол бірқатар күтпеген нюанстарды әкелуі мүмкін екенін есте ұстаған жөн, сондықтан операторларды ақылмен таңдаңыз.

PostgreSQL үшін ең танымал үш Kubernetes операторын қарастыра отырып, біз жобаны Zalando-дан таңдадық. Біз онымен белгілі бір қиындықтарды жеңуге тура келді, бірақ нәтиже шынымен қуантты, сондықтан біз бұл тәжірибені кейбір басқа PgSQL қондырғыларына кеңейтуді жоспарлап отырмыз. Егер сізде ұқсас шешімдерді пайдалану тәжірибеңіз болса, біз түсініктемелерде егжей-тегжейлерді көруге қуаныштымыз!

PS

Біздің блогта да оқыңыз:

• «Деректер базалары және Кубернеталар (шолу және бейне есеп)«;
• «Postgres сейсенбі №5: PostgreSQL және Kubernetes. CI/CD. Сынақтарды автоматтандыру«;
• «K8s ішіндегі Redis операторымен бір оқиға және осы дерекқордағы деректерді талдауға арналған утилиталарға шағын шолу«.

Ақпарат көзі: www.habr.com