в v3.1 пофиксили много связаных с этим проблем. по крайней мере у нас все более-менее ок с ней.
3.2 amd64
Anonymous
Anonymous
Flannel 0.10.0
Maxim
3.2 amd64
я напутал, мултус стал стабильнее как раз в версии 3.2.
логи мултуса случайно не пишете?
если это действительно мултус не подчищает за собой, то в логах мултуса должны быть ошибки.
Anonymous
Не увидел. Пересмотрю чуть позже ещё раз
Anonymous
Да и на ты, ко мне можно как-бы
Anton
я напутал, мултус стал стабильнее как раз в версии 3.2.
логи мултуса случайно не пишете?
если это действительно мултус не подчищает за собой, то в логах мултуса должны быть ошибки.
в 3.2 другой косяк — нельзя интерфейсы называть как вздумается (если я всё правильно помню)
Maxim
в 3.2 другой косяк — нельзя интерфейсы называть как вздумается (если я всё правильно помню)
не встречал, так как использовал дефолтные значения всегда.
но вполне возможно, разработка у них весьма сумбурная)
Anonymous
В доках вроде как прописываешь имя в конфиге фланели и все
Anonymous
Anonymous
Имею ввиду для расширения подсети
Anton
а почему именно фланель?
Anton
как думаете, кросс-региональный кластер в рамках одного клауда норм запилить или — ну, такое?
Anton
gce, там вроде свои каналы, с лэтенси всё ништяк
Terry
как думаете, кросс-региональный кластер в рамках одного клауда норм запилить или — ну, такое?
да хоть в разны, смысл же в отказоустойчивости, если сделаешь обходной маршрут, почему нет?
Yury
Anton
да хоть в разны, смысл же в отказоустойчивости, если сделаешь обходной маршрут, почему нет?
вот я и спрашиваю почему нет
Yury
не уверен насчет gce, но в aws регионы географически далеко, поэтому летенси будет большим в любом случае даже на идеальном коннекте. А для одного региона в разных зонах почему бы и нет
Yury
между регионами летенси 50-200мс. Многовато.
Andor
Vadim
gce, там вроде свои каналы, с лэтенси всё ништяк
https://geekflare.com/google-cloud-latency/ чот неочень ништяк
Yury
я бы отдельные кластеры пилил
Andor
ты впн в кубере пускаешь?
Andor
а там где два там и 10
Andor
а зачем только два если можно 10 и это дёшево?
Anton
потому что обслуживать один демонсет проще, чем 10 деплойментов
Anton
обслуживать и обновлять один кластер, проще чем 10
Andor
два же
Andor
два уже не сильно-то проще становится
Vadim
обслуживать и навернуть во время обновления один кластер и правда проще
Anton
ладно, мне бы по сути консёрны услышать, два или десять потом разберёмся
Anton
интересуют known проблемы с лэтенси
Vadim
А по сути - нормальный пайплайн (опционально federationv2) и тогда etcd перестанет разваливаться
Anton
кстати, fv2 вообще юзабл?
Anton
а то версия 0.0.8 не внушает доверия
Anton
для развала etcd я не вижу предпосылок, мастера нет идеи сделать кросс-региональными
Vadim
кроссрегиональный кластер, но мастера собраны в одной зоне?
𝚔𝚟𝚊𝚙𝚜
потому что обслуживать один демонсет проще, чем 10 деплойментов
С ksonnet / qbec пофиг сколько кластеров обслуживать например.
Но в целом я согласен: если твои сервисы не сильно зависят от kube-api и слабо связаны между ссобой, то смело разворачивай, проблем быть не должно
Anton
кроссрегиональный кластер, но мастера собраны в одной зоне?
зоны может и три, регион один для мастеров
Vadim
кстати, fv2 вообще юзабл?
юзабл если тебе не нужно ничего сложного - деплойменты обновлять в управляемых кластерах
Stefan
обслуживать и навернуть во время обновления один кластер и правда проще
разве не делают так, что подымают рядом еще один кластер, на который всё переливается и трафик потом переключают на новые балансеры?
Stefan
как-то стремно один кластер на горячую обновллять
Vadim
разве не делают так, что подымают рядом еще один кластер, на который всё переливается и трафик потом переключают на новые балансеры?
можно и так сделать, но тогда смысл ставить один кластер на все регионы, если их и так будет два?
Stefan
можно и так сделать, но тогда смысл ставить один кластер на все регионы, если их и так будет два?
не, к той теме мой вопрос не имеет значения, я больше о подходе к обновлению кластеров
𝚔𝚟𝚊𝚙𝚜
разве не делают так, что подымают рядом еще один кластер, на который всё переливается и трафик потом переключают на новые балансеры?
стейтлесс можно как угодно обновлять - ему же пофиг
Andor
между двумя и десятком мало разницы в операционной сложности
Stefan
стейтлесс можно как угодно обновлять - ему же пофиг
паранойя... вдруг коряво обновится или чет не учту важного
𝚔𝚟𝚊𝚙𝚜
паранойя... вдруг коряво обновится или чет не учту важного
как правило сервис не сломается если аписервер ненадолго приляжет
𝚔𝚟𝚊𝚙𝚜
но нынешняя структура с мультимастером позволяет обновиться вообще без простоя
𝚔𝚟𝚊𝚙𝚜
и даже если что-то пошло не так, всегда можно откатиться, главное все мастера одновременно не обновлять, а один за другим)
𝚔𝚟𝚊𝚙𝚜
проблемы начинаются в основном со стейтом после обновления, то CSI сломается, то еще что, узнается как правило при перезапуске первого пода)
Stefan
и даже если что-то пошло не так, всегда можно откатиться, главное все мастера одновременно не обновлять, а один за другим)
ну копс так делает, только не одновременно естественно 😆
Stefan
проблемы начинаются в основном со стейтом после обновления, то CSI сломается, то еще что, узнается как правило при перезапуске первого пода)
стейт это ты о стейтфулл приложениях?
𝚔𝚟𝚊𝚙𝚜
ага
𝚔𝚟𝚊𝚙𝚜
мы стейт в кубере крутим, и знаем как готовить его 😎
Puma
Вообще как быть с апдейтами кубера?
Puma
А что делать если при апдейте завалился прод ?
Puma
Есть конечно позиция не обновлять кубер, но мне кажется не панацея
Stefan
А что делать если при апдейте завалился прод ?
ну как я понял из комментариев, это нужно еще попытаться
Stefan
завалить при апдейте
Puma
Я два раза переставлял кластер и это я его только тыкаю по мелочи
𝚔𝚟𝚊𝚙𝚜
Вообще как быть с апдейтами кубера?
Все апдейты тестируются в стейджинге сначала изучаются возможные проблемы и как их избежать при апгрейде прода
Stefan
Да с пол пинка ))))
приложение допустим да, но саму экосистему кубера положить не думаю что сильно просто😆
Puma
приложение допустим да, но саму экосистему кубера положить не думаю что сильно просто😆
Так приложения у меня не ломаются, как раз инфраструктура и ломается
Egor
Э