В края на миналата година се състоя поредно пряко предаване на руската PostgreSQL общност , в рамките на което съоснователят й Николай Самохвалов обсъди с техническия директор на „Фланта“ Дмитрий Столяров тази СУБД в контекста на Kubernetes.
Публикуваме стенограмата на основната част от тази дискусия, а на е публикувано пълното видео:
Бази данни и Kubernetes
НС: Няма да говорим днес за VACUUM и CHECKPOINT’и. Искам да поговорим за Kubernetes. Знам, че имаш много опит. Гледал съм твоите видеа и някои дори съм преглеждал отново... Нека да започнем направо: защо вообще Postgres или MySQL в K8s?
ДС: Няма еднозначен отговор на този въпрос и не може да има. Но всъщност става въпрос за простота и удобство… потенциално. Всеки иска managed услуги.
НС: Както , само че при себе си?
ДС: Да: за да е като RDS, само че навсякъде.
НС: „Навсякъде“ — това е добър коментар. В големи компании всичко е разположено на различни места. А защо, ако това е голяма компания, да не се вземе готово решение? Например, Nutanix имат свои разработки, а други компании (VMware…) предлагат същото „RDS, само че при себе си“.
ДС: Но говорим за конкретна реализация, която ще работи само при определени условия. А ако става въпрос за Kubernetes, тук има огромно разнообразие от инфраструктура (която може да бъде в K8s). Всъщност това е стандарт за API към облака…
НС: Освен това е и безплатно!
ДС: Това не е толкова важно. Безплатността е важна за не много голям сегмент от пазара. Важно е нещо друго… Вероятно си спомняш доклада „»?
НС: Да.
ДС: Разбрах, че той беше възприет много противоречиво. Част от хората помислиха, че казвам: „Ребята, давайте да пуснем всичките бази данни в Kubernetes!“, а други решиха, че това всичкото е ужасно велосипеди. А аз всъщност исках да кажа нещо съвсем различно: „Вижте какво се случва, какви проблеми има и как могат да се решават. Сега да се премине към бази в Kubernetes? Производствено? Е, само ако харесвате… да се занимавате с определени неща. Но за 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, отгоре на SСД. Преместихме я в и сега можем да я прехвърляме от машина на машина.
НС: Бази с такъв размер, до 100 Гб, на добри дискове и при добра мрежа могат да се прехвърлят за няколко минути, нали? Скорост от 1 Гб в секунда — това вече не е екзотика.
ДС: Да, за линейна операция това не е проблем.
НС: Добре, за prod трябва само да мислим. А ако разглеждаме Kubernetes за не-prod обкръжения — как да го направим? Виждам, че в Zalando , в Crunchy , има и други варианти. И има — това е нашият добър познат Алваро от Испания: те всъщност правят не просто , а цял дистрибутив (), който освен самия Postgres, ще включва и бекъп, прокси Envoy…
ДС: Envoy за какво? За балансиране точно на трафика на Postgres?
НС: Да. Тоест, те го виждат така: ако вземеш Linux дистрибуция и ядрото, обикновеният PostgreSQL е ядрото, а те искат да създадат дистрибуция, която ще бъде приятелска към облаците и ще работи в Kubernetes. Те свързват компоненти (бекъпи и т.н.) и ги настройват, за да работят добре.
ДС: Много яко! По същество това е софтуер, за да направиш своя managed Postgres.
НС: При Linux дистрибуциите винаги има проблеми: как да се направят драйвери, за да се поддържа цялото хардуер. А тяхната идея е, че те ще работят в Kubernetes. Знам, че в оператора Zalando наскоро видяхме обвързване с AWS и това вече не е много добре. Не би трябвало да има обвързване с конкретна инфраструктура — какъв е смисълът тогава?
ДС: Не знам в каква конкретна ситуация е обвързан Zalando, но в Kubernetes в момента хранилището е направено така, че не може да се направи генерален (generic) бекъп на диска. Н Recently inserted sections of text are usually in holidays and weekends — but they often cause media to get free for weekend bags. — направиха възможност за моментни снимки, но къде е реализирана? Честно, все още е толкова незряло… Пробваме CSI върху AWS, GCE, Azure, vSphere, но щом започнеш да го използваш, ясно е, че все още не е готово.
НС: Затова понякога се налага да се обвързваш с инфраструктурата. Мисля, че все още сме в ранна фаза — проблеми с растежа. Въпрос: какво би посъветвал новаците, които искат да опитат PgSQL в K8s? Кой оператор, може би?
ДС: Проблемът е, че Postgres за нас е 3%. Имаме още много софтуер в Kubernetes, няма да изброявам всичко. Например, Elasticsearch. Операторите — много: някои се развиват активно, други — не. Ние си съставихме изисквания, какво трябва да има в оператора, за да го приемем сериозно. Операторът именно за Kubernetes — не в „оператор, за да правиш нещо в условията на Amazon“… По факту ние използваме доста масово (= почти при всички клиенти) единствен оператор — (скоро ще публикуваме статия и за него).
НС: А за MySQL нямате ли? Знам, че Percona… тъй като те сега се занимават и с MySQL, и с MongoDB, и с Postgres, те трябва да направят някакъв универсален инструмент: за всички бази, за всички облачни доставчици.
ДС: Не успяхме да разгледаме операторите за MySQL. В момента това не е нашият основен фокус. MySQL работи нормално в самостоятелен режим. Защо ни е оператор, ако просто можем да стартираме базата данни… Можем да стартираме Docker контейнер с Postrges или можем да го направим по-просто.
НС: И това беше въпрос. Напълно без оператор?
ДС: Да, 100% от нашия PostgreSQL е стартиран без оператор. За сега е така. Активно използваме оператор за Prometheus и Redis. Имаме планове да намерим оператор за Elasticsearch — там
БД за тестване в Kubernetes
НС: Нека преминем към темата за тестването. Как да разгръщаме промени в базата — от гледна точка на DevOps перспективата. Има микросервизи, много бази, постоянно нещо се променя. Как да осигурим нормален CI/CD, за да е всичко в ред от страна на СУБД? Какъв е твоят подход?
ДС: Няма единствен отговор. Има няколко параметъра. Първият е размерът на базата, която искаме да разгръщаме. Ти спомена, че в компаниите по различен начин подхождат към това да имат копие на prod-базата на dev и stage.
НС: А при условията на GDPR, мисля, че там подходът е все по-внимателен… Мога да кажа, че в Европа вече започнаха да налагат глоби.
ДС: Но често може да се напише софтуер, който прави дъмп от production и го обфускира. Получават се prod данни (snapshot, дъмп, бинарна копия…), но те са анонимизирани. Вместо това могат да бъдат и скриптове за генериране: това могат да бъдат фикстури или просто скрипт, който генерира голяма база. Проблемът е: колко време отнема създаването на основния образ? И колко време отнема разгръщането му на нужното околство?
Пристигнахме до схема: ако клиентът разполага с фикстурен набор данни (минимална версия на базата), по подразбиране ги използваме. Ако става въпрос за review околства, когато сме създали клон, разгръщаме екземпляр на приложението - там разгръщаме малка база. , когато всеки ден (нощем) правим дъмп от продукцията и създаваме на неговата основа 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?
НС: Да, понякога наистина е нужно много памет — това е нормално. Но ето един пример от живота. На продукционната машина имаме 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. Там секундите ще бъдат различни (по-бавни), но данните, които наистина Sчитаме, и самите планове (какви 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’и и да направиш мини тест. За бързо получаване на доказателство за концепция, за да видиш, че приложението работи в Kubernetes, без да отделяш много машини за това. Има Minikube, нали?
ДС: Мисля, че този случай — разгръщането на един възел — е изцяло за локална разработка. Или някакви проявления на такъв модел. Има , има , . Отиваме към това, че ще използваме Kubernetes IN Docker. В момента започнахме да работим с него за тестове.
НС: Преди мислех, че това е опит за опаковане на всички pod’и в един Docker образ. Но се оказа, че става въпрос за нещо съвсем различно. Във всеки случай там са отделни контейнери, отделни pod’и — просто в Docker.
ДС: Да. И там е направена доста забавна имитация, но смисълът е такъв… Имаме утилита за деплой — . Искаме в нея да направим режим — условно werf up: „Създай ми локален Kubernetes“. И след това да стартираме условно werf follow. Тогава разработчикът ще може да прави корекции в IDE, а в системата ще върви процес, който вижда промените и пренарежда образите, повторно ги деплойва в локалния K8s. Това е начинът, по който искаме да решим проблема с локалната разработка.
Снапшоти и клониране на БД в реалностите на K8s
НС: Ако се върнем към copy-on-write. Забелязах, че облаците също имат снапшоти. Те работят по различен начин. Например в GCP: имаш много терабайтен инстанс на източния бряг на САЩ. Правиш периодично снапшоти. Създаваш копие на диска от снапшота на западния бряг — след няколко минути всичко е готово, работи много бързо, само кеша трябва да се запълни в паметта. Но тези клони (снапшоти) — са за да се 'provision' нов том. Това е страхотно, когато трябва да създадеш много инстанси.
А за тестовете, мисля, че снапшотите, за които говориш в 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, казваха нещо подобно:
„Отидете в управлявани услуги и ги използвайте, не стартирайте БД в 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). Базата данни нарастваше, в един момент беше необходимо да направим 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 активно работи по него.
P.S. Бонус!
Ако се интересувате от темата PostgreSQL и Kubernetes, имаме също така информация, че миналата седмица се проведе следващият Postgres-вторник, на който Николай обсъди с Александър Кукушкин от Zalando. Видеото от него е достъпно .
P.P.S.
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «».
Източник: habr.com
