и я же не просто так задал вопрос об оплате труда

это тебе сюда http://flant.ru они тебе за деньги на русском языке на любые вопросы ответят. и ведь гуглится за 5 минут кто в ру сегменте готов тебе помочь за некоторое колво денег.

@terrifilch тут в группе как раз недавно подобные вопросы были про мультиреджин кластер, и ответы на них тоже были. Но мне не в лом повторить: мультиреджин сингл кластер это верный способ нажить себе проблем. Особенно если не можешь гарантировать коннекшин между реджинами. И кубер - не серебрянная пуля, которая из гавяной архитектуры способна сваять конфекту с названием highavailability, highscalability, highperformance

@terrifilch тут в группе как раз недавно подобные вопросы были про мультиреджин кластер, и ответы на них тоже были. Но мне не в лом повторить: мультиреджин сингл кластер это верный способ нажить себе проблем. Особенно если не можешь гарантировать коннекшин между реджинами. И кубер - не серебрянная пуля, которая из гавяной архитектуры способна сваять конфекту с названием highavailability, highscalability, highperformance

я бы на твоём месте задумался зачем тебе 3 дц.

я бы на твоём месте задумался зачем тебе 3 дц.

воспользуйся для быстрой доставки CDN

вопрос не про реалтайм, это одна сущность, которая синхронно у тебя должна работать в трех локациях, или все-таки разные сущности, которые между собой никак не связаны?

монго плохой выбор для таких задачь. О риалтайме можно забыть.

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

твое предложение?

при таких вводных, кубер кластер в одном реджине с распределением нод по AZ. (Aws\GKE) Базу если не менять - то можно mongomms cloud, если менять то взять что-то из того что предлагает клауд. Если своими силами - то все очень сильно зависит от логики приложения. Таже кассандра не везде пойдет.

делать мультиреджин кластера надо если ты работаешь на глобальный рынок и важна латенси.

приложение пишет или читает из базы?

Всем привет! Кто настраивал мультимастер Kubernetes кластер скажите, правильно ли я понял логику всей схемы. Чтобы поднять мультимастер Kubernetes нужно настроить одну мастер ноду, далее скопировать с нее сертификаты на остальные 2 ноды. Далее, по стандартной схеме, настроить остальные два мастера на оставшихся двух нодах (при этом ключи на них генериться уже не будут, т.к. они есть) и в конце настроить реплику между всеми etcd который пуступает как БД для мастеров. В логическом завершении нужно на четвертой машине настроить баллансировщик (единую точку входа для всех 3-х мастер нод). Все правильно?

Всем привет! Кто настраивал мультимастер Kubernetes кластер скажите, правильно ли я понял логику всей схемы. Чтобы поднять мультимастер Kubernetes нужно настроить одну мастер ноду, далее скопировать с нее сертификаты на остальные 2 ноды. Далее, по стандартной схеме, настроить остальные два мастера на оставшихся двух нодах (при этом ключи на них генериться уже не будут, т.к. они есть) и в конце настроить реплику между всеми etcd который пуступает как БД для мастеров. В логическом завершении нужно на четвертой машине настроить баллансировщик (единую точку входа для всех 3-х мастер нод). Все правильно?

etcd сразу настраивается как единый кластер

так а где настраивается keepalived ? и какая логика с ним получается?

держит один адрес который шарится между серверами. При падении одного - этот адрес зажигается на другом.

@voskobovich есть ещё мнение что в случае мультимастера мастеров должно быть нечётное кол-во из-за (рас)синхронизации состояния. поправьте если я не прав.

никогда с keepalived не работал, но слышал что это за зверь) мне не понятно на какой ноде его запускать?

@voskobovich есть ещё мнение что в случае мультимастера мастеров должно быть нечётное кол-во из-за (рас)синхронизации состояния. поправьте если я не прав.

а большая разница сразу настраивать или в будущем добавить мастеров?

не делал так, обычно сразу кластер поднимал

я планирую 3 ноды))) самый распространенный вариант, да и в доке написано. А можно подробней почему именно нечетное и в сем проблема (рас)синхронизации состояния ?

В случае любого разделения сети формируется новый кластер из оставшихся узлов. Один из вариантов разделения сети - это просто потеря связи между двумя участками кластера, и в таком случае возникает проблема двойного авторитета. Из-за этого та часть, в которой меньшинство, должна потухнуть до воссоединения, а большинство - продолжить работу. Если мы берем нечетное количество нод, скажем пять - большинством является три ноды. Если мы возьмем шесть, то большинством будет четыре ноды - и получается, что вот эта шестая нода не дает нам никакого преимущества, потому что больше двух нод мы потерять все равно не можем.

я правильно понял, что keepalived это тоже кластер из 3 демонов на всех нодах? Но тогда не понятно где же та самая единая точка выхода.

Конкретно в etcd внутри сидит протокол raft, который просто не считает операцию совершенной, пока ее не приняло большинство участников кластера, поэтому там это вообще сразу из коробки (правда с чтениями они один раз все же профакапились, но это пофиксили).

@voskobovich есть ещё мнение что в случае мультимастера мастеров должно быть нечётное кол-во из-за (рас)синхронизации состояния. поправьте если я не прав.

аааа, это функция самого ПО. То есть если ПО умеет соединяться в кластер, то на его уровне и реализуется логика контроля совершенности операции. Например в etcd пришел запрос на запись значения, нода его пишет себе и передает другим. И пока другие не примут и не сохранят у себя то операция не считается завершенной. Так?