Postgres вторник № 5: „PostgreSQL и Kubernetes. CI/CD. Автоматизация на тестовете"

В края на миналата година се проведе друго предаване на живо на руската PostgreSQL общност #RuPostgres, по време на който неговият съосновател Николай Самохвалов разговаря с техническия директор на Flant Дмитрий Столяров за тази СУБД в контекста на Kubernetes.

Публикуваме стенограма от основната част от тази дискусия, а на YouTube канал на общността Публикуван е пълен видеоклип:

Бази данни и Kubernetes

NS: Днес няма да говорим за ВАКУУМ и КОНТРОЛНИ ТОЧКИ. Искаме да говорим за Kubernetes. Знам, че имате дългогодишен опит. Гледах вашите видеоклипове и дори прегледах някои от тях... Нека да преминем направо към въпроса: защо изобщо Postgres или MySQL в K8s?

DS: На този въпрос няма и не може да има еднозначен отговор. Но като цяло това е простота и удобство... потенциал. Всеки иска управлявани услуги.

NS: Как RDS, само вкъщи?

DS: Да: като RDS, просто навсякъде.

NS: „Навсякъде“ е добра точка. В големите компании всичко е разположено на различни места. Защо тогава, ако е голяма фирма, да не вземем готово решение? Например Nutanix има свои собствени разработки, други компании (VMware...) имат същото „RDS, само у дома“.

DS: Но ние говорим за отделна реализация, която ще работи само при определени условия. И ако говорим за Kubernetes, тогава има огромно разнообразие от инфраструктура (което може да бъде в K8s). По същество това е стандарт за API към облака...

NS: Освен това е безплатно!

DS: Това не е толкова важно. Безплатността е важна за не много голям сегмент от пазара. Друго е важно... Сигурно си спомняте доклада”Бази данни и Kubernetes»

NS: Да.

DS: Разбрах, че е прието много двусмислено. Някои хора си помислиха, че казвам: „Момчета, нека вкараме всички бази данни в Kubernetes!“, докато други решиха, че всичко това са ужасни велосипеди. Но аз исках да кажа нещо съвсем друго: „Вижте какво става, какви проблеми има и как могат да бъдат решени. Трябва ли да използваме базите данни на Kubernetes сега? производство? Е, само ако обичате...да правите определени неща. Но за разработчик мога да кажа, че го препоръчвам. За разработчика динамиката на създаване/изтриване на среди е много важна.“

NS: Под dev, имате предвид всички среди, които не са прод? Постановка, QA…

DS: Ако говорим за перф стендове, вероятно не, защото там изискванията са специфични. Ако говорим за специални случаи, при които е необходима много голяма база данни за етап, тогава вероятно не... Ако това е статична, дълготрайна среда, тогава каква е ползата базата данни да се намира в K8s?

NS: Нито един. Но къде виждаме статични среди? Статичната среда ще стане остаряла утре.

DS: Постановката може да бъде статична. Имаме клиенти...

NS: Да, и аз имам такъв. Това е голям проблем, ако имате 10 TB база данни и 200 GB етап...

DS: Имам много готин калъф! При подготовката има продуктова база данни, в която се правят промени. И има бутон: „прехвърляне към производство“. Тези промени - делта - се добавят (изглежда, че просто се синхронизират чрез API) в производството. Това е много екзотичен вариант.

NS: Виждал съм стартиращи компании в Долината, които седят в RDS или дори в Heroku - това са истории от преди 2-3 години - и те изтеглят дъмпа на лаптопа си. Тъй като базата данни все още е само 80 GB, а на лаптопа има място. След това купуват допълнителни дискове за всички, за да имат 3 бази данни, за да извършват различни разработки. И така става. Видях също, че те не се страхуват да копират прод в постановка - много зависи от компанията. Но също така видях, че те много се страхуват и че често нямат достатъчно време и ръце. Но преди да преминем към тази тема, искам да чуя за Kubernetes. Правилно ли разбирам, че все още никой не е в прод?

DS: Имаме малки бази данни в прод. Говорим за обеми от десетки гигабайти и некритични услуги, за които ни мързеше да направим реплики (и няма такава нужда). И при условие, че има нормално хранилище под Kubernetes. Тази база данни работеше във виртуална машина - условно във VMware, върху системата за съхранение. Поставихме го вътре PV и сега можем да го прехвърляме от машина на машина.

NS: Бази данни с такъв размер, до 100 GB, могат да бъдат пуснати за няколко минути на добри дискове и добра мрежа, нали? Скорост от 1 GB в секунда вече не е екзотика.

DS: Да, за линейна работа това не е проблем.

NS: Добре, просто трябва да помислим за прод. И ако обмисляме Kubernetes за непродуктивни среди, какво трябва да направим? Виждам това в Zalando do оператор, в Крънчи рязане, има и други опции. И има OnGres - това е нашият добър приятел Алваро от Испания: това, което правят, по същество не е просто оператори цялото разпределение (StackGres), в който освен самия Postgres, решиха да сложат и резервно копие, проксито Envoy...

DS: Пратеник за какво? Специално балансиране на трафика на Postgres?

NS: Да. Тоест, те го виждат така: ако вземете Linux дистрибуция и ядро, тогава обикновеният PostgreSQL е ядрото и те искат да направят дистрибуция, която да е удобна за облака и да работи на Kubernetes. Те събират компоненти (резервни копия и т.н.) и ги отстраняват, така че да работят добре.

DS: Много яко! По същество това е софтуер за създаване на ваш собствен управляван Postgres.

NS: Linux дистрибуциите имат вечни проблеми: как да се направят драйвери, така че да се поддържа целият хардуер. И те имат идеята, че ще работят в Kubernetes. Знам, че в оператора Zalando наскоро видяхме връзка с AWS и това вече не е много добро. Не трябва да има връзка с конкретна инфраструктура - какъв е смисълът тогава?

DS: Не знам точно в каква ситуация е попаднал Zalando, но в Kubernetes съхранението вече е направено по такъв начин, че е невъзможно да се направи резервно копие на диска с помощта на общ метод. Recently in standard - в най-новата версия CSI спецификации — направихме възможни моментни снимки, но къде се прилага? Честно казано, всичко е още толкова сурово... Опитваме CSI върху AWS, GCE, Azure, vSphere, но веднага щом започнете да го използвате, можете да видите, че все още не е готов.

NS: Ето защо понякога трябва да разчитаме на инфраструктура. Мисля, че това е все още ранен етап - болки в растежа. Въпрос: Какъв съвет бихте дали на начинаещите, които искат да опитат PgSQL в K8s? Какъв оператор може би?

DS: Проблемът е, че Postgres е 3% за нас. Имаме и много голям списък от различен софтуер в Kubernetes, дори няма да изброявам всичко. Например Elasticsearch. Има много оператори: някои се развиват активно, други не. Ние сме изготвили изисквания за себе си, какво трябва да има в оператора, за да го приемем сериозно. В оператор специално за Kubernetes - не в "оператор, който да направи нещо в условията на Amazon"... Всъщност ние доста широко (= почти всички клиенти) използваме един оператор - за Redis (скоро ще публикуваме статия за него).

NS: А не и за MySQL? Знам, че Percona... тъй като сега работят върху MySQL, MongoDB и Postgres, ще трябва да създадат някакво универсално решение: за всички бази данни, за всички облачни доставчици.

DS: Нямахме време да разгледаме операторите за MySQL. Това не е основният ни фокус в момента. MySQL работи добре самостоятелно. Защо да използвате оператор, ако можете просто да стартирате база данни... Можете да стартирате Docker контейнер с Postrges или можете да го стартирате по прост начин.

NS: Имаше въпрос и за това. Изобщо няма оператор?

DS: Да, 100% от нас имат PostgreSQL, работещ без оператор. До тук така. Използваме активно оператора за Prometheus и Redis. Имаме планове да намерим оператор за Elasticsearch - той е този, който най-много „запали“, защото искаме да го инсталираме в Kubernetes в 100% от случаите. Точно както искаме да гарантираме, че MongoDB винаги е инсталиран в Kubernetes. Тук се появяват определени желания - има усещането, че в тези случаи може да се направи нещо. И ние дори не погледнахме Postgres. Разбира се, ние знаем, че има различни опции, но всъщност имаме самостоятелна.

DB за тестване в Kubernetes

NS: Да преминем към темата за тестването. Как да внедрите промени в базата данни - от гледна точка на DevOps. Има микроуслуги, много бази данни, нещо се променя някъде през цялото време. Как да осигурим нормален CI/CD, така че всичко да е наред от гледна точка на СУБД. Какъв е вашият подход?

DS: Не може да има един отговор. Вариантите са няколко. Първият е размерът на основата, която искаме да разгърнем. Вие сами споменахте, че компаниите имат различно отношение към наличието на копие на прод базата данни на dev и stage.

NS: И според условията на GDPR, мисля, че са все по-внимателни... Мога да кажа, че в Европа вече започнаха да налагат глоби.

DS: Но често можете да напишете софтуер, който взема дъмп от производството и го замъглява. Получават се производствени данни (моментна снимка, дъмп, двоично копие...), но са анонимизирани. Вместо това може да има скриптове за генериране: те могат да бъдат приспособления или просто скрипт, който генерира голяма база данни. Проблемът е: колко време отнема създаването на базово изображение? И колко време отнема разгръщането му в желаната среда?

Стигнахме до схема: ако клиентът има фиксиран набор от данни (минимална версия на базата данни), тогава ги използваме по подразбиране. Ако говорим за среди за преглед, когато създадохме клон, внедрихме екземпляр на приложението - разгърнахме малка база данни там. Но се получи добре вариант, когато вземаме дъмп от производството веднъж на ден (през нощта) и изграждаме Docker контейнер с PostgreSQL и MySQL с тези заредени данни, базирани на него. Ако трябва да разширите базата данни 50 пъти от това изображение, това се прави доста просто и бързо.

NS: Чрез обикновено копиране?

DS: Данните се съхраняват директно в изображението на Docker. Тези. Имаме готов образ, макар и 100 GB. Благодарение на слоевете в Docker можем бързо да разположим това изображение толкова пъти, колкото имаме нужда. Методът е глупав, но работи добре.

NS: Тогава, когато тествате, това се променя направо в Docker, нали? Копиране при запис в Docker - изхвърлете го и отидете отново, всичко е наред. клас! И използвате ли го вече пълноценно?

DS: За дълго време.

NS: Ние правим много подобни неща. Само ние не използваме копирането при запис на Docker, а някакво друго.

DS: Не е генерично. И Docker работи навсякъде.

NS: На теория, да. Но ние също имаме модули там, можете да правите различни модули и да работите с различни файлови системи. Какъв момент тук. От страна на Postgres, ние гледаме на всичко това по различен начин. Сега погледнах от страната на Docker и видях, че всичко работи за вас. Но ако базата данни е огромна, например 1 TB, тогава всичко това отнема много време: операции през нощта и пълнене на всичко в Docker... И ако 5 TB са пълнени в Docker... Или всичко е наред?

DS: Каква е разликата: това са петна, само битове и байтове.

NS: Разликата е следната: правите ли го чрез дъмп и възстановяване?

DS: Изобщо не е необходимо. Методите за генериране на това изображение могат да бъдат различни.

NS: За някои клиенти направихме така, че вместо редовно да генерираме базово изображение, ние постоянно го поддържаме актуално. По същество е реплика, но получава данни не от главния директно, а чрез архив. Бинарен архив, където всеки ден се теглят WAL, където се правят резервни копия... След това тези WAL достигат до базовия образ с малко забавяне (буквално 1-2 секунди). Ние клонираме от него по всякакъв начин - сега имаме ZFS по подразбиране.

DS: Но със ZFS сте ограничени до един възел.

NS: Да. Но ZFS има и магически изпрати: с него можете да изпратите моментна снимка и дори (все още не съм го тествал наистина, но...) можете да изпратите делта между две PGDATA. Всъщност имаме друг инструмент, който всъщност не сме обмисляли за подобни задачи. PostgreSQL има pg_rewind, който работи като „интелигентен“ rsync, пропускайки много от това, което не трябва да гледате, защото нищо не се е променило там. Можем да направим бърза синхронизация между двата сървъра и да превъртим по същия начин.

И така, от тази, повече DBA страна, ние се опитваме да създадем инструмент, който ни позволява да правим същото, което казахте: имаме една база данни, но искаме да тестваме нещо 50 пъти, почти едновременно.

DS: 50 пъти означава, че трябва да поръчате 50 спот инстанции.

NS: Не, ние правим всичко на една машина.

DS: Но как ще разширите 50 пъти, ако тази една база данни е да речем терабайтова. Най-вероятно тя се нуждае от условни 256 GB RAM?

NS: Да, понякога се нуждаете от много памет - това е нормално. Но това е пример от живота. Производствената машина има 96 ядра и 600 GB. В същото време за базата данни се използват 32 ядра (дори 16 ядра сега понякога) и 100-120 GB памет.

DS: И 50 копия се побират там?

NS: Значи има само едно копие, тогава копирането при запис (ZFS) работи... Ще ви разкажа по-подробно.

Например имаме 10 TB база данни. Направиха му диск, ZFS също го компресира с 30-40 процента. Тъй като не правим тестове за натоварване, точното време за реакция не е важно за нас: нека бъде до 2 пъти по-бавно - това е добре.

Даваме възможност на програмисти, QA, DBA и др. извършете тестване в 1-2 нишки. Например, те могат да изпълнят някакъв вид миграция. Не изисква 10 ядра наведнъж - има нужда от 1 Postgres бекенд, 1 ядро. Миграцията ще започне - може би автовакуум все пак ще стартира, тогава ще се използва второто ядро. Разполагаме с 16-32 ядра, така че 10 души могат да работят едновременно, няма проблем.

Защото физически PGDATA същото, оказва се, че всъщност заблуждаваме Postgres. Номерът е следният: например, 10 Postgres се стартират едновременно. Какъв обикновено е проблемът? Те поставят споделени_буфери, да кажем 25%. Съответно това е 200 GB. Няма да можете да стартирате повече от три от тях, защото паметта ще свърши.

Но в един момент осъзнахме, че това не е необходимо: ​​зададохме shared_buffers на 2 GB. PostgreSQL има ефективен_размер_кеш, а реално само той влияе планове. Настроихме го на 0,5 TB. И дори няма значение, че те всъщност не съществуват: той прави планове, сякаш съществуват.

Съответно, когато тестваме някаква миграция, можем да съберем всички планове - ще видим как ще стане в продукцията. Секундите там ще бъдат различни (по-бавни), но данните, които всъщност четем, и самите планове (какви JOIN-и има и т.н.) се оказват точно същите като в производството. И можете да изпълнявате много такива проверки паралелно на една машина.

DS: Не мислите ли, че тук има няколко проблема? Първото е решение, което работи само на PostgreSQL. Този подход е много личен, не е общ. Второто е, че Kubernetes (и всичко, което облачните технологии ще направят сега) включва много възли и тези възли са ефимерни. И във вашия случай това е състояние, постоянен възел. Тези неща ме правят конфликтен.

NS: Първо, съгласен съм, това е чисто Postgres история. Мисля, че ако имаме някакъв вид директен IO и буферен пул за почти цялата памет, този подход няма да работи - плановете ще бъдат различни. Но засега работим само с Postgres, не мислим за други.

Относно Kubernetes. Вие сами ни казвате навсякъде, че имаме постоянна база данни. Ако екземплярът се провали, основното е да запазите диска. Тук също имаме цялата платформа в Kubernetes, а компонентът с Postgres е отделен (въпреки че някой ден ще го има). Следователно всичко е така: екземплярът падна, но ние запазихме неговия PV и просто го свързахме с друг (нов) екземпляр, сякаш нищо не се е случило.

DS: От моя гледна точка ние създаваме подове в Kubernetes. K8s - ластик: възлите се поръчват според нуждите. Задачата е просто да създадете под и да кажете, че се нуждае от X количество ресурси, а след това K8s ще го разбере сам. Но поддръжката за съхранение в Kubernetes все още е нестабилна: 1.16, Аз Н 1.17 (това издание беше пуснато на седмицата преди) тези функции стават само бета.

Ще минат шест месеца до година - ще стане повече или по-малко стабилно или поне ще бъде обявено за такова. Тогава възможността за моментни снимки и преоразмеряване решава проблема ви напълно. Защото имаш база. Да, може да не е много бързо, но скоростта зависи от това какво има „под капака“, защото някои реализации могат да копират и копират при запис на ниво дискова подсистема.

NS: Също така е необходимо всички двигатели (Amazon, Google...) да започнат да поддържат тази версия - това също отнема известно време.

DS: Все още не ги използваме. Ние използваме нашите.

Локално развитие за Kubernetes

NS: Срещали ли сте такова желание, когато трябва да инсталирате всички подове на една машина и да направите такъв малък тест. За да получите бързо доказателство за концепцията, вижте, че приложението работи в Kubernetes, без да отделяте куп машини за него. Има Minikube, нали?

DS: Струва ми се, че този случай - разгърнат на един възел - е изключително за местно развитие. Или някои прояви на такъв модел. Яжте Миникубетам k3s, МИЛ. Преминаваме към използване на Kubernetes IN Docker. Сега започнахме да работим с него за тестове.

NS: Мислех, че това е опит да се обвият всички подове в едно Docker изображение. Но се оказа, че става дума за нещо съвсем различно. Както и да е, има отделни контейнери, отделни подове - само в Docker.

DS: Да. И има доста забавна имитация, но смисълът е следният... Имаме помощна програма за внедряване - werf. Искаме да го направим условен режим werf up: „Вземете ми местен Kubernetes.“ И след това изпълнете условното условие там werf follow. След това разработчикът ще може да редактира IDE и в системата ще бъде стартиран процес, който вижда промените и възстановява изображенията, преразпределяйки ги в локални K8. Така искаме да се опитаме да решим проблема с местното развитие.

Снимки и клониране на база данни в реалността на K8s

NS: Ако се върнем към копиране при запис. Забелязах, че облаците също имат моментни снимки. Те работят по различен начин. Например в GCP: имате многотерабайтово копие на източното крайбрежие на Съединените щати. Периодично правите моментни снимки. Взимате копие на диска на западния бряг от снимка - след няколко минути всичко е готово, работи много бързо, само кеша трябва да се попълни в паметта. Но тези клонинги (моментни снимки) са с цел „осигуряване“ на нов том. Това е страхотно, когато трябва да създадете много екземпляри.

Но за тестовете ми се струва, че моментните снимки, за които говорите в Docker или аз говоря в ZFS, btrfs и дори LVM... - те ви позволяват да не създавате наистина нови данни на една машина. В облака пак ще плащате за тях всеки път и ще чакате не секунди, а минути (и в случая мързеливо натоварване, евентуално часовник).

Вместо това можете да получите тези данни за секунда или две, да стартирате теста и да го изхвърлите. Тези моментни снимки решават различни проблеми. В първия случай - за мащабиране и получаване на нови реплики, а във втория - за тестове.

DS: Не съм съгласен. Задачата на облака е да накара клонирането да работи правилно. Не съм разглеждал тяхното изпълнение, но знам как го правим на хардуера. Имаме Ceph, позволява всякакъв физически обем (RBD) казвам клонинг и да получите втори обем със същите характеристики за десетки милисекунди, IOPS'ами и т.н. Трябва да разберете, че вътре има сложно копиране при запис. Защо облакът да не направи същото? Сигурен съм, че се опитват да направят това по един или друг начин.

NS: Но пак ще им отнеме секунди, десетки секунди, за да създадат инстанция, да доведат Docker там и т.н.

DS: Защо е необходимо да се повдигне цяла инстанция? Имаме един екземпляр с 32 ядра, 16... и може да влезе в него - примерно четири. Когато поръчаме петия, инстанцията вече ще бъде повдигната и след това ще бъде изтрита.

NS: Да, интересно, Kubernetes се оказва различна история. Нашата база данни не е в K8s и имаме един екземпляр. Но клонирането на многотерабайтова база данни отнема не повече от две секунди.

DS: Това е страхотно. Но първоначалната ми точка е, че това не е общо решение. Да, страхотно е, но е подходящо само за Postgres и само на един възел.

NS: Подходящ е не само за Postgres: тези планове, както описах, ще работят само в него. Но ако не се занимаваме с планове и просто се нуждаем от всички данни за функционално тестване, тогава това е подходящо за всяка СУБД.

DS: Преди много години направихме нещо подобно на моментни снимки на LVM. Това е класика. Този подход беше много активно използван. Възлите със състояние са просто болка. Защото не трябва да ги изпускате, винаги трябва да ги помните...

NS: Виждате ли някаква възможност за хибрид тук? Да кажем, че stateful е някакъв вид pod, работи за няколко души (много тестери). Имаме един том, но благодарение на файловата система клонингите са локални. Ако капсулата падне, но дискът остане, капсулата ще се издигне, ще преброи информацията за всички клонинги, ще вземе всичко отново и ще каже: „Ето вашите клонинги, работещи на тези портове, продължете да работите с тях.“

DS: Технически това означава, че в Kubernetes това е един под, в който изпълняваме много Postgres.

NS: Да. Той има ограничение: да кажем, че не повече от 10 души работят с него едновременно. Ако имате нужда от 20, ще пуснем втора такава капсула. Ние ще го клонираме напълно, след като получим втория пълен том, той ще има същите 10 „тънки“ клонинга. Не виждате ли тази възможност?

DS: Трябва да добавим проблеми със сигурността тук. Този тип организация предполага, че този pod има високи привилегии (възможности), защото може да извършва нестандартни операции върху файловата система... Но повтарям: вярвам, че в средносрочен план те ще поправят съхранението в Kubernetes и в облаците ще оправят цялата история с обеми - всичко ще „просто работи“. Ще има преоразмеряване, клониране... Има обем - казваме: „Създайте нов въз основа на това“ и след секунда и половина получаваме това, което ни трябва.

NS: Не вярвам в секунда и половина за много терабайти. На Ceph го правиш сам, но говориш за облаците. Отидете в облака, направете клонинг на многотерабайтов EBS том на EC2 и вижте каква ще бъде производителността. Няма да отнеме няколко секунди. Много ми е интересно кога ще стигнат това ниво. Разбирам какво искаш да кажеш, но моля да се разгранича.

DS: Добре, но казах в средносрочен план, не в краткосрочен план. За няколко години.

Относно оператора за PostgreSQL от Zalando

В средата на тази среща Алексей Клюкин, бивш разработчик от Zalando, също се присъедини и говори за историята на оператора PostgreSQL:

Чудесно е, че тази тема е засегната като цяло: както Postgres, така и Kubernetes. Когато започнахме да го правим в Zalando през 2017 г., това беше тема, която всички искаха да направят, но никой не го направи. Всички вече имаха Kubernetes, но когато попитаха какво да правят с базите данни, дори хората харесаха Келси Хайтауър, който проповядва K8s, каза нещо подобно:

„Отидете на управлявани услуги и ги използвайте, не стартирайте базата данни в Kubernetes. В противен случай вашите K8s ще решат например да направят надстройка, да изключат всички възли и вашите данни ще отлетят далеч, далеч.

Решихме да направим оператор, който, противно на този съвет, ще стартира Postgres база данни в Kubernetes. И имахме добра причина - Патрони. Това е автоматичен отказ за PostgreSQL, направен правилно, т.е. използване на etcd, consul или ZooKeeper като хранилище на информация за клъстера. Такова хранилище, което ще даде на всеки, който пита например какъв е текущият лидер, една и съща информация - въпреки факта, че имаме всичко разпределено - така че да няма разцепване на мозъка. Освен това имахме Докер изображение за него.

Като цяло нуждата на компанията от автоматично прехвърляне на данни се появи след мигрирането от вътрешен хардуерен център за данни към облака. Облакът беше базиран на собствено решение PaaS (платформа като услуга). Той е с отворен код, но отне много работа, за да го стартирате. Беше наречено СТЪПКИ.

Първоначално нямаше Kubernetes. По-точно, когато нашето собствено решение беше разгърнато, K8 вече съществуваше, но беше толкова сурово, че не беше подходящо за производство. Беше според мен 2015 или 2016 г. До 2017 г. Kubernetes стана повече или по-малко зрял - имаше нужда да мигрира там.

И вече имахме Docker контейнер. Имаше PaaS, който използваше Docker. Защо не опитате K8s? Защо не напишете свой собствен оператор? Мурат Кабилов, който дойде при нас от Avito, започна това като проект по собствена инициатива - „да играе“ - и проектът „излетя“.

Но като цяло исках да говоря за AWS. Защо имаше исторически код, свързан с AWS...

Когато стартирате нещо в Kubernetes, трябва да разберете, че K8s е такъв процес на работа. Той непрекъснато се развива, усъвършенства и дори от време на време се поврежда. Трябва да следите внимателно всички промени в Kubernetes, трябва да сте готови да се потопите в него, ако нещо се случи, и да научите как работи в детайли - може би повече, отколкото бихте искали. Това по принцип се отнася за всяка платформа, на която стартирате вашите бази данни...

И така, когато направихме изявлението, имахме Postgres, работещ на външен том (EBS в този случай, тъй като работихме върху AWS). Базата данни нарасна, в един момент беше необходимо да я преоразмерим: например първоначалният размер на EBS беше 100 TB, базата данни нарасна до него, сега искаме да направим EBS 200 TB. как? Да приемем, че можете да направите дъмп/възстановяване на нов екземпляр, но това ще отнеме много време и ще включва прекъсване.

Затова исках преоразмеряване, което да увеличи EBS дяла и след това да каже на файловата система да използва новото пространство. И го направихме, но по това време Kubernetes нямаше API за операцията за преоразмеряване. Тъй като работихме върху AWS, написахме код за неговия API.

Никой не ви спира да правите същото за други платформи. В изявлението няма намек, че може да се изпълнява само на AWS и няма да работи на всичко останало. Като цяло това е проект с отворен код: ако някой иска да ускори появата на използването на новия API, добре дошъл. Яжте GitHub, заявки за изтегляне - екипът на Zalando се опитва да им отговори доста бързо и да популяризира оператора. Доколкото знам, проектът участвал на Google Summer of Code и някои други подобни инициативи. Zalando работи много активно по него.

PS бонус!

Ако се интересувате от темата за PostgreSQL и Kubernetes, моля, имайте предвид също, че следващият Postgres вторник се проведе миналата седмица, където говорих с Николай Александър Кукушкин от Zalando. Налично е видео от него тук.

PPS

Прочетете също в нашия блог:

• «Бази данни и Kubernetes (преглед и видео отчет)»;
• «Миграция на Cassandra към Kubernetes: функции и решения»;
• «Безпроблемна миграция на MongoDB към Kubernetes»;
• «Безпроблемна миграция на RabbitMQ към Kubernetes".

Източник: www.habr.com