А вот та diskless штука из доклада, она по какому протоколу до drbd дисков ходит и как знает какой из них активный?

ты действильно считаешь что все должны понимать как работает k8s без понимания зачем он должен работать? и это считать за оффтоп? uhh, well... так и будем клеймить все хайпом и модой, без понимания зачем оно было придумано

Нет, она использует тот же drbd9 и является полноценной репликой, когда дисклесс реплика находится в primary она просто реплицирует изменения на остальные

Так и вижу как инструктор в автошколе на первом занятии: "ты понимаешь зачем машину водить собрался? Насколько осознанный твой выбор в пользу автомобиля против общественного транспорта? Семью возить? Ты уверен, что знаешь для чего институт семьи придуман и взвешенно идёшь этим путем?"

это не относится к экономике выбора, это скорее про то что к тебе приходит покупатель и просит тачилу шобы ездила и шобы таксовать по ночам, а ты ему советуешь фигню расхайпованную тк ты не шаришь за тачки, тебя посадили консультантом потому что ты водишь круто на своей девятке и им почемуто показалось что ты во всем так шаришь, и ты считаешь что это как бы не твои проблемы что ты хуево тачки советуешь, ведь девятку водишь? водишь консультантом тебя поставили? поставили тачки советуешь? советуешь вот только покупатель больше не придет к таким кретинам и другим не посоветует и ты спустя n лет окажешься на бирже труда не понимая почему ваша контора разорилась, наверно потому босс кретин нанимает не пойми кого говоришь ты про своего коллегу который херово тачки в соцсетях продвигал, ведь он не шарит за соцсети, он до этого холодными звонками занимался в другой конторе которая тоже разорилась

Как там на практике перезагрузка сервера с дисками устроена? Оно же должно синхронизировать все пропущенные записи, где то хранится их лог?

@kvaps Спасибо за pull request! Субмурно вопрос получился, надо ответ всё-таки получить. Подскажи, что значит один под на ноду? Как у вас вообще scheduling устроен и что за workload'ы вы вообще в Kubernetes гоняете? Оверселлите ли ресурсы, как используете HPA/VPA?

Под на ноду - это довольно условно, подов на самом деле больше, но как правило мы не видим особого смысла делить нагрузку если нет на то везкой причины. Пример нагрузки: нагруженный веб-сервер (Apache) с кучей клиентских сайтов или база данных с кучей юзеров.

Т.е. multi-tenancy нет?

Мы не предоставляем куб пользователям, мы используем его сами для деплоя наших сервисов.

Ну и вопросы трансграничной передачи данных, когда гостовые средства шифрования нельзя юзать вне рф и иметь костыли тут гост, там обычный ipsec - тот еще колхоз

какой-то везде скептицизм в ру комьюнити по поводу новых технологий, и k8s это "мода", serverless это "хайп" в итоге получаем кучу докладов про то как в очередной раз поставить k8s на bare metal, не понимая что бизнесу это может быть и не нужно, вместо адаптации технологий которые удешевляют процесс итерации бизнеса, в ру комьюнити наоборот удешевляют стоимость хостинга но зато это требует отдельных людей для поддержания этого всего и навешивания кучу мониторингов возможно это потому что найм людей в рф стоит дешевле и это такой процесс "масштабирования", что дешевле нанять тут операторов которые буду мониторить bare metal серваки, вместо того чтобы платить облакам за это все, но не видел еще на докладах стоимость и сравнение того как было и как стало, в основном это обосновывалось "хотелками" и "мы так привыкли"

Ну мы protocol C используем, то есть все операции записи осуществляется синхронно на все девайсы, есть ещё async или semi-sync, в любом случае выключать реплики должно быть без outage. При восстановлении тоже, будет быстрый ресинк и все.

Я тут после товарища с foundationdb погуглил про этот nbd, оказывается живее всех живых штука, вот например есть https://github.com/libguestfs/nbdkit эдакий FUSE но для блочных устройств :)

Если синхронно на все девайсы то выключить ничего нельзя же будет

Я тут после товарища с foundationdb погуглил про этот nbd, оказывается живее всех живых штука, вот например есть https://github.com/libguestfs/nbdkit эдакий FUSE но для блочных устройств :)

Можно, пока хотя бы одна реплика есть живая I/O не остановится

Вот вторая реплика вышла после перезагрузки, она же не может начать подтверждать записи пока не синхронизирует все, что пропустила. Как синхронизация устроена? Без журнала блоков или скажем их версий оно же должно полностью все что есть пересинхронизировать

Кстати насчёт nbd, какая ошибка была бы более ожидаема в случае одновременного подключения экспорта с двух разных хостов? Пока у меня мысль о том чтобы отключить старый хост и слать ему ESHUTDOWN в ответ на все запросы, а новому хосту дать возможность подключения без каких-либо проблем.

В смысле, ты эти отключения на стороне клиента хочешь отрабатывать?

Ага, если например два контейнера пытаются законнектится к одной volume, то только один должен иметь доступ. На каждый запрос отсылается lease token, и клиенты всегда проверяют что тапки все ещё принадлежат им.

Может проще будет запускать в поде два контейнера с одним Emptydir, один контейнер - приложение, второй - суперкроник который выполняет его обновление

Вообще скейлить и на local volumes можно, тот же drain по умолчанию пытается мигрировать поды local volumes. С --force у него это даже получается, главное чтобы приложение умело перереплицировать без даунтайма.

что вы вообще сейчас сказали?..

Парни, нужно заполнять emptyDir определёнными данными перед стартом пода. Это решается initContainer. Но проблема в том, что данные нужно раз в сутки обновлять. Средствами куба это можно решить?

Ребят, а давайте серьёзно поговорим. Только без срача, пожалуйста, я не задаю такой тон дискуссии. Как вы считаете, с точки зрения программирования и архитектуры приложений, на serverless парадигму возможно перейти всем workload'ам? Или место контейнерам всё ещё есть и будет долгие годы? Возможно, вы уже задумывались об этом и можете поделиться мыслями и ссылками?

и вообще, мне кажется что не очень правильно всю инфраструктуру / архитектуру приложения перевеодить во что-то одно типа, о, придумали контейнеры, бежим срочно все упаковывать в контейнеры о, серверлесс, нахуй контейнеры, пишем функции вот с контейнерами тоже. Они тоже не для всего подходят, они хороши для stateless приложений типа сервера, для быстрого деплоя и постоянного обновления, для CI/CD. Это cattle, который immutable и его можно убивать все время но контейнеры не для всего лучшее решение, те же базы данных, файловые и блочные хранилища и весь прочий statefull уже хуже ложится. И это нормально. Почему бы не использовать все по своему назначению, тем более что бд-сервер наверное не так часто выкатывать приходится как приложения вашего бизнеса. У FaaS тоже вполне себе ниша своя, это event-based процессы. Так что мне кажется этот паттерн должен не заменить контейнеры, а гармонично его дополнить

Когда там следующий серверлес митап, надо на нем этот вопрос поднять)

Собираем самостоятельно, там в поставке есть Dockerfile же, все просто

Всем привет, задача: есть EKS кластер в AWS(в одной организации, назовем ее qa-team), есть SSL сертификат(в другой организации, назовем ее root) в ACM (AWS Certificate Manager, экспортировать нельзя, пошарить на другую организацию тоже) Вопрос: можно ли как-то создать ELB(LoadBalancer) в root организации чтобы он как-то балансировал на EKS в qa-team организации?

https://t.me/aws_ru

Есть ли смысл ставить kubernetes, на одном виртуальном сервере, или есть смысл докупуить второй виртуальный сервер? Есть вообще практика деплоя домашних страничек на kubernetes?

Тогда и третий сразу

Может тогда лучше без kubernetes обойтись для pet projects?

Хороший вариант, но если вдруг надо будет масштабироваться - будет чуть меньше боли, если проект сразу пилится под кубер

Хороший вариант, но если вдруг надо будет масштабироваться - будет чуть меньше боли, если проект сразу пилится под кубер

А для одной ноды рекомендутся использовать minikube, но там пометка что не для продакшена? Значит получается для одной ноды в продакшене лучше всё-таки использовать kubeadm, или у кого-то есть другие идеи?

А для одной ноды рекомендутся использовать minikube, но там пометка что не для продакшена? Значит получается для одной ноды в продакшене лучше всё-таки использовать kubeadm, или у кого-то есть другие идеи?

Если просто "нормально делать", то и в куб потом заедет. Нафиг щас время тратить?

А для одной ноды рекомендутся использовать minikube, но там пометка что не для продакшена? Значит получается для одной ноды в продакшене лучше всё-таки использовать kubeadm, или у кого-то есть другие идеи?

у кубовского control plane оверхед такой нехилый, один апи-сервер у тебя только 400Mi памати отожрет

Норм все, @drakmail, ставь kubeadm на single node. Когда время придет - масштабируешься.

Может что-то есть, что бы меньше хавало? Настройка там какая-то, или локальный компьютер сделать мастером и админить им ноду?

etcd не масштабируется же.

Может что-то есть, что бы меньше хавало? Настройка там какая-то, или локальный компьютер сделать мастером и админить им ноду?

С 13й версии все нормально масштабируется. Мастера можно как и воркеры в любой момент добавлять

А какой бюджет на это всё?

вообще ради странички можно зарегаться в GKE и получить 300 баксов на год

А ради второго года что делать?

Кстати, у DO вроде дешёвый куб можно получить

5$ + 15LB

Кстати, у DO вроде дешёвый куб можно получить