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
Sergei
>там всегда ровно одна принимающая решения нода
это тоже неверно
Etki
так, я подумал что мы говорим про блансировку самого куба
Etki
Etki
там может быть несколько нод, считающих себя мастером. но закоммитить сможет только одна.
Sergei
эни пруфс?
почитайте как работает Raft.
в etcd всегда один координатор транзакций. но решение принимает не одна нода.
Etki
да вот именно, что в рафте один мастер и куча фолловеров
Sergei
с практической точки зрения вы правы, это не масштабируется.
но говорить что мастер единолично все решает - неверно.
Etki
они не участвуют в транзакции, они участвуют в отсылке сообщений о приеме логов
Sergei
Etki
окей, давайте просто скажем, что фолловеры ничего не решают
Etki
они не принимают участия в решении
Etki
они могут отказать мастеру в его короне, сославшись на терм. в решении же они не участвуют никак.
Sergei
если фолловер не подтверждает применимость транзакции, мастер не может коммитить.
Eugene
Кто нибудь etcd "по миру пускал", ну там одна нода в северноей европе, другая в западной третья на востоке сшп и тд?
Etki
это не влияет на решение. это влияет на легитимность того, кто выдвигает решение.
Sergei
Sergei
Eugene
от спасибо а то я сам не догадался)
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
:)
Vladimir
продолжаем тред маленьких девопсов,
https://github.com/kubernetes/contrib/tree/master/keepalived-vip
вот тут поясняется, что dns round-robin не нужен, да и в доках k8s пишится мол "не делой так, подумой"
поясняется тем, что если одна из трех нод упадет, то 33% трафика будет идти на мертвую ноду
решение предлагает через VIP, якобы пусть весь трафик пойдет на одну машину, зато если она упадет, то мы быстро выберем нового мастера и направим трафик туда
меня тут немного смущает, что пока одна машина работает, другие отдыхают, как нагрузку то балансировать тогда?🤔
ведь допустим если трафик вырастет так, что одна машина не справляется, зато три вместе ок выдержат, то в случае с VIP этот трафик просто поочередно убьет все три машины
очевидно, я чего-то не понимаю в этом способе и решение более хитрое, чем я предполагаю, или нет?
Вопрос в том что ты хочешь - балансировку или отказоустойчивость. Если тебе нужно 3-х кратное резервирование то не имеет значения у тебя трафик пойдет на одну ноду или на все 3. 3-х кратное резервирование подразуемвеает что 1 нода должна держать нагрузку
Vladimir
например
Vladimir
@alisabents если все же не хочется так делать, то стоит почитать либо вайтпейпер на maglev и сделать также, но на опенсорсном софте (например поверх ipvs), ну либо просто сразу почитать про всякие ECMP
Vladimir
но это несколько сложнее
Vladimir
с DNS проблема в том что хоть клиенты должны уважать TTL для доменов, но на практике встречаются такие, которые его задирают если он слишком низкий, поэтому то что ты поставишь TTL 60 и быстро удалишь сдохший IP из DNS все равно приведет к тому что весомый процент клиентов будут долбиться периодически на сдохший сервер
Vladimir
из практики - 5-10% и дня три
Vladimir
хотя эксперимент конечно старый и сейчас может быть лучше уже все
Vladimir
И не надо думать о том что у тебя будут меганагрузки и нужно 3 сервера чтобы с ними справляться, пока нет данных которые это подтверждают :)
Vladimir
то есть прикидок нагрузки и т.п.
Vladimir
а то ты сейчас закопаешься в решении проблемы которая у тебя в этой конторе может никогда не возникнуть
Vladimir
опыт конечно полезный, но нафига?
Роман
А какой может быть случай, в котором etcd не выдержит нагрузку? Как можно инициировать её?
Sergei
Роман
на балансировке - никакой
То есть, вне зависимости от того, сколько у меня нод, подов и прочего, я не смогу создать сколь-нибудь ощутимую нагрузку на etcd, если у меня просто обычный кластер?
Etki
Нагрузка на etcd пропорциональна количеству операций в кубе, поэтому в теории до него можно таким образом докопаться. На практике вряд ли кто-то кроме гугла добирался до таких проблем, и тут актуален комментарий выше про проблему, которая скорее всего никогда не возникнет.
Anonymous
@Civiloid спасибо большое за советы! :)
Роман
Пользователи prometheus, подскажите, а обязательно node-exporter'у обязательно hostNetwork: true? зачем ему слушать публичный адрес?
kås
Да вроде не обязательно, если ты метрику собираешь по локалке.
kås
Даже не кашерно такое наружу отдавать. Палево же
Sergey
кому нужны ваши метрики)
kås
Кстати там авторизацию в экспортёр не запилили ещё?
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 из чартов ставил хелмом