« Rev
@kubernetes_ru   460
Fwd »


Anton
и еще спеку рафта
Etcd примет за основу данные большей части после воссоединения, то есть отбросив Стейт меньшей части, и как это отразиься на k8s все таки вопрос
Etki
не будет никакой меньшей части
Sergei
Sergei
кластер в меньшей части не соберется
Sergei
поэтому не будет оттуда никаких записей
Etki
в кластере один (1) мастер
Etki
он не может избраться в меньшей части кластера
Etki
он не может ничего закоммитить, потому что для коммита нужен кворум
Etki
там есть только окно возможностей, когда уже-не-очень-мастер примет запрос, пихнет в лог, но даже не ответит успехом клиенту, потому что кворум не отзовется, но система в целом все равно будет в консистентном состоянии и не сможет вернуть эти данные вне зависимости от того, какой узел опрашивается
Sergei
не выберет.
Anton
Ну при соблюдении нечетного количества мастеров
Anton
N/2 +1
Anton
Хорошо
Anton
Значит при отсутствии багов все будет ок
Etki
Ну при соблюдении нечетного количества мастеров
я надеюсь, etcd все-таки разрабатывают не люди, которые не понимают, что кворум это большинство, а не половина
Anton
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
Etki
и здесь нет никакого запрета на четное число нод
Etki
это нерационально, но не запрещено
Etki
Если кто-то смог собрать нужное количество голосов, он станет мастером. Если никто не сможет, мастера не будет. В протокол вшит забавный функционал, который не позволит одной из частей кластера пропустить чьи-то выборы и затем избраться (при условии сохранения кворума).
Anton
Не обин не заработает)
Etki
Это все еще один кластер
Etki
Если память не изменяет, то каждая нода сможет стать мастером. Центральная при этом будет служить фейлсейфом от того, чтобы обе ветви этой кардиоиды избрались
Etki
Другими словами после разветвления она сможет отдать голос только кому-то одному (включая себя - опять же, если память не изменяет), и кто-то останется без промоутинга
Sergei
это автоматически означает что пятая нода видит всех. таким образом пятая нода после цикла голосования станет мастером.
Etki
время раскопать спеку
Sergei
это ожидаемое поведение. ни одна другая не сможет стать мастером, потому что не получит подтверждений об этом.
Sergei
возможно в реализации можно предусмотреть, чтобы ноды имели полную связность на этапе выборов, но в целом для рафта это не обязательно
Etki
насколько понимаю, пара (1, 2) видит узел (3), поэтому любой из этой связки может получить три из пяти голосов (аналогично для (4, 5))
Sergei
ты что сказать-то хочешь?
Sergei
"нельзя верить алгоритмам поиска консенсуса, потому что в них баги"?
Sergei
ну проверь
Anton
"нельзя верить алгоритмам поиска консенсуса, потому что в них баги"?
Мы рассматриваем случаи без багов, есть текет еткд где все ноды становились мастером
Etki
> In (a) S1 is leader and partially replicates the log entry at index 2. In (b) S1 crashes; S5 is elected leader for term 3 with votes from S3, S4, and itself Короче, тройка может самоопределить судьбу своего суверенитета, выходит что любой узел может стать мастером, но кластер продолжит функционировать всеми пятью нодами только если изберется центральная.
Etki
голос можно отдать только за один узел в одном раунде выборов
Etki
Там есть такое свойство как срок (term). Когда кто-то выпадает, все начинают претендовать на следующий срок (term + 1), и для term + 1 можно отдать только один голос, и отдается он только такому узлу, который успел принять все те обновления от мастера, который принял и текущий узел.
Etki
Таким образом если какая-то запись закоммитилась, она гарантированно останется после переизбрания мастера.
Etki
я сомневаюсь, что выйдет полнее, чем у https://aphyr.com/posts/316-jepsen-etcd-and-consul
Dmitry
я не понимаю, откуда мне в гластере взять rest api
Dmitry
там только 2 порта открываются и те не http
Dmitry
зато тут хотят рест https://kubernetes.io/docs/concepts/storage/storage-classes/#glusterfs
Dmitry
heketi ставить не охота, похоже что должен быть какой-то родной rest
Dmitry
пишут Gluster REST service/Heketi service то есть где-то в гластере есть rest?
Dmitry
то есть надо еще heketi ставить. сюрприз)
Dmitry
бесит. я просто хочу запустить чарты))
Dmitry
а, можно походу создать endpoint и pv вручную. ок
Dmitry
прокатило вроде. heketi, я так понимаю, для динамической магии. оно мне пока не надо.
Dmitry
ну все. пора спать
Dmitry
а, фиг там volumeClaimTemplates все равно storageClass хочет
Dmitry
Попробовать manual что ли
Dmitry
Ааа. Я получается класс могу вообще любой статическому диску задать. Так что ли. Ладно. Теперь точно спать
sherzod
Кто-нибудь делал подключение на нестандартные порты - мультиплексирование по разным портам на кубере? Задача такая, есть внешний айпи, надо в зависимости от того на какой порт идёт обращение перекидывать на разные службы
sherzod
Сейчас ингресс позволяет только по http path мультиплексировать
sherzod
А у меня даже не http
Vladimir
nginx-ingress умеет tcp/udp проксировать
sherzod
спасибо, щас буду вникать
Vitalii
Как kubelet общается с мастером? Мастер обращается к kubelet и говорит что делать или kubelet ходит к мастеру?
sherzod
спросил в девопсе, здесь тоже спрошу, а кто-нить знает, гугловый ингрес без всяких правил сможет не http трафик прокинуть? просто есть идейка дальше на хапрокси рулить (нужно быстрое решение)
Vitalii
https://kubernetes.io/docs/concepts/architecture/master-node-communication/
спасибо 🙂 заодно еще радок перечитаю Концепт Кубера
Vitalii
Если бы перед вами встала задача развернуть продакшен кластер из 3-х нод мастера, настройки системы балансировки между ними, а так же развертывания N нод с kubelet. Причем все это развернуть на собственных серверах компании, а не где-то в облаке. Какой бы инструмент развертки вы выбрали? Все делать вручную с нуля или kubeadm или что-то другое?
Vitalii
Как в экосистеме кубера принять разворачивать готовые к продакшену кластеры? Т.к. для поиграться есть куча вариантов от миникуба, варганта до развертки на виртуалбоксе ручками на коленке. А вот для продакшена сценариев и тонкостей не встречал пока что.
Dmitry
kubespray? правда он не даёт никаких знаний как это чинить, если поломается...
Vitalii
Вот! В этом и вся беда готовых решений. Ими можно пользоваться только если ты полностью разобрался как они работают и что делают. А в сети почему-то куча вариантов с kubeadm, kubespray и развертыванием парой кнопок в облаке гугла или амазона. Как буд-то ни кто не разворачивает кубер на проде и не описывает решений по развертке, масштабированию, безопасности и самое главное - пониманию как оно работает, чтобы знать как чинить.
Anonymous
Или ansible-playbook
Vitalii
я тоже смотрел на эти решения. Но как сказано выше - пока не изучишь что конкретно и зачем оно делает для установки кластера в прод с таким нельзя.
Vitalii
в истории по ключам: bootkube typhoon kubespray
Спасибо:) Скажи, стоит ли использовать эти инструменты, если не умеешь поднимать кластер руками с нуля на голом железе?
Serega
нужно с чего то начинать. И тестировать.
Serega
Да и не факт что сходу нужно на голое железо. Виртуалки тоже вполне подойдут. Проще эксперементировать.
Vitalii
нужно с чего то начинать. И тестировать.
Ну начинать можно с миникуба.
Serega
начинайте с того, что позволит решить бизнес задачу. И постепенно изучайте инструмент. Серебрянной пули нет, хоть многие ищут. tectonic еще вариант глянуть.
Vitalii
Да и не факт что сходу нужно на голое железо. Виртуалки тоже вполне подойдут. Проще эксперементировать.
Я под голым железом имел голые ОС, не так выразился:) У меня kuberspray не встал на Ubuntu 17.04 или какая там последняя. А конкретно проблема с репо докером была, он не смог его поставить.
Vitalii
начинайте с того, что позволит решить бизнес задачу. И постепенно изучайте инструмент. Серебрянной пули нет, хоть многие ищут. tectonic еще вариант глянуть.
Ну я начал с того, что изучаю компоненты по отдельности и связь между ними. Хочу научиться собирать систему с нуля ручками запуская все демоны и проставляя все параметры, флаги и сертификаты.
Vitalii
Там написано Минимальные дистрибутивы. Точнее я так понял.
« Rev
@kubernetes_ru   460
Fwd »