Мб кому пригодится detailed tutorial on how to deploy an HA Kubernetes Cluster inside an VPC on AWS..... https://www.youtube.com/watch?v=saXjuWG4PeU

есть 3 реплики, и каждая должна знать список

Реплика чего и какой список?

вот этого ,наприме рhttps://hub.docker.com/r/erlio/docker-vernemq/ там один из вариантов клатеризации - discovery node., т.е. нужно передать адресок первой ноды.

Он только айпи принимает?

Имена не может?

Он только айпи принимает?

можно порпобовать с именем пока думаю должно сработать

Для этого есть тип сервиса хендлес

Для этого есть тип сервиса хендлес

Это доп. сервис? Или тип моего сервиса должен быть таким, вс смысле

Sometimes you don’t need or want load-balancing and a single service IP. In this case, you can create “headless” services by specifying "None" for the cluster IP (spec.clusterIP).

Это тип сервиса

ок

хендлес != headleass ?

Три пода, на каждый свой сервис с типом None

хендлес != headleass ?

Похуй, хоть эйпл

Как мне это поможет? Как они найдут друг друга? единственный clusterIP будет типа дискавери?

а между собой у них что, нат?

Похуй, хоть эйпл

Whaaat? )

Как мне это поможет? Как они найдут друг друга? единственный clusterIP будет типа дискавери?

Я же выше написал по сервису на каждый под

Пример можно найти по зукипер и стейтфул сервису

Там как раз этот тип сервиса используется

Whaaat? )

Это я убогий не стоит обращать внимания

Да. Спасибо. Нашёл ещё по монге похожее

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

Да. Зукиперовская модель вполне. Теперь опять вопрос стораджа

Я так и не дошёл

И надо будет взять тот имидж докеровский и немного переделать

Да возьми локалпатч и забей

Это если не Клауд

Можно просто вольюм дать Куберу создать?

У кубера свой движок для работы с волумами

Я пока этого не понимаю до конца.

Да, я помню.

Можно его попросить создать вольюм на время жизни пода?

Удалён под- умерли данные

я сравниваю с подходом docker compose

Надо доку изучить

Там нюансы

Ну хорошо, начнем с обратного. Чарт Зукипера хочет PersistentVolume support

https://github.com/kubernetes/charts/tree/master/incubator/zookeeper

Это для меня что значит? Нужно как минимум вручную будет создавать вольюмы, да?

вот, например, тип local

Можно темплейт юзать

или hostPath

я более глобально не могу понять подход к локальным вольюмам.

Письку Дашь ебать?

@p8sih вот emptyDir мне подойдет?

я более глобально не могу понять подход к локальным вольюмам.

Я с волумами не разбирался ещё плотно ибо не юзал кубер для стейтфул

Я с волумами не разбирался ещё плотно ибо не юзал кубер для стейтфул

Ну даавай вслух порассуждаем

вот зукипер делает volumeClaimTemplates

как мне подсунуть emptyDir?

Брать Гугл и тестить я тебе не подскажу тут

буду тогд смотреть на emptyDir

Ну судя по всему это то что надо в моем случае

https://kubernetes.io/docs/tasks/configure-pod-container/configure-volume-storage/

и еще спеку рафта

Etcd примет за основу данные большей части после воссоединения, то есть отбросив Стейт меньшей части, и как это отразиься на k8s все таки вопрос

Etcd примет за основу данные большей части после воссоединения, то есть отбросив Стейт меньшей части, и как это отразиься на k8s все таки вопрос

Да просто проебутся изменения которые пришли с меньшей части

Etcd примет за основу данные большей части после воссоединения, то есть отбросив Стейт меньшей части, и как это отразиься на k8s все таки вопрос

господи

не будет никакой меньшей части

кластер в меньшей части не соберется

поэтому не будет оттуда никаких записей

кластер в меньшей части не соберется

Хорошо если так

ERROR: S client not available

в кластере один (1) мастер

он не может избраться в меньшей части кластера

он не может ничего закоммитить, потому что для коммита нужен кворум

кластер в меньшей части не соберется

Кластер из 7 нод распался на 4 и 3 ноды, кластер из 3 нод не выберет себе мастера?

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

Кластер из 7 нод распался на 4 и 3 ноды, кластер из 3 нод не выберет себе мастера?

не выберет.

не выберет.

Это хорошо если так, надо будет потестить

Ну при соблюдении нечетного количества мастеров

N/2 +1

Хорошо

Значит при отсутствии багов все будет ок

Ну при соблюдении нечетного количества мастеров

я надеюсь, etcd все-таки разрабатывают не люди, которые не понимают, что кворум это большинство, а не половина

А как будет поведение, если кластер из 5 нод распался на три, при чем зитпо, по две ноды друг друга не видеть, в одна видит все оставшиеся 4

At least 51% of the cluster must be online — the actual formula is N/2 + 1 — in order for any data to be read or written, to prevent split brain problems

и здесь нет никакого запрета на четное число нод

это нерационально, но не запрещено

А как будет поведение, если кластер из 5 нод распался на три, при чем зитпо, по две ноды друг друга не видеть, в одна видит все оставшиеся 4

Логически когда у нас два кластера из 3 нод

А как будет поведение, если кластер из 5 нод распался на три, при чем зитпо, по две ноды друг друга не видеть, в одна видит все оставшиеся 4

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

Не обин не заработает)

Логически когда у нас два кластера из 3 нод

Это все еще один кластер

Просто тут загвоздка что 4 ноды в попарно не видят друг друга, но все они видят пятую ноду

Идеальный вариант, если эта года была мастером

А если нет, никто в рафте не даёт гарантии что она станет мастером при выборе

Если память не изменяет, то каждая нода сможет стать мастером. Центральная при этом будет служить фейлсейфом от того, чтобы обе ветви этой кардиоиды избрались

Другими словами после разветвления она сможет отдать голос только кому-то одному (включая себя - опять же, если память не изменяет), и кто-то останется без промоутинга

Ну вот я как раз о том, станет ли пятая координатором

Просто тут загвоздка что 4 ноды в попарно не видят друг друга, но все они видят пятую ноду

это автоматически означает что пятая нода видит всех. таким образом пятая нода после цикла голосования станет мастером.

это автоматически означает что пятая нода видит всех. таким образом пятая нода после цикла голосования станет мастером.

Это гарантированное поведение?

время раскопать спеку

это ожидаемое поведение. ни одна другая не сможет стать мастером, потому что не получит подтверждений об этом.

возможно в реализации можно предусмотреть, чтобы ноды имели полную связность на этапе выборов, но в целом для рафта это не обязательно