вы вообще читали, что я писал

чем проще ты сделаешь тем лучше. одного дц тебе современного даже тиер 2-3 достаточно будет.

разные сервисы на разные континенты

и страны

галактики

cdn само собой

это логично

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

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

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

ПО-ЭТОМУ, я и спросил о консультации

3дц это уход от идиотизма датацентра

облако тоже не панацея

так, давайте на два шага назад

в этих трех дц один и тот же контент, или разный?

там не контент, а сервис который будет генерировать данные для юзеров

при этом реалтайм

cdn для сео не всегда ок

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

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

2 сервиса, 2 сущности, они разибиты на части , можно сказать и микросервисы

база на чем?

mongo

пока что она, в дальнейшем - может поменятся

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

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

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

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

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

ну ок, допустим 3 кластера по местам, вопрос тогда становится в архитектуре для каждого кластера

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

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

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

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

ну кагбе да

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

вот

и я о том же

ну вот и делай несколько отдельных кластеров. Да хоть мультиклауд. Это вообще всё фигня, кроме вопроса синхронизации данных между реджинами.

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

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

пишет и читает

читать может конечно меньше, но писать будет 100%, каждый час и по многу

правда все зависит от аппетита юзера к данным

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

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

Опять же, если данные не нужно синхронизировать между реджинами, то и монга может подойти.

Представлюсь. Я php backend разработчик. Хочу уметь создавать приложения работающие в облаке и легко масштаблируемые. Для этого я изучил Docker и сейчас учу оркестрацию. Выбрал Kubernetes в качестве откестратора. В планах хочу построить protuction HA кластер из 3 мастер нод и N миньйонов, а так же настроить CI\CD приложение через Gitlab CI. Наметил себе путь, а теперь активно курю доки и вкладываю в свою голову знания и понятия. Я из Украины, г Одесса. Про группу узнал из списка каналог на гитхабе и гугла. #whois

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

про логическое завершение: логично использовать keepalived или bgp анонс, а не единую точку отказа.

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

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

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

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

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

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

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

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

еще надо не забыть про флаги leader-elect в контрол плейне

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

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

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

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

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

на всех мастерах

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

в распределенной системе (в данном случае etcd), при четном количестве кворум формируется таким образом, что последний узел становится немного лишним

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

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

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

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

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

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

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

ох, спасибо. В теории понятно. Но каким образом меньшинство тухнет? Например есть 5 нод, одна из них потухла. Что произойдет в системе и кто это контролирует?

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

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

http://img2.ph.126.net/knqvT-s-s-Ap6TGBblmu4g==/6630875351165754278.jpg вот примерно что это такое

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

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

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

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

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

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

типа того, да

http://img2.ph.126.net/knqvT-s-s-Ap6TGBblmu4g==/6630875351165754278.jpg вот примерно что это такое

Я понял логику, но не понял как это спасает от единой точки отказа? Ведь все равно есть VIP который принимает запрос и дальше решает кому его отдать (кто работает сейчас). Т.е. в тако схеме ВИТ и есть точка отказа.

он дублируется

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

Да, примерно так. На самом деле там очень большое пространство для работы и возможностей прострелить ногу, можно почитать серию jepsen у афира, он в процессе объяснения самих инструментов еще и объясняет сам класс возможных проблем.

call me maybe

ERROR: S client not available

Да, примерно так. На самом деле там очень большое пространство для работы и возможностей прострелить ногу, можно почитать серию jepsen у афира, он в процессе объяснения самих инструментов еще и объясняет сам класс возможных проблем.

Спасибо. Мне пока базовые вещи построения HA систем бы освоить) И наконец-то бы поднять хоть какой-то Kubernetis своими руками а не готовыми установщиками ?

один из лучших циклов на эту тему

один из лучших циклов на эту тему

где? )

aphyr.com/tags/jepsen

Так, получается что я все понял правильно кроме того, что баллансировку между нодами делает keepalived. Etcd можно как сразу в кластер соединять, а можно и потом прикрутить реплики.

502 Bad Gateway ?

jepsen.io

Так, получается что я все понял правильно кроме того, что баллансировку между нодами делает keepalived. Etcd можно как сразу в кластер соединять, а можно и потом прикрутить реплики.

etcd можно вообще с одного хоста начинать, увеличить кол-во нод в кластере недолго

https://webcache.googleusercontent.com/search?q=cache:qKqUKdvRHesJ:https://aphyr.com/tags/jepsen+&cd=14&hl=en&ct=clnk&gl=ru&lr=lang_en%7Clang_ru

etcd можно вообще с одного хоста начинать, увеличить кол-во нод в кластере недолго

ну, ты имеешь ввиду начать с одного мастера? а потом по мере надобности добавлять еще?

конечно

ну это так себе практика, но работать будет

если конечно этот самый 1 мастер не сдохнет по пути :)

ну для прода надо сразу поднимать 3 мастера))

не мастера, а инстанса етцд

Ух, нашел про keepalived https://habrahabr.ru/company/netangels/blog/326400/ почитал. Сума сойти какая схема)) но круто что нет точки отказа. Спасибо!

Вопрос: kubectl create -f https://k8s.io/docs/tasks/debug-application-cluster/counter-pod.yaml kubectl logs counter Консоль висит и логов нет, подскажите куда смотреть, что не так может быть?

я так понимаю, что keepalived и установка виртуального ИП делается на мастер нодах, верно?

Вопрос: kubectl create -f https://k8s.io/docs/tasks/debug-application-cluster/counter-pod.yaml kubectl logs counter Консоль висит и логов нет, подскажите куда смотреть, что не так может быть?

Что в дескрайбе пода?

как вариант, вместо keepalived можно на каждом воркере запустить локальный прокси (nginx/haproxy) который будет раскидывать все запросы к апи серверу(ам) (идущие на 127.0.0.1 на воркере)

как вариант, вместо keepalived можно на каждом воркере запустить локальный прокси (nginx/haproxy) который будет раскидывать все запросы к апи серверу(ам) (идущие на 127.0.0.1 на воркере)

вариант!

как вариант, вместо keepalived можно на каждом воркере запустить локальный прокси (nginx/haproxy) который будет раскидывать все запросы к апи серверу(ам) (идущие на 127.0.0.1 на воркере)

честно, ничего не понял)) знаете где сылочку взять для почитать описание схемы?

Что в дескрайбе пода?

# kubectl describe pod counter Name: counter Namespace: default Node: domain/172.27.39.28 Start Time: Fri, 19 Jan 2018 18:32:39 +0300 Labels: <none> Annotations: <none> Status: Running IP: 10.244.0.13 Containers: count: Container ID: docker://7049fcc5911a6c7a5dbe182bc69351e16dbb1d9727f502e6c41dc61d05cfe0fb Image: busybox Image ID: docker-pullable://busybox@sha256:ac2fc418f3348815e68e266a5aa1b60bc522581c96964912560a0baacc4f5c06 Port: <none> Args: /bin/sh -c i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done State: Running Started: Fri, 19 Jan 2018 18:32:57 +0300 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-4pqlv (ro) Conditions: Type Status Initialized True Ready True PodScheduled True Volumes: default-token-4pqlv: Type: Secret (a volume populated by a Secret) SecretName: default-token-4pqlv Optional: false QoS Class: BestEffort Node-Selectors: <none> Tolerations: node.alpha.kubernetes.io/notReady:NoExecute for 300s node.alpha.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 11m default-scheduler Successfully assigned counter to domain Normal SuccessfulMountVolume 11m kubelet, domain MountVolume.SetUp succeeded for volume "default-token-4pqlv" Normal Pulling 10m kubelet, domain pulling image "busybox" Normal Pulled 10m kubelet, domain Successfully pulled image "busybox" Normal Created 10m kubelet, domain Created container Normal Started 10m kubelet, domain Started container

ссылочку не знаю, схема такая: есть воркер, на нём стоит nginx, слушает на каком то порту на 127.0.0.1, и проксирует все запросы на бэкенды в качестве которых API сервера. компоненты куба-воркера (кубелет и кубе-прокси) ходят в 127.0.0.1 вместо адресов API серверов

ссылочку не знаю, схема такая: есть воркер, на нём стоит nginx, слушает на каком то порту на 127.0.0.1, и проксирует все запросы на бэкенды в качестве которых API сервера. компоненты куба-воркера (кубелет и кубе-прокси) ходят в 127.0.0.1 вместо адресов API серверов

То есть ты предлагаешь на minion серверах ставить nginx который будет проксировать запросы к АПИ через себя? Типа если у меня 10 minion`ов то на каждом nginx в котором прописаны все бекенды (мастер ноды) ?

# kubectl describe pod counter Name: counter Namespace: default Node: domain/172.27.39.28 Start Time: Fri, 19 Jan 2018 18:32:39 +0300 Labels: <none> Annotations: <none> Status: Running IP: 10.244.0.13 Containers: count: Container ID: docker://7049fcc5911a6c7a5dbe182bc69351e16dbb1d9727f502e6c41dc61d05cfe0fb Image: busybox Image ID: docker-pullable://busybox@sha256:ac2fc418f3348815e68e266a5aa1b60bc522581c96964912560a0baacc4f5c06 Port: <none> Args: /bin/sh -c i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done State: Running Started: Fri, 19 Jan 2018 18:32:57 +0300 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-4pqlv (ro) Conditions: Type Status Initialized True Ready True PodScheduled True Volumes: default-token-4pqlv: Type: Secret (a volume populated by a Secret) SecretName: default-token-4pqlv Optional: false QoS Class: BestEffort Node-Selectors: <none> Tolerations: node.alpha.kubernetes.io/notReady:NoExecute for 300s node.alpha.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 11m default-scheduler Successfully assigned counter to domain Normal SuccessfulMountVolume 11m kubelet, domain MountVolume.SetUp succeeded for volume "default-token-4pqlv" Normal Pulling 10m kubelet, domain pulling image "busybox" Normal Pulled 10m kubelet, domain Successfully pulled image "busybox" Normal Created 10m kubelet, domain Created container Normal Started 10m kubelet, domain Started container

Логгинг в кластере никак не конфигурировался, все "из коробки"?

Логгинг в кластере никак не конфигурировался, все "из коробки"?

да, все из коробки

То есть ты предлагаешь на minion серверах ставить nginx который будет проксировать запросы к АПИ через себя? Типа если у меня 10 minion`ов то на каждом nginx в котором прописаны все бекенды (мастер ноды) ?

да

да, все из коробки

Нашел файлик с логами: tail /var/log/pods/fb9ebd51-fd2d-11e7-9877-fa163e595e88/count_0.log Он пишется, не понятно только почему команда не показывает их

ребят, а кто-то делать что-то Kubernetes + Kerberos?

честно, ничего не понял)) знаете где сылочку взять для почитать описание схемы?

Вот тут можно посмотреть реализацию. Только нужно по ансиблу полазить. Из опыта этот вариант лучше чем вррп на мастерах