что говорит?

ничего

потрясающе

а как ты в api ходишь?

а ой, на локальной машине всмысле?

вот локальная машина

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

так получилось :c я уже решил, что проще переделать конечно, просто не ожидал подвоха с этой стороны

с точки зрения куба проблем, я так понимаю, нет. А вот с точки зрения диагностики... Я бы рекомендовал, для начала: - три ноды, а не две - разные имена - переделать

хорошо, спасибо большое! пойду переделывать

да как бы не за что. Деплой куба - очень болезненная тема. Способов - как блох, и все они не работают. И все - по-разному

да как бы не за что. Деплой куба - очень болезненная тема. Способов - как блох, и все они не работают. И все - по-разному

Почему? Все сводится к одному и тому же просто разными способами....

И замечу все способы рабочие...

зе хард вей и понеслась

И замечу все способы рабочие...

апаснасть, сейчас взбомбанет

апаснасть, сейчас взбомбанет

Да всё оно работает, просто подходить нужно с головой ОС(опен сорос) а не Винлы, где кнопка далее решает все проблемы установки...За 15 лет в ОС я столько всего перевидал, что всё тут всё долвльно нормально....Слегка доработать напильником это в порядке вещей

Ну я прошел через все стадии неизбежности: гнев, отрицание, торг, депрессия, принятие , пока разбирался с установкой кубера :)

Эт норм

да что там его ставить то?

первый раз вообще в амазоне апал через куб - ап на баше, было давно)

потом у кейси по хардвею

2 раза по хард вею и все понятно

вот уже всякие cni типа калико и инжест контроллеры - да тут уже надо помучаться

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

продолжаем тред маленьких девопсов, https://github.com/kubernetes/contrib/tree/master/keepalived-vip вот тут поясняется, что dns round-robin не нужен, да и в доках k8s пишится мол "не делой так, подумой" поясняется тем, что если одна из трех нод упадет, то 33% трафика будет идти на мертвую ноду решение предлагает через VIP, якобы пусть весь трафик пойдет на одну машину, зато если она упадет, то мы быстро выберем нового мастера и направим трафик туда меня тут немного смущает, что пока одна машина работает, другие отдыхают, как нагрузку то балансировать тогда?? ведь допустим если трафик вырастет так, что одна машина не справляется, зато три вместе ок выдержат, то в случае с VIP этот трафик просто поочередно убьет все три машины очевидно, я чего-то не понимаю в этом способе и решение более хитрое, чем я предполагаю, или нет?

узкое место все равно будет в etcd

и он не масштабируется никак, там всегда ровно одна принимающая решения нода

а почему? как он участвует в обработке трафика?

узкое место все равно будет в etcd

откуда?

>там всегда ровно одна принимающая решения нода это тоже неверно

так, я подумал что мы говорим про блансировку самого куба

>там всегда ровно одна принимающая решения нода это тоже неверно

эни пруфс?

там может быть несколько нод, считающих себя мастером. но закоммитить сможет только одна.

эни пруфс?

почитайте как работает Raft. в etcd всегда один координатор транзакций. но решение принимает не одна нода.

да вот именно, что в рафте один мастер и куча фолловеров

да вот именно, что в рафте один мастер и куча фолловеров

фолловеры участвуют в каждой транзакции. мастер без фолловеров не может коммитить.

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

они не участвуют в транзакции, они участвуют в отсылке сообщений о приеме логов

они не участвуют в транзакции, они участвуют в отсылке сообщений о приеме логов

это и есть транзакция.

окей, давайте просто скажем, что фолловеры ничего не решают

окей, давайте просто скажем, что фолловеры ничего не решают

решают. фолловеры могут отказаться принимать транзакцию и тогда мастер скажет клиенту "не согласная я".

они не принимают участия в решении

они могут отказать мастеру в его короне, сославшись на терм. в решении же они не участвуют никак.

если фолловер не подтверждает применимость транзакции, мастер не может коммитить.

Кто нибудь etcd "по миру пускал", ну там одна нода в северноей европе, другая в западной третья на востоке сшп и тд?

это не влияет на решение. это влияет на легитимность того, кто выдвигает решение.

это не влияет на решение. это влияет на легитимность того, кто выдвигает решение.

я сольюсь пожалуй, мы на разных языках говорим.

Кто нибудь etcd "по миру пускал", ну там одна нода в северноей европе, другая в западной третья на востоке сшп и тд?

летенси будет большая.

от спасибо а то я сам не догадался)

от спасибо а то я сам не догадался)

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

Спасбо, Ну судя по офф документации так есть, хотелось бы реального конфига от человека кто так делает и у него все отлично работает.

продолжаем тред маленьких девопсов, https://github.com/kubernetes/contrib/tree/master/keepalived-vip вот тут поясняется, что dns round-robin не нужен, да и в доках k8s пишится мол "не делой так, подумой" поясняется тем, что если одна из трех нод упадет, то 33% трафика будет идти на мертвую ноду решение предлагает через VIP, якобы пусть весь трафик пойдет на одну машину, зато если она упадет, то мы быстро выберем нового мастера и направим трафик туда меня тут немного смущает, что пока одна машина работает, другие отдыхают, как нагрузку то балансировать тогда?? ведь допустим если трафик вырастет так, что одна машина не справляется, зато три вместе ок выдержат, то в случае с VIP этот трафик просто поочередно убьет все три машины очевидно, я чего-то не понимаю в этом способе и решение более хитрое, чем я предполагаю, или нет?

бампану свой вопрос, если позволите ☺️

1. Никакой, связанной с темой канала. 2. Ни в чем. 3. Ничем. 4. Говорят тут ржачно и шутка дня: etcd это master-slave 5. Амстердам 6. Рассказали друзья #whois

:)

бампану свой вопрос, если позволите ☺️

что мешает в keepalived настроить N VIP адресов для всех нод и выделить по одному мастеру для VIP?

продолжаем тред маленьких девопсов, https://github.com/kubernetes/contrib/tree/master/keepalived-vip вот тут поясняется, что dns round-robin не нужен, да и в доках k8s пишится мол "не делой так, подумой" поясняется тем, что если одна из трех нод упадет, то 33% трафика будет идти на мертвую ноду решение предлагает через VIP, якобы пусть весь трафик пойдет на одну машину, зато если она упадет, то мы быстро выберем нового мастера и направим трафик туда меня тут немного смущает, что пока одна машина работает, другие отдыхают, как нагрузку то балансировать тогда?? ведь допустим если трафик вырастет так, что одна машина не справляется, зато три вместе ок выдержат, то в случае с VIP этот трафик просто поочередно убьет все три машины очевидно, я чего-то не понимаю в этом способе и решение более хитрое, чем я предполагаю, или нет?

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

например

бампану свой вопрос, если позволите ☺️

1в оставь как есть, 2в сделай 3 випа, 3в юзать pacemaker/corosync cluster ip

@alisabents если все же не хочется так делать, то стоит почитать либо вайтпейпер на maglev и сделать также, но на опенсорсном софте (например поверх ipvs), ну либо просто сразу почитать про всякие ECMP

но это несколько сложнее

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

из практики - 5-10% и дня три

ERROR: S client not available

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

И не надо думать о том что у тебя будут меганагрузки и нужно 3 сервера чтобы с ними справляться, пока нет данных которые это подтверждают :)

то есть прикидок нагрузки и т.п.

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

опыт конечно полезный, но нафига?

А какой может быть случай, в котором etcd не выдержит нагрузку? Как можно инициировать её?

А какой может быть случай, в котором etcd не выдержит нагрузку? Как можно инициировать её?

на балансировке - никакой

на балансировке - никакой

То есть, вне зависимости от того, сколько у меня нод, подов и прочего, я не смогу создать сколь-нибудь ощутимую нагрузку на etcd, если у меня просто обычный кластер?

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

@Civiloid спасибо большое за советы! :)

Пользователи prometheus, подскажите, а обязательно node-exporter'у обязательно hostNetwork: true? зачем ему слушать публичный адрес?

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

Даже не кашерно такое наружу отдавать. Палево же

кому нужны ваши метрики)

Кстати там авторизацию в экспортёр не запилили ещё?

Кстати там авторизацию в экспортёр не запилили ещё?

А зачем простой тул усложнять? Нужна авторизация, прикрути ssl проксей

Правда

я правильно понимаю, чтобы на bare-metal сервисы открылись наружу мне надо вручную поставить внешний ip в конфига балансера или мне нужно еще вне кластера на самой машине еще поставить nginx, чтобы он пробрасывал порты на под балансера? (мне правда сложна с этим немножко)

вариантов несколько

первый - нодпор для сервиса и потом айпи нод и порты прописывать куда надо

еще вариант - инжесь контроллер

ingress?

да

"svc/funny-mastiff-nginx-ingress-controller 10.233.51.39 <pending> 80:32035/TCP,443:30182/TCP 2h " ingess-controller поставленный через helm не помог подозреваю ему надо вручную ip прописать?

надо смотреть, я с ним не разбирался, ибо в амазоне юзаю тайп лодбалансер

Всем привет. Хочу сделать доступ к кластеру с локальных компов по openVpn для того чтобы можно было заходить на сайты по dns. Никто подобное не настраивал? Может есть другие пути для решения этой проблемы. На данный момент настроил доступ через ssh туннелирование и прокси, но это такое

сам кластер крутится в гугл клауд

я правильно понимаю, чтобы на bare-metal сервисы открылись наружу мне надо вручную поставить внешний ip в конфига балансера или мне нужно еще вне кластера на самой машине еще поставить nginx, чтобы он пробрасывал порты на под балансера? (мне правда сложна с этим немножко)

Почитай про hostNetwork: true. Поду можно даже сервис не создавать - порт откроется прямо на хосте-ноде.

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

Разворачиваю мониторинг по этой статье: https://github.com/gregbkr/kubernetes-kargo-logging-monitoring Интересует только мониторинг при помощи прометея. Возникла проблема. Есть такой демонсет node-directory-size-metrics. Там два контейнера. Второй, который caddy, работает и с ним всё хорошо. Первый, который read-du тоже работает, но в прометее в targets напротив метрик стоит down и ошибка: Get http://10.233.96.10:80/metrics: dial tcp 10.233.96.10:80: getsockopt: connection refused Зачем он стучится на 80 порт? там же открыт только 9102. Кто-то разворачивал это? Что ему нужно?

а кто-нибудь spinnaker из чартов ставил хелмом