В края на миналата година се проведе поредно живо предаване на руското PostgreSQL общество , в рамките на което неговият съосновател Николай Самохвалов говори с техническия директор на „Фланта“ Дмитрий Столяров за тази СУБД в контекста на Kubernetes.
Публикуваме стенограмата на основната част от тази дискусия, а на е публикувано пълното видеозапис:
Бази данни и Kubernetes
НС: Днес няма да говорим за VACUUM и CHECKPOINTи. Искаме да говорим за Kubernetes. Знам, че имаш много години опит. Гледал съм твоите видеа и дори съм преглеждал някои от тях на части... Нека да отидем направо на въпроса: защо изобщо Postgres или MySQL в K8s?
ДС: Няма еднозначен отговор на този въпрос. Но всъщност, това е простота и удобство... потенциални. Все пак всички искат управляеми услуги.
НС: Както , само че при себе си?
ДС: Да: така, както RDS, само че навсякъде.
НС: „Навсякъде“ — това е добро наблюдение. В големите компании всичко е разположено на различни места. А защо тогава, ако това е голяма компания, да не се вземе готово решение? Например, Nutanix има свои разработки, а други компании (VMware…) — също „RDS, само че при себе си“.
ДС: Но говорим за конкретна реализация, която ще работи само при определени условия. А когато става дума за Kubernetes, тук има огромно разнообразие от инфраструктури (които могат да бъдат в K8s). По същество това е стандарт за API към облака...
НС: И е безплатно!
ДС: Това не е толкова важно. Безплатността е важна за не толкова голям сегмент от пазара. Важно е нещо друго... Сигурно си спомняш доклада „»?
НС: Да.
ДС: Разбрах, че е възприет много неоднозначно. Част от хората помислиха, че казвам: «Хайде, да караме всички БД в Kubernetes!», — а други решиха, че това са ужасни велосипеди. А всъщност исках да кажа нещо съвсем различно: «Вижте какво става, какви проблеми съществуват и как могат да се решават. Сегашната среда за работа с бази данни в Kubernetes? Производствена? Е, само ако обичате... да се занимавате с определени неща. А за dev'а — мога да кажа, че препоръчвам. За dev'а е много важна динамичността на създаването/изтриването на среди».
НС: Когато казваш dev', имаш предвид всички среди, които не са prod? Staging, QA...
ДС: Ако говорим за perf-стендо, то май вече няма, защото там изискванията са специфични. Ако говорим за особени случаи, където на staging е необходима много голяма БД, също не мисля… Ако това е статична среда с дълъг живот, каква полза има от това, че базата е в K8s?
НС: Никаква. Но къде виждаме статични среди? Статичната среда остарява утре.
ДС: Staging може да бъде статичен. Имаме клиенти...
НС: Да, и аз имам. Голям проблем е, ако имаш база от 10 Тб, а staging — 200 Гб...
ДС: Имам много интересен случай! На staging се намира продукционната база, в която се правят промени. И има бутон: «изпрати в продукция». Тези промени — делтите — се добавят (мисля, че просто синхронизират по API) в продукцията. Това е много екзотичен вариант.
НС: Видях стартъпи в Долината, които все още са в RDS или дори в Heroku — това са истории от преди 2-3 години — и те изтеглят дамп на лаптопа си. Защото базата е само 80 Гб, а на лаптопа има място. После купуват дискове на всеки, за да имат по 3 бази, за различни разработки. И така става. Също така съм виждал, че не се страхуват да копират продукционни данни в staging — това много зависи от компанията. Но съм виждал и хора, които много се страхуват, и често не им стига времето и ръцете. Но преди да преминем към тази тема, искам да чуя за Kubernetes. Правилно ли разбирам, че в продукция все още няма у никого?
ДС: Имаме малки бази в продукция. Става дума за обеми от десетки гигабайти и некритични услуги, за които беше мързеливо да правим реплики (да и такава необходимост нямаше). И при условие, че под Kubernetes има нормално хранилище. Тази база работеше на виртуална машина — грубо казано в VMware, отгоре на СХД. Преместихме я в и сега можем да я прехвърляме от машина на машина.
НС: Бази от такъв размер, до 100 Гб, на добри дискове и при добра мрежа могат да се разпределят за няколко минути, нали? Скорост от 1 Гб в секунда — това вече не е екзотика.
ДС: Да, за линейна операция това не е проблем.
НС: Окей, за продукцията трябва само да мислим. А ако разглеждаме Kubernetes за не-продуктови среди — как да направим? Виждам, че в Zalando , в Crunchy , има и други опции. И има — нашият добър познат Алваро от Испания: те не правят просто , а цял дистрибутив (), в който освен самия Postgres, ще вкарат и бекъп, прокси Envoy…
ДС: Envoy за какво? За балансировка точно на трафика на Postgres?
НС: Да. Тоест, те го виждат така: ако вземеш Linux дистрибуция и ядрото, обикновеният PostgreSQL е ядрото, а те искат да направят дистрибуция, която да е дружелюбна към облаците и да работи в Kubernetes. Сглобяват компоненти (бекъпи и т.н.) и настройват, така че да работят добре.
ДС: Много готино! По същество това е софтуер, за да направиш собствен managed Postgres.
НС: В Linux дистрибуциите постоянно има проблеми: как да направиш драйвери, така че да се поддържат всичките хардуерни компоненти. А те имат идеята, че ще работят в Kubernetes. Знам, че в оператора Zalando наскоро видяхме завързване с AWS и това вече не е много добре. Няма как да има зависимост от конкретна инфраструктура — какъв е смисълът тогава?
ДС: Не знам, в каква точно ситуация е завързан Zalando, но в Kubernetes в момента сториджът е направен така, че не може да се вземе дисков бекъп по generic начин. Н Recently в стандарта — в последната версия — направиха възможност за снимки, но къде е реализирана? Честно казано, все още е толкова неузрял… Опитваме CSI върху AWS, GCE, Azure, vSphere, но веднага щом започнеш да го използваш, се вижда, че все още не е готово.
НС: Затова понякога трябва да се завързваш за инфраструктурата. Мисля, че все още продължава ранната фаза — проблеми с растежа. Въпросът е: какво би посъветвал начинаещи, които искат да опитат PgSQL в K8s? Какъв оператор, може би?
ДС: Проблемът е, че Postgres за нас е 3%. Имаме и много дълъг списък с различен софтуер в Kubernetes, дори няма да изброявам всичко. Например, Elasticsearch. Операторите — много: някои се развиват активно, други — не. Ние съставихме изисквания, какво трябва да има в оператора, за да го приемем на сериозно. В оператора именно за Kubernetes — не в „оператор, за да правиш нещо в условията на Amazon“… Фактически, ние достатъчно масово (= почти при всички клиенти) използваме единствения оператор — (скоро ще публикуваме статия и за него).
НС: А за MySQL също ли няма? Знам, че Percona… тъй като те сега се занимават и с MySQL, и с MongoDB, и с Postgres, те трябва да направят някакъв универсален вариант: за всички бази, за всички облачни доставчици.
ДС: Не успяхме да разгледаме операторите за MySQL. Това в момента не е основният ни фокус. MySQL функционира добре в самостоятелен режим. Защо ни е оператор, ако можем просто да стартираме базата данни… Можем да стартираме Docker контейнер с Postgres, а можем и по-обикновено.
НС: Имаше и такъв въпрос. Възможно ли е изцяло без оператор?
ДС: Да, ние имаме 100% PostgreSQL стартиран без оператор. Засега така е. Активно използваме оператора за Prometheus и за Redis. Планираме да намерим оператор за Elasticsearch — той е най-належащ, защото искаме да го инсталираме във 100% от случаите в Kubernetes. Както искаме да направим MongoDB винаги да се инсталира в Kubernetes. Имаме определени желания — усещането е, че в тези случаи можем да направим нещо. А за Postgres дори не сме разглеждали. Знаем, разбира се, за съществуването на различни опции, но фактически сме в самостоятелен режим.
База данни за тестване в Kubernetes
НС: Нека преминем към темата за тестването. Как се разгръщат промените в базата — от гледна точка на DevOps перспектива. Има микросервизи, много бази, постоянно нещо се променя. Как да осигурим нормален CI/CD, така че от страната на СУБД всичко да е наред. Какъв е твоят подход?
ДС: Не може да има единствен отговор. Има няколко параметъра. Първият е размерът на базата, която искаме да разгръщаме. Ти сам спомена, че в компаниите отношенията към копирането на prod-базата на dev и stage са различни.
НС: А в условията на GDPR, мисля, те стават все по-внимателни... Мога да ти кажа, че в Европа вече започнаха да налагат глоба.
ДС: Но в много случаи е възможно да се напише софтуер, който прави дамп от продукцията и го обфускира. Получават се prod-данни (снапшот, дамп, бинарна копия…), но те са анонимизирани. Вместо това може да има и скриптове за генериране: това могат да бъдат фикстури или просто скрипт, който генерира голяма база. Проблемът е какво: колко време отнема създаването на базов образ? И колко време отнема да го разгрънем в нужната среда?
Стигнахме до схемата: ако клиентът има фикстурен набор от данни (минимална версия на базата), по подразбиране ги използваме. Ако става въпрос за review-среда, когато създаваме branch, имаме разгрънат екземпляр на приложението — ние разгръщаме малка база там. Но се получи добре и , когато от production-a веднъж на ден (през нощта) правим дамп и събираме на базата на него Docker-контейнер с PostgreSQL и MySQL с тези заредени данни. Ако от този образ трябва да развернем базата 50 пъти, това става доста лесно и бързо.
НС: Просто чрез копиране?
ДС: Данните се съхраняват директно в Docker образа. Т.е. имаме готов образ, да кажем 100 Гб. Благодарение на слоевете в Docker можем бързо да разгръщаме този образ необходимия брой пъти. Методът е прост, но работи добре.
НС: След като тествате, той се променя вътре в Docker, нали? Copy-on-write вътре в Docker — изхвърляме и започваме отначало, всичко е наред. Чудесно! И вие вече го използвате активно?
ДС: Отдавна.
НС: Ние се занимаваме с много подобни неща. Само че ние не използваме Docker-ското copy-on-write, а нещо друго.
ДС: То не е универсално. А Docker-ното работи навсякъде.
НС: По принцип да. Но и ние имаме модули, можем да направим различни модули и да работим с различни файлови системи. Тук е моментът. Ние от страната на Postgres гледаме на всичко това по различен начин. Сега погледнах от страната на Docker и видях, че при вас всичко работи. Но ако базата е огромна, например 1 Тб, тогава всичко става бавно: и операциите през нощта, и вмъкването на всичко в Docker… А ако вмъквам 5 Тб в Docker… Или всичко е наред?
ДС: Каква разлика има: това са просто блобове, просто битове и байтове.
НС: Разликата е такава: правите ли го през дамп и възстановяване?
ДС: Въобще не е задължително. Методите за генериране на този образ могат да бъдат различни.
НС: За някои клиенти направихме така, че вместо редовно генериране на основния образ, ние го поддържаме постоянно актуален. По същество той е реплика, но данните не идват директно от мастера, а през архив. Бинарен архив, където 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. Такъв подход е много специфичен, не е генеричен. Вторият — Kubernetes (и всичко, към което сега се стремят облачните технологии) предполага множество възли, а тези възли са ефимерни. А в твоя случай това е stateful, персистентен възел. Тези неща у мен предизвикват противоречия.
НС: Първо — съгласен, това е чисто история на Postgres. Мисля, че ако имаме някакъв direct IO и буферен пул, почти под всичката памет, такъв подход не би сработил — плановете ще бъдат различни. Но за момента работим само с Postgres и не мислим за другите.
За Kubernetes. Самият ти навсякъде разказваш, че нашата база е персистентна. Ако инстансът падне, най-важното е да запазим диска. Ето, и нашата платформа е в Kubernetes, а компонентът с Postgres е отделен (въпреки че и той веднъж ще бъде там). Затова е така: инстансът падна, но ние запазихме неговия PV и просто го свързахме към друг (нов) инстанс, все едно нищо не се е случило.
ДС: От моя гледна точка, създаваме pod-ове в Kubernetes. K8s е еластичен: узлите се поръчват сами според нуждата. Задачата е просто да създадем pod и да кажем, че му трябват X ресурси, а след това K8s сам ще се справи. Но поддръжката на хранилища в Kubernetes все още е нестабилна: в , в (този релийз излезе преди седмици назад) тези функции стават само бета.
След полгода-година — ще стане по-или по-малко стабилно, или поне така ще бъде обявено. Тогава възможността за snapshot и resize вече напълно решава вашата задача. Защото имате база. Да, тя може да не е много бърза, но скоростта зависи от това, какво е „под капака“, защото някои реализации могат да правят копиране и copy-on-write на ниво дискова подсистема.
НС: Тук трябва и всички двигатели (Amazon, Google…) да успеят да започнат да поддържат тази версия — за това също е необходимо време.
ДС: Все още не ги използваме. Използваме своето.
Локално разработване под Kubernetes
НС: Случвало ли ти се да имаш такава нужда, когато искаш на едно устройство да стартираш всички pod-ове и да направиш малко тестване. За бързо да получиш доказателство за концепция, да видиш, че приложението работи в Kubernetes, без да отделяш много устройства за това. Има Minikube, нали?
ДС: Сигурно е, че този случай — развиването на един възел — е изцяло за локално разработване. Или за някакви прояви на този модел. Има , има , . Насочваме се към използването на Kubernetes В Docker. Сега започнахме да работим с него за тестове.
НС: По-рано мислех, че това е опит да се обгърнат всички pod-ове в един Docker образ. Но се оказа, че става въпрос за нещо съвсем различно. Въпреки това, там има отделни контейнери, отделни pod-ове — просто в Docker.
ДС: Да. И там е направена забавна имитация, но идеята е следната… Имаме инструмент за деплой — . Искаме в него да направим режим — условно werf up: «Стартирай ми локален Kubernetes». И след това да стартираме условен werf follow. Тогава разработчикът може да редактира в IDE, а в системата работи процес, който вижда промените и пресобира образите, деплойва ги в локалния K8s. Така искаме да опитаме да решим проблема с локалната разработка.
Снапшоти и клониране на БД в реалностите на K8s
НС: Ако се върнем към copy-on-write. Забелязах, че облаците също имат снапшоти. Те работят по различен начин. Например, в GCP: имаш мулти-терабайтен инстанс на източното крайбрежие на САЩ. Правиш периодично снапшоти. Пускаш от снапшота копия на диска на западното крайбрежие — след няколко минути е готово, работи много бързо, просто кешът трябва да се запълни в паметта. Но тези клони (снапшоти) — за да за’про-визионираш нов том. Това е страхотно, когато трябва да създадеш много инстанси.
А за тестове, ми се струва, че снапшотите, за които говориш в Docker или които аз обсъждам в ZFS, btrfs и дори LVM… — те всъщност позволяват на едно устройство да не генерираш нови данни. В облака ще плащаш за тях всеки път и ще чакаш не секунди, а минути (а в случай на , вероятно, и часове).
Вместо това можеш за секунда-две да получиш тези данни, да проведеш теста и да изхвърлиш. Тези снапшоти решават различни задачи. В първия случай — за да се мащабираш и да получиш нови реплики, а във втория — за тестове.
ДС: Не съм съгласен. Да направим нормално клониране на томове — това е задача на облака. Не съм разглеждал тяхната реализация, но знам как го правим ние на самата техника. Имаме Ceph, в него може да се каже на всеки физически том () clone и за десетки милисекунди да получим втори том с идентични характеристики, и т.н. Трябва да разберем, че там има хитър copy-on-write. Защо облака не прави също така? Уверен съм, че те така или иначе се опитват да го направят.
НС: Но на тях все пак ще им отнеме секунди, десетки секунди, за да стартират инстанс, да го настроят с Docker и т.н.
ДС: Защо непременно да се стартира цял инстанс? Ние имаме инстанс с 32 ядра, с 16... и в него влизат няколко — например, четири. Когато поръчаме петия, ще се стартира инстанс, а след това той ще бъде изтрит.
НС: Да, интересно, в Kubernetes се получава друга история. Нашата БД не е в K8s, а е един инстанс. Въпреки това, за клониране на многотерабайтна база отнема не повече от две секунди.
ДС: Това е страхотно. Но мой първоначален аргумент е, че това не е обобщено решение. Да, то е страхотно, но е валидно само за Postgres и само на една възел.
НС: То е валидно не само за Postgres: това, което описах, ще работи само в него. Но ако не се притесняваме за плановете, а просто имаме нужда от всички данни за функционално тестване, тогава това подхожда за всяка СУБД.
ДС: Много години назад правихме подобно на LVM-снапшоти. Това е класика. Такава практика беше много активно използвана. Просто stateful-узлите са трудна работа. Защото не трябва да ги поваляме, винаги трябва да помним за тях...
НС: Не виждаш ли тук някаква възможност за хибрид? Да речем, stateful — това е pod, който работи за няколко души (много тестери). Имаме един том, но благодарение на файловата система клоновете — локални. Ако pod падне, дискът остава — pod ще се стартира отново, ще отчете информацията за всички клони и ще възстанови всичко, и ще каже: „Ето вашите клонове на тези портове, работете с тях нататък“.
ДС: Технически това означава, че в рамките на Kubernetes това е един pod, в който стартираме много Postgres’и.
НС: Да. Има лимит: да кажем, че едновременно с него работят не повече от 10 души. Ако трябва 20 — ще стартираме втори такъв pod. Напълно е възможно да го клонираме, получавайки втори пълен том, на който ще има същите 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 е в постоянен процес на развитие. Той непрекъснато се подобрява и понякога дори се разпада. Трябва да следите внимателно всички промени в Kubernetes, да сте готови в случай на необходимост да се задълбочите и да разберете как работи в детайли — вероятно повече, отколкото бихте искали. Това важи принципно за всяка платформа, на която стартирате вашите БД...
Така че, когато правихме оператора, имахме Postgres, който работеше с външен том (в този случай — EBS, тъй като работехме в AWS). Базата данни растеше, в определен момент се наложи да направим увеличение на размера: например, първоначалният размер на EBS — 100 Тб, базата достигна до него, сега искаме да направим EBS на 200 Тб. Как? Да приемем, че можем да направим dump/restore на нов инстанс, но това е бавно и с престой.
Затова искахме такова увеличение, което да увеличи раздела на EBS и след това да извести файловата система да използва новото пространство. И го направихме, но тогава Kubernetes нямаше никакво API за операция по увеличаване на размера. Тъй като работехме на AWS, написахме код за неговото API.
Никой не пречи да направи същото за други платформи. В оператора няма завръзка, че може да бъде стартиран само на AWS, а на всичко друго няма да работи. В принцип, това е Open Source проект: ако някой иска да ускори появата на новото API — заповядайте. Има , pull-запросите — екипът на Zalando се стреми доста бързо да реагира на тях и да напредва с оператора. Понастоящем знам, че проектът в Google Summer of Code и в някои подобни инициативи. Zalando работи върху него много активно.
P.S. Бонус!
Ако се интересувате от темата PostgreSQL и Kubernetes, също така отбелязваме, че миналата седмица се проведе следващият Postgres-четвъртък, където с Николай разговаряше Александър Кукушкин от Zalando. Видео от него е налично .
P.P.S.
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «».
Източник: habr.com
