Наприкінці минулого року відбувся черговий прямий ефір російської PostgreSQL-спільноти У рамках якого його співзасновник Микола Самохвалов поговорив з технічним директором «Фланту» Дмитром Столяровим про цю СУБД у контексті Kubernetes.
Ми публікуємо стенограму основної частини цієї дискусії, а на опубліковано повний відеозапис:
Бази даних та Kubernetes
НС: Ми не будемо сьогодні про VACUUM та CHECKPOINT'и Хочемо поговорити про Kubernetes. Я знаю, що в тебе вже багато років досвіду. Дивився твої відео і деякі навіть шматочками переглядав… Давай одразу з місця у кар'єр: навіщо взагалі Postgres чи MySQL у K8s?
ДС: Однозначної відповіді на це питання немає і не може бути Але взагалі, це простота та зручність… потенційні. Адже всім хочеться managed-сервісів.
НС: Щоб як , Тільки в себе?
ДС: Так: щоб як RDS, тільки де завгодно
НС: «Де завгодно» - це гарне зауваження У великих компаніях все розташоване у різних місцях. А чому тоді, якщо це велика компанія, не ухвалити готове рішення? Наприклад, у Nutanix свої розробки, в інших компаній (VMware ...) - той же "RDS, тільки у себе".
ДС: Але це ми говоримо про окремо взяту реалізацію, яка працюватиме лише в певних умовах А якщо мова про Kubernetes, то тут велика різноманітність інфраструктури (яка може бути в K8s). Насправді це стандарт для API до хмари…
НС: Ще та безкоштовно!
ДС: Це не так важливо. Безкоштовність важлива невеликому сегменту ринку. Важливо інше… Ти, мабуть, згадуєш доповідь»?
НС: Так
ДС: Я зрозумів, що його сприйняли дуже неоднозначно Частина людей подумали, що я кажу: «Хлопці, поїхали всіма БД у Kubernetes!», а інші вирішили, що це все моторошні велосипеди. А я хотів сказати взагалі про інше: «Дивіться, що відбувається, які є проблеми та як їх можна вирішувати. Зараз їхати базами до Kubernetes? Production'ом? Ну, тільки якщо ви любите займатися певними речами. А ось для dev'а – можу сказати, що рекомендую. Для dev'а дуже важлива динамічність створення/видалення оточення».
НС: Під dev'ом ти маєш на увазі всі оточення, які не prod? Staging, QA…
ДС: Якщо говоримо про perf-стенди, то вже, напевно, ні, бо там вимоги специфічні Якщо говоримо про особливі випадки, де на staging потрібна дуже велика БД, то теж, напевно, ні… Якщо це статичне оточення, яке довго довго живе, то яка вигода від того, що база розташована в K8s?
НС: Ніякий. Але де ми бачимо статичні оточення? Статичне оточення застаріло вже завтра.
ДС: Staging може бути статичним У нас є клієнти.
НС: Так, у мене теж є Велика проблема, якщо маєш базу на 10 Тб, а staging — 200 Гб…
ДС: У мене є дуже крутий кейс На staging знаходиться prod'ова база, в яку вносять зміни. І передбачена кнопка: "викотити в production". Ці зміни - дельти - доливаються (здається, просто по API'шке синхронізуються) в production. Це дуже екзотичний варіант.
НС: Я бачив стартапи в Долині, які сидять у RDS'і або навіть у Heroku ще - це історії 2-3-річної давності, - і вони скачують дамп собі на лаптоп Тому що база поки лише 80 Гб, а на лаптопі є місце. Потім вони докуповують диски кожному, щоб по 3 бази мати, щоб різні розробки вести. Отак буває теж. Також бачив, що не бояться prod копіювати в staging дуже залежить від компанії. Але бачив і що дуже бояться, і часто не вистачає часу і рук. Але перш, ніж ми перейдемо до цієї теми, хочеться почути про Kubernetes. Я правильно розумію, що в prod'і поки що ні в кого?
ДС: У нас невеликі бази є у prod'і Мова про обсяги в десятки гігабайт і некритичні сервіси, для яких ліньки було робити репліки (та й немає такої потреби). І за умови, що під Kubernetes'ом є нормальне сховище. Ця база працювала у віртуальній машині - умовно в VMware, поверх СГД. Ми її помістили в і тепер можемо переносити її з машини на машину.
НС: Бази такого розміру, до 100 Гб, на хороших дисках і за хорошої мережі можна розкачати за кілька хвилин, правильно? Швидкість 1 Гб на секунду - це вже не екзотика.
ДС: Так, для лінійної операції це не проблема
НС: Окей, про prod ми повинні тільки думати А якщо ми розглядаємо Kubernetes для не-prod-оточень – як робити? Я бачу, що в Zalando у Crunchy , Є ще якісь варіанти. І є - Це наш добрий знайомий Alvaro з Іспанії: вони роблять по суті не просто , а цілий дистрибутив (), в який, крім самого Postgres'а, ще й бекап вирішили запхати, проксі Envoy…
ДС: Envoy для чого? Балансування саме трафіку Postgres?
НС: Так Тобто вони це бачать як: якщо взяти Linux-дистрибутив та ядро, то звичайний PostgreSQL – це ядро, а вони хочуть зробити дистрибутив, який буде дружелюбний до хмар і крутитись у Kubernetes. Вони стикують компоненти (бекапи тощо) та налагоджують, щоб вони добре працювали.
ДС: Дуже круто! По суті, це софт, щоб зробити свій managed Postgres.
НС: У Linux-дистрибутивів вічні проблеми: як робити драйвери, щоб все залізо підтримувалося. А у них ідея, що вони в Kubernetes працюватимуть. Я знаю, що в операторі Zalando ми нещодавно побачили зав'язку на AWS, і це вже не дуже добре. Не повинно бути зав'язки на конкретну інфраструктуру — в чому тоді сенс?
ДС: Не знаю, в якій ситуації конкретно Zalando зав'язався, але в Kubernetes зараз storage зроблений так, що не можна generic-способом зняти дисковий бекап Нещодавно у стандарті — в останній версії - Зробили можливість снапшотів, але де вона реалізована? Чесно, все ще настільки сире… Ми пробуємо CSI поверх AWS, GCE, Azure, vSphere, але починаєш використовувати, як видно, що воно ще не готове.
НС: Тому і доводиться іноді зав'язуватися на інфраструктуру Думаю, це ще триває рання стадія — проблеми зростання. Питання: що б ти порадив новачкам, які хочуть спробувати PgSQL у K8s? Який оператор може бути?
ДС: Проблема в тому, що Postgres для нас - це 3% У нас є ще дуже великий список різного софту в Kubernetes, навіть не перераховуватиму. Наприклад, Elasticsearch. Операторів купа: якісь розвиваються активно, інші ні. Ми для себе склали вимоги, що має бути в операторі, щоб ми сприймали його всерйоз. В операторі саме для Kubernetes — не в «операторі, щоб робити щось в умовах Amazon'а»… За фактом ми досить масово (= майже всі клієнти) використовуємо єдиний оператор — (Незабаром опублікуємо статтю і про нього).
НС: А для MySQL теж немає? Я знаю, що Percona ... так як вони тепер займаються і MySQL, і MongoDB, і Postgres, вони повинні будуть якийсь універсальний запиляти: для всіх баз, для хмарних провайдерів.
ДС: Ми не встигли подивитися на оператори для MySQL Для нас це нині не головний фокус. MySQL нормально працює в standalone. Навіщо оператор, якщо можеш просто запустити БД… Можна запустити Docker-контейнер із Postrges, а можна запустити його просто.
НС: Про це теж було питання Взагалі, без оператора?
ДС: Так, у 100% у нас PostgreSQL запущений без оператора Поки що так. Ми активно використовуємо оператор для Prometheus, Redis. У нас є в планах знайти оператор для Elasticsearch — він найбільше горить, тому що хочемо його в 100% випадках ставити в Kubernetes. Так само, як ми хочемо прийти до того, щоб MongoDB теж завжди ставити в Kubernetes. Тут з'являються певні хотілки — є відчуття, що у випадках можна щось зробити. А про Postgres ми навіть не дивилися. Звичайно, знаємо про існування різних варіантів, але за фактом у нас standalone.
БД для тестування в Kubernetes
НС: Давай перейдемо до теми тестування Як розкочувати зміни в базі – з погляду DevOps-перспективи. Є мікросервіси, багато баз, постійно десь щось змінюється. Як забезпечити нормальний CI/CD, щоб з позиції СУБД все було гаразд. Який у тебе підхід?
ДС: Не може бути однієї відповіді Є кілька параметрів. Перший це розмір бази, яку ми хочемо розкотити. Ти сам згадав, що у компаніях по-різному ставляться до того, щоб копія prod-бази була на dev та stage.
НС: А в умовах GDPR, я думаю, вони ставляться дедалі акуратніше... Можу сказати, що в Європі вже почали штрафувати.
ДС: Але найчастіше можна написати софт, який робить дамп з production'а та його обфусцьує Виходять prod'ові дані (снапшот, дамп, бінарна копія…), але вони анонімізовані. Натомість можуть бути і скрипти генерації: це можуть бути фікстури або просто скрипт, який генерує велику базу. Проблема яка: скільки часу створюється базовий образ? І скільки часу розгорнути його у потрібному оточенні?
Ми прийшли до схеми: якщо клієнт має фікстурний набір даних (мінімальна версія бази), то за замовчуванням використовуємо їх. Якщо мова йде про review-оточення, коли ми створили branch, у нас розгорнувся екземпляр програми - ми туди розкочуємо маленьку базу. Але добре вийшов і , коли з production'а раз на добу (вночі) знімаємо дамп і збираємо на його підставі Docker-контейнер з PostgreSQL та MySQL із цими завантаженими даними. Якщо з цього образу треба 50 разів розгорнути базу, це робиться досить легко і швидко.
НС: Простим копіюванням?
ДС: Дані зберігаються прямо в Docker-образі Тобто. у нас є готовий образ, хай на 100 Гб. Завдяки шарам Docker ми можемо швидко розгортати цей образ потрібну кількість разів. Спосіб тупий, але працює непогано.
НС: Далі, коли тестуєте, воно прямо всередині Docker'а змінюється, так? Copy-on-write всередині Docker'а - викидаємо і знову поїхали, все добре. Клас! І ви це вже використовуєте на повну силу?
ДС: Давно
НС: Ми дуже схожими речами займаємося Тільки ми не Docker'овський copy-on-write використовуємо, а якийсь ще.
ДС: Він не generic А Docker'ний працює повсюдно.
НС: За ідеєю, так Але у нас теж є модулі, можна різні модулі зробити і працювати з різними файловими системами. Тут якийсь момент. Ми з боку Postgres на все це по-іншому дивимося. Тепер я подивився з боку Docker і побачив, що у вас все працює. Але якщо база - величезна, наприклад, 1 Тб, то це вже все довго: і операції вночі, і запихати все в Docker ... А якщо 5 Тб запихати в Docker ... Чи все нормально?
ДС: Яка різниця: це ж блоби, просто биті та байти
НС: Різниця така: ви це через dump та restore робите?
ДС: Зовсім необов'язково Способи генерації цього можуть бути різні.
НС: Для деяких клієнтів ми зробили так, що замість регулярної генерації базового образу ми постійно підтримуємо його в актуальному стані. Він насправді є реплікою, але дані отримує не з майстра безпосередньо, а через архів. Бінарний архів, куди WAL'и накочуються щодня, там же бекапи знімаються… Ці WAL'и потім долітають — із невеликою затримкою (буквально 1-2 секунди) — до базового образу. З нього ми у будь-який спосіб клонуємо — зараз за замовчуванням у нас є ZFS.
ДС: Але з ZFS ви обмежені одним вузлом
НС: Так Але у ZFS є ще чарівний : з ним можна надіслати снапшот і навіть (я це ще не дуже тестував, але…) можна надсилати дельту між двома PGDATA. Насправді, ми маємо ще один інструмент, який ми не особливо розглядали для таких завдань. У PostgreSQL є , що працює як «розумний» rsync, що пропускає багато з того, що можна не дивитися, тому що там точно нічого не змінювалося. Ми можемо між двома серверами зробити швидку синхронізацію і відмотати назад так само.
Так ось, ми намагаємося з цієї, більш DBA'ної, сторони зробити інструмент, який дозволяє зробити те саме, про що ти казав: у нас є одна база, але ми хочемо 50 разів щось протестувати, чи не одночасно.
ДС: 50 разів означає, що вам потрібно замовити 50 Spot'ових інстансів.
НС: Ні, на одній машині все робимо
ДС: Але як ви розгорнете 50 разів, якщо ця одна база, скажімо, терабайтова Швидше за все, їй потрібно умовно 256 Гб RAM?
НС: Так, пам'яті іноді потрібно багато - це нормально Але такий приклад із життя. На production-машині 96 ядер та 600 Гб. При цьому для БД використовуються 32 ядра (навіть 16 ядер зараз іноді) та пам'яті 100-120 Гб.
ДС: І туди влазить 50 копій?
НС: Так копія одна, далі працює copy-on-write (ZFS'ний) ... Розповім докладніше.
В нас, наприклад, база на 10 Тб. Диск для неї зробили, ZFS ще стиснув її розмір відсотків на 30-40. Оскільки ми не робимо навантажувального тестування, нам точний час відгуку не має значення: нехай буде до 2 разів гальмівніше — це окей.
Ми надаємо можливість програмістам, QA, DBA тощо. виконувати тестування в 1-2 потоки. Наприклад, вони можуть запустити якусь міграцію. Вона не вимагає відразу 10 ядер - їй потрібен 1 бекенд Postgres'а, 1 ядро. Міграція запуститься - може, ще запуститься, тоді друге ядро задіюється. У нас виділено 16-32 ядер, тож 10 осіб можуть одночасно працювати, жодних проблем немає.
Оскільки фізично PGDATA однакова, виходить так, що ми обманюємо Postgres насправді. Фішка в чому: запускається, наприклад, 10 Postgres одночасно. Проблема зазвичай якась? Ставлять , припустимо, у 25%. Відповідно, це 200 Гб. Більше трьох таких уже не запустиш, бо пам'ять скінчиться.
Але ми в якийсь момент зрозуміли, що це не потрібно: ми ставимо shared_buffers у 2 Гб. у PostgreSQL є , і насправді тільки він впливає на . Його ми ставимо в 0,5 Тб. І навіть не важливо, що їх насправді немає: він будує плани, начебто вони є.
Відповідно, коли ми тестуємо якусь міграцію, можна зібрати всі плани – ми побачимо, як воно відбуватиметься на production. Секунди там будуть інші (гальмівніші), але дані, які ми реально зчитуємо, і самі плани (які там JOIN'и тощо) виходять такими самими, як на production. І паралельно можна запускати багато таких перевірок на одній машині.
ДС: Ти не вважаєш, що тут є кілька проблем? Перша – це рішення, яке працює лише на PostgreSQL. Такий підхід дуже приватний, він не generic. Друга - Kubernetes (і все, куди зараз йдуть хмарні технології) передбачає безліч вузлів, і ці вузли - ефемерні. А у твоєму випадку це stateful, персистентний вузол. Ці речі у мене викликають протиріччя.
НС: Перше - згоден, це чисто Postgres'ова історія Думаю, якщо у нас є якийсь direct IO і буферний пул майже на всю пам'ять, такий підхід не підійде — плани будуть інші. Але ми поки що тільки з Postgres і працюємо, про інших не думаємо.
Про Kubernetes. Ти ж скрізь розповідаєш, що в нас база персистентна. Якщо інстанс впав, головне зберегти диск. Ось у нас теж вся платформа в Kubernetes, а компонент з Postgres окремо (хоча і він там якось буде). Тому все так: інстанс впав, але ми зберегли його PV і просто підключили до іншого (нового) інстансу, ніби нічого не сталося.
ДС: На мій погляд, ми створюємо pod'и в Kubernetes K8s - еластичний: вузли замовляються самі при необхідності. Завдання просто створити pod і сказати, що йому потрібно X ресурсів, а далі K8s сам розбереться. Але підтримка сховищ у Kubernetes, як і раніше, нестабільна: , в (Цей реліз вийшов тижня тому) ці фічі стають лише бетою.
Мине півроку-рік — воно стане більш-менш стабільним, або хоча б буде заявлено таким. Тоді можливість снапшотів та resize'а вже вирішує ваше завдання повністю. Тому що у вас є основа. Так, вона може бути не дуже швидкою, але швидкість залежить від того, що під капотом, тому що деякі реалізації вміють копіювання і copy-on-write на рівні дискової підсистеми.
НС: Тут же треба ще, щоб всі движки (Amazon, Google ...) встигли почати підтримувати цю версію - адже це теж якийсь час займає.
ДС: Поки що ми їх не використовуємо Ми використовуємо своє.
Локальна розробка під Kubernetes
НС: Чи стикався ти з такою хотівкою, коли потрібно на одній машині підняти всі pod'и і зробити таке маленьке тестування Щоб швидко отримати proof of concept, подивитися, що програма працює в Kubernetes, не виділяючи під це купу машин. Чи є Minikube, так?
ДС: Мені здається, цей кейс — на одному вузлі розгорнути — про локальну розробку виключно Або якісь прояви такого патерну. Є , Є , . Ми йдемо до того, що будемо використовувати Kubernetes IN Docker. Наразі почали з ним працювати для тестів.
НС: Я раніше думав, що це спроба завернути всі pod'и в один Docker-образ Але виявилося, що це зовсім інше. Все одно там окремі контейнери, окремі pod'и — просто в Docker'і.
ДС: Так І там досить кумедна імітація зроблена, але сенс такий… У нас є утиліта для деплою. . Ми хочемо в ній зробити режим — умовно werf up: «Підніми мені локальний Kubernetes» І далі запустити там умовний werf follow. Тоді розробник зможе правити в IDE, а в системі запущено процес, який бачить зміни та перезбирає образи, передеплоює їх у локальний K8s. Тож ми хочемо спробувати вирішити проблему локальної розробки.
Снапшоти та клонування БД у реаліях K8s
НС: Якщо повернутися до copy-on-write Я помітив, що хмари теж мають снапшоти. Вони працюють по-різному. Наприклад, у GCP: у тебе на східному узбережжі США є багатотерабайтний інстанс. Робиш періодично снапшоти. Піднімаєш із снапшота копію диска на західному узбережжі — за кілька хвилин уже все готово, працює дуже швидко, тільки кеш треба заповнити в пам'яті. Але ці клони (снапшоти) — для того, щоб запропонувати новий том. Це круто, коли потрібно багато інстансів створити.
А ось для тестів, мені здається, снапшоти, про які ти розповідаєш у Docker'і або я розповідаю в ZFS, btrfs і навіть LVM... вони дозволяють якраз на одній машині не робити реально нові дані. У хмарі ти ще платитимеш за них щоразу і чекатимеш уже не секунди, а хвилини (а у разі , можливо, і годинник).
Натомість можна за секунду-дві отримати ці дані, поганяти тест і викинути. Ці снапшоти вирішують різні завдання. У першому випадку — щоби відмасштабуватися й нові репліки отримати, а в другому — для тестів.
ДС: Не погоджуся Зробити нормально клонування томів це завдання хмари. Я не дивився їхню реалізацію, але знаю, як це робимо ми на залозі. У нас є Ceph, в ньому можна будь-якому фізичному тому () сказати клон і отримати за десятки мілісекунд другий том з такими ж характеристиками, Самі і т.п. Треба розуміти, що там усередині хитрий copy-on-write. Чому хмари не робити так само? Впевнений, що вони так чи інакше намагаються це зробити.
НС: Але у них все одно підуть секунди, десятки секунд, щоб підняти інстанс, привести туди Docker і т.д.
ДС: Чому обов'язково цілий інстанс піднімати? А в нас є інстанс на 32 ядра, на 16... і в нього скількись залазить — наприклад, чотири. Коли ми замовляємо п'ятий, вже підніметься інстанс, а потім він відійде.
НС: Так, цікаво, у Kubernetes виходить інша історія У нас БД не в K8s і один інстанс. Натомість на клонування багатотерабайтної бази йде не більше двох секунд.
ДС: Це круто. Але моє початкове посилання в тому, що це не generic-рішення. Так, воно класне, але підходить лише Postgres і лише на одному вузлі.
НС: Воно підходить не тільки для Postgres: це плани, як я описував, будуть так працювати тільки в ньому Але якщо не морочитися щодо планів, а нам просто потрібні всі дані для функціонального тестування, тоді це підійде для будь-якої СУБД.
ДС: Багато років тому ми робили подібне на LVM-снапшотах Це класика. Такий підхід дуже активно використовувався. Просто stateful-вузли – це біль. Тому що їх треба не кидати, завжди про них пам'ятати.
НС: Чи не бачиш ти тут якоїсь можливості гібрида? Допустимо, stateful - це pod якийсь, він працює на кількох людей (багато тестувальників). Том у нас один, але завдяки файловій системі клони локальні. Якщо pod впав, диск залишився - підніметься pod, інформацію про всі клони рахує, все назад підніме і скаже: "От ваші клони на цих портах запущені, працюйте з ними далі".
ДС: Технічно це означає, що в рамках Kubernetes це один pod, всередині якого ми запускаємо багато Postgres'ів
НС: Так Він має ліміт: припустимо, одночасно з ним працюють не більше 10 осіб. Якщо потрібно 20 - запустимо другий такий під. Цілком реально схиляємо його, отримавши другий повний том, на ньому будуть такі ж 10 тонких клонів. Чи не бачиш такої можливості?
ДС: Треба додати сюди питання безпеки Такий варіант організації має на увазі, що у цього pod'а високі привілеї (capabilities), тому що він може виконувати нестандартні операції над файловою системою… Але повторюся: я вважаю, що в середньостроковій перспективі в Kubernetes полагодять storage, у хмарах полагодять всю історію з томами — все «просто працюватиме». Буде resize, клонування… Є тому — ми кажемо: «Створи новий на основі того», — і за півтори секунди отримуємо все.
НС: Не вірю в півтори секунди для багатьох терабайт На Ceph ти робиш сам, а говориш про хмари. Піди в хмару, на EC2 зроби клон тома EBS багатьох терабайт і подивися, яка продуктивність буде. Це не триватиме кілька секунд. Мені дуже цікаво, коли вони дійдуть такого показника. Розумію, про що ти говориш, але дозволю собі не погодитись.
ДС: Ок, але я сказав, що в середньостроковій перспективі, не короткостроковій Протягом декількох років.
Про оператор для PostgreSQL від Zalando
У середині цієї зустрічі до неї також підключився Олексій Клюкін, колишній розробник компанії Zalando, який розповів про історію оператора PostgreSQL:
Здорово, що ця тема взагалі порушена: і Postgres, і Kubernetes. Коли ми починали її робити в Zalando у 2017 році, це була така тема, якою всі хотіли займатися, але ніхто не робив. У всіх вже з'являвся Kubernetes, але коли питали, як бути з базами даних, то навіть такі люди, як , що проповідували K8s, говорили приблизно таке:
«Ідіть у managed-сервіси та використовуйте їх, не запускайте БД у Kubernetes. Інакше ваш K8s вирішить, наприклад, зробити апгрейд, згасить усі вузли, і ваші дані відлетять далеко-далеко».
Ми вирішили зробити оператор, який буде, попри цю пораду, запускати БД Postgres у Kubernetes. І у нас була хороша основа — . Це автоматичний failover для PostgreSQL, зроблений правильно. використовує etcd, consul або ZooKeeper як сховище інформації про кластер. Такого сховища, яке віддаватиме всім, хто запитує, наприклад, який зараз лідер, ту саму інформацію — незважаючи на те, що у нас все розподілене, — щоб не було split brain'а. Плюс, у нас був для нього.
Взагалі потреба в auto failover у компанії з'явилася після міграції з внутрішнього залізного дата-центру в хмару. Хмара була заснована на власному рішенні PaaS (Platform-as-a-Service). Воно Open Source'не, але щоб його підняти, треба було сильно попрацювати. Називалося .
Спочатку ніякого Kubernetes не було. Точніше, коли розгорталося власне рішення, K8s вже був, але настільки сирим, що для production годився. Це був, на мою думку, 2015 чи 2016 рік. До 2017 року Kubernetes став більш-менш зрілим — виникла потреба міграції туди.
І ми вже мали Docker-контейнер. Була PaaS, яка використовувала Docker. Чому б не спробувати K8s? Чому не написати свій оператор? Мурат Кабілов, який прийшов до нас з Авіто, розпочав це як проект із власної ініціативи — «пограти», — і проект «злетів».
Але взагалі я хотів розповісти про AWS. Чому там був історично код, пов'язаний з AWS…
Коли ви запускаєте щось у Kubernetes, треба розуміти, що K8s це такий work in progress. Він постійно розвивається, покращується і періодично навіть ламається. Потрібно стежити уважно за всіма змінами в Kubernetes, потрібно бути готовим у разі чого поринути в нього і дізнатися, як працює в деталях – можливо, більше, ніж вам хотілося б. Це, в принципі, будь-яка платформа, на якій ви запускаєте свої БД…
Отже, коли ми робили оператор, у нас був Postgres, який працював із зовнішнім томом (у даному випадку – EBS, оскільки ми працювали в AWS). База даних зростала, в якийсь момент потрібно зробити resize: наприклад, початковий розмір EBS - 100 Тб, база доросла до нього, тепер хочемо зробити EBS 200 Тб. Як? Допустимо, можна зробити dump/restore на новий інстанс, але це довго і з простоєм.
Тому хотілося такий resize, який збільшуватиме розділ EBS'а і потім говорити файловій системі використовувати новий простір. І ми це зробили, але в той час у Kubernetes не було ніякого API для операції resize. Оскільки ми працювали на AWS, написали код для його API.
Ніхто не заважає зробити те саме для інших платформ. В операторі немає зав'язки, що його можна запустити тільки на AWS, а на решті він працювати не буде. Загалом, це Open Source-проект: якщо хтось хоче прискорити появу використання нового API – ласкаво просимо. Є , pull-запити - команда Zalando намагається досить оперативно на них реагувати та просувати оператор. Наскільки знаю, проект в Google Summer of Code та інших схожих ініціативах. Zalando над ним дуже активно працює.
PS Бонус!
Якщо вас цікавить тема PostgreSQL та Kubernetes, то звертаємо також увагу, що минулого тижня відбувся наступний Postgres-вівторок, де з Миколою спілкувався Олександр Кукушкін із Zalando. Відео з нього доступне .
PPS
Читайте також у нашому блозі:
- «»;
- «»;
- «»;
- «».
Джерело: habr.com