Sergey
зе хард вей и понеслась
Etki
И замечу все способы рабочие...
апаснасть, сейчас взбомбанет
Maksim
апаснасть, сейчас взбомбанет
Да всё оно работает, просто подходить нужно с головой ОС(опен сорос) а не Винлы, где кнопка далее решает все проблемы установки...За 15 лет в ОС я столько всего перевидал, что всё тут всё долвльно нормально....Слегка доработать напильником это в порядке вещей
Knyage
Ну я прошел через все стадии неизбежности: гнев, отрицание, торг, депрессия, принятие , пока разбирался с установкой кубера :)
Maksim
Эт норм
Sergey
да что там его ставить то?
Sergey
первый раз вообще в амазоне апал через куб - ап на баше, было давно)
Sergey
потом у кейси по хардвею
Sergey
2 раза по хард вею и все понятно
Sergey
вот уже всякие cni типа калико и инжест контроллеры - да тут уже надо помучаться
Sergey
а сам кубер ставится без проблем, вопрос в том, что в таком виде она кроме как на поиграться нах не уперся
Anonymous
продолжаем тред маленьких девопсов, https://github.com/kubernetes/contrib/tree/master/keepalived-vip вот тут поясняется, что dns round-robin не нужен, да и в доках k8s пишится мол "не делой так, подумой" поясняется тем, что если одна из трех нод упадет, то 33% трафика будет идти на мертвую ноду решение предлагает через VIP, якобы пусть весь трафик пойдет на одну машину, зато если она упадет, то мы быстро выберем нового мастера и направим трафик туда меня тут немного смущает, что пока одна машина работает, другие отдыхают, как нагрузку то балансировать тогда?🤔 ведь допустим если трафик вырастет так, что одна машина не справляется, зато три вместе ок выдержат, то в случае с VIP этот трафик просто поочередно убьет все три машины очевидно, я чего-то не понимаю в этом способе и решение более хитрое, чем я предполагаю, или нет?
Etki
узкое место все равно будет в etcd
Etki
и он не масштабируется никак, там всегда ровно одна принимающая решения нода
Anonymous
а почему? как он участвует в обработке трафика?
Sergei
>там всегда ровно одна принимающая решения нода это тоже неверно
Etki
так, я подумал что мы говорим про блансировку самого куба
Etki
там может быть несколько нод, считающих себя мастером. но закоммитить сможет только одна.
Sergei
эни пруфс?
почитайте как работает Raft. в etcd всегда один координатор транзакций. но решение принимает не одна нода.
Etki
да вот именно, что в рафте один мастер и куча фолловеров
Sergei
да вот именно, что в рафте один мастер и куча фолловеров
фолловеры участвуют в каждой транзакции. мастер без фолловеров не может коммитить.
Sergei
с практической точки зрения вы правы, это не масштабируется. но говорить что мастер единолично все решает - неверно.
Etki
они не участвуют в транзакции, они участвуют в отсылке сообщений о приеме логов
Etki
окей, давайте просто скажем, что фолловеры ничего не решают
Sergei
окей, давайте просто скажем, что фолловеры ничего не решают
решают. фолловеры могут отказаться принимать транзакцию и тогда мастер скажет клиенту "не согласная я".
Etki
они не принимают участия в решении
Etki
они могут отказать мастеру в его короне, сославшись на терм. в решении же они не участвуют никак.
Sergei
если фолловер не подтверждает применимость транзакции, мастер не может коммитить.
Eugene
Кто нибудь etcd "по миру пускал", ну там одна нода в северноей европе, другая в западной третья на востоке сшп и тд?
Etki
это не влияет на решение. это влияет на легитимность того, кто выдвигает решение.
Eugene
от спасибо а то я сам не догадался)
Sergei
от спасибо а то я сам не догадался)
работает. таймауты надо покрутить, чтобы у вас был запас.
Eugene
Спасбо, Ну судя по офф документации так есть, хотелось бы реального конфига от человека кто так делает и у него все отлично работает.
Anonymous
продолжаем тред маленьких девопсов, https://github.com/kubernetes/contrib/tree/master/keepalived-vip вот тут поясняется, что dns round-robin не нужен, да и в доках k8s пишится мол "не делой так, подумой" поясняется тем, что если одна из трех нод упадет, то 33% трафика будет идти на мертвую ноду решение предлагает через VIP, якобы пусть весь трафик пойдет на одну машину, зато если она упадет, то мы быстро выберем нового мастера и направим трафик туда меня тут немного смущает, что пока одна машина работает, другие отдыхают, как нагрузку то балансировать тогда?🤔 ведь допустим если трафик вырастет так, что одна машина не справляется, зато три вместе ок выдержат, то в случае с VIP этот трафик просто поочередно убьет все три машины очевидно, я чего-то не понимаю в этом способе и решение более хитрое, чем я предполагаю, или нет?
бампану свой вопрос, если позволите ☺️
Vladimir
1. Никакой, связанной с темой канала. 2. Ни в чем. 3. Ничем. 4. Говорят тут ржачно и шутка дня: etcd это master-slave 5. Амстердам 6. Рассказали друзья #whois
Denis
:)
Anton
бампану свой вопрос, если позволите ☺️
что мешает в keepalived настроить N VIP адресов для всех нод и выделить по одному мастеру для VIP?
Vladimir
продолжаем тред маленьких девопсов, https://github.com/kubernetes/contrib/tree/master/keepalived-vip вот тут поясняется, что dns round-robin не нужен, да и в доках k8s пишится мол "не делой так, подумой" поясняется тем, что если одна из трех нод упадет, то 33% трафика будет идти на мертвую ноду решение предлагает через VIP, якобы пусть весь трафик пойдет на одну машину, зато если она упадет, то мы быстро выберем нового мастера и направим трафик туда меня тут немного смущает, что пока одна машина работает, другие отдыхают, как нагрузку то балансировать тогда?🤔 ведь допустим если трафик вырастет так, что одна машина не справляется, зато три вместе ок выдержат, то в случае с VIP этот трафик просто поочередно убьет все три машины очевидно, я чего-то не понимаю в этом способе и решение более хитрое, чем я предполагаю, или нет?
Вопрос в том что ты хочешь - балансировку или отказоустойчивость. Если тебе нужно 3-х кратное резервирование то не имеет значения у тебя трафик пойдет на одну ноду или на все 3. 3-х кратное резервирование подразуемвеает что 1 нода должна держать нагрузку
Vladimir
например
Eugene
бампану свой вопрос, если позволите ☺️
1в оставь как есть, 2в сделай 3 випа, 3в юзать pacemaker/corosync cluster ip
Vladimir
@alisabents если все же не хочется так делать, то стоит почитать либо вайтпейпер на maglev и сделать также, но на опенсорсном софте (например поверх ipvs), ну либо просто сразу почитать про всякие ECMP
Vladimir
но это несколько сложнее
Vladimir
с DNS проблема в том что хоть клиенты должны уважать TTL для доменов, но на практике встречаются такие, которые его задирают если он слишком низкий, поэтому то что ты поставишь TTL 60 и быстро удалишь сдохший IP из DNS все равно приведет к тому что весомый процент клиентов будут долбиться периодически на сдохший сервер
Vladimir
из практики - 5-10% и дня три
Vladimir
хотя эксперимент конечно старый и сейчас может быть лучше уже все
Vladimir
И не надо думать о том что у тебя будут меганагрузки и нужно 3 сервера чтобы с ними справляться, пока нет данных которые это подтверждают :)
Vladimir
то есть прикидок нагрузки и т.п.
Vladimir
а то ты сейчас закопаешься в решении проблемы которая у тебя в этой конторе может никогда не возникнуть
Vladimir
опыт конечно полезный, но нафига?
Роман
А какой может быть случай, в котором etcd не выдержит нагрузку? Как можно инициировать её?
Роман
на балансировке - никакой
То есть, вне зависимости от того, сколько у меня нод, подов и прочего, я не смогу создать сколь-нибудь ощутимую нагрузку на etcd, если у меня просто обычный кластер?
Etki
Нагрузка на etcd пропорциональна количеству операций в кубе, поэтому в теории до него можно таким образом докопаться. На практике вряд ли кто-то кроме гугла добирался до таких проблем, и тут актуален комментарий выше про проблему, которая скорее всего никогда не возникнет.
Anonymous
@Civiloid спасибо большое за советы! :)
Роман
Пользователи prometheus, подскажите, а обязательно node-exporter'у обязательно hostNetwork: true? зачем ему слушать публичный адрес?
kås
Да вроде не обязательно, если ты метрику собираешь по локалке.
kås
Даже не кашерно такое наружу отдавать. Палево же
Sergey
кому нужны ваши метрики)
kås
Кстати там авторизацию в экспортёр не запилили ещё?
Dmitry
Кстати там авторизацию в экспортёр не запилили ещё?
А зачем простой тул усложнять? Нужна авторизация, прикрути ssl проксей
kås
Правда
Anonymous
я правильно понимаю, чтобы на bare-metal сервисы открылись наружу мне надо вручную поставить внешний ip в конфига балансера или мне нужно еще вне кластера на самой машине еще поставить nginx, чтобы он пробрасывал порты на под балансера? (мне правда сложна с этим немножко)
Sergey
вариантов несколько
Sergey
первый - нодпор для сервиса и потом айпи нод и порты прописывать куда надо
Sergey
еще вариант - инжесь контроллер
Anonymous
ingress?
Sergey
да
Anonymous
"svc/funny-mastiff-nginx-ingress-controller 10.233.51.39 <pending> 80:32035/TCP,443:30182/TCP 2h " ingess-controller поставленный через helm не помог подозреваю ему надо вручную ip прописать?
Sergey
надо смотреть, я с ним не разбирался, ибо в амазоне юзаю тайп лодбалансер
Никита
Всем привет. Хочу сделать доступ к кластеру с локальных компов по openVpn для того чтобы можно было заходить на сайты по dns. Никто подобное не настраивал? Может есть другие пути для решения этой проблемы. На данный момент настроил доступ через ssh туннелирование и прокси, но это такое
Никита
сам кластер крутится в гугл клауд
Роман
Но сервис нужен, если ты хочешь изнутри к поду подключаться по имени.
Роман
Разворачиваю мониторинг по этой статье: 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. Кто-то разворачивал это? Что ему нужно?
bebebe
а кто-нибудь spinnaker из чартов ставил хелмом