я просто новый бинарь kubelet'a заношу на ноды и новые манифесты в /etc/kubernetes/manifests

А поды в таком случае гасятся? Или как вообще этот процесс протекает?

нет

только те, для которых манифесты поменялись

ты можешь пойти сейчас на любую ноду и пристрелить там kubelet

все поды будут продолжать бежать

остановить-то их будет некому со смертью кьюблета ;)

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

эээ

а зачем ты ноды гасишь?

ну копс так делает, у нас aws

Новую поднимаешь ноду, старую гасишь

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

потом ты ее гасишь и уже один под остается

кластер из трех подов у нас

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

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

гггг

а в пользу чего отказаться?

смотря для чего вы его используете. из message queue самые положительные отзывы за кафкой (но там вроде еще ZK придется поднимать), k-v хранилищ сколько угодно, у меня аэроспайк (к нему свои претензии, но нам не нужны строгие гарантии в k-v кэше)

ну а в чем профит? чем редис плох?

этож не мемкеш)

в этом чате места не хватит. у него абсолютно нулевые гарантии и абсолютно ущербная однопоточная модель, аналогично с персистенсом (в сохранении данных раз в N минту нет никакого смысла, потому что у тебя нет гарантии, записались ли только что отправленные данные), я видел забавные случаи с "у меня редис отвечает семнадцать секунд" просто потому что автор придумал модный хак в виде хранения всего в памяти вместо нормальной архитектуры

и кластер у него банально не работает, насколько помню

ну там sentinel ставится, который ТИПА следит за кластером

другой чат

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

кк

другой чат

Предлагаю создать кубернетес оффтоп... орги, ктотам. Потому как вопросы бывает выходят далеко за, да и комьюнити растет )

А какие еще чаты есть кстати? по golang есть?

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

один конфигмап?

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

пока не представляю как лучше организовать

Как модно - хз, я просто запилил структуру папок, которая из сервиса в сервис одинаковая. Типа папка-тип ресурса, подпапка - специфичные для энв ресурсы

Но уже смотрю в сторону темплейтов для файлов

@pipopolam тебя можно будет попросить помочь с разворачиванием kubernetes на 300 нод?

хехе, я так еще не пробовал

а что за ноды?

сколько мастеров планируешь?

один датацентр или несколько?

3 ДЦ

так, то есть это уже ubernetes будет?

Сейчас только есть 2 ДЦ, третий будет в декабре

ну это не важно

на этапе проектирования

главное понять, чего с федерацией делать

кто-нить запускает в кубернетсе сервисы которым нужен сторадж ? ну там эластику или influxe/graphite, etc...

я про PersistentVolumeClaim в курсе если что :) интересует реальный опыт

лично я бы такое вообще в контейнерах не запускал :)

и дело даже не в сторадже

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

а в том, что завалится что-то из-за “нюансов контейнеризации” - будешь руками чинить

в контейнерах

безотносительно k8s

пока что у нас бд сами по себе значительно стабильнее любых “контейнерных технологий”

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

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

посмотри на количество багов в докере

довольно много из которых -довольно критичны

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

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

учитывая, что в проде докера никакого ещё нет

т.е. fs/net/kernel

вот через полгода-год можно думать, наверное

у нас этим проблемам уже год точно есть :)

т.е. fs/net/kernel

overlay сырой?

ERROR: S client not available

мы на aufs

с overlay свои проблемы были

но в целом думаю пробовать переходить на него

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

и в итоге - ребут (например)

что приводит к тому, что на 5-10 минут ты теряешь хост

что некритично для stateless штук, но очень критично для какого-нибудь mysql

если, конечно, у тебя не master-master и автоматически переключающиеся клиенты (скорее всего это не так)

у меня вообще основное приложение хрен в контейнеры засунешь, слишком много проблем

всё мечтаю в k8s это как-то засунуть

т.е. идея PV/PVC - очень интересная. и я почти уверен, что при наличии стабильной инфраструктуры самих контейнеров - вопрос бы в принципе не стоял. а так - рисковано :)

а у нас нет куба

по многим причинам

хотя микросервисы :)

да и если и будет куб - то только для шедулера. т.к. хочется внятные фоллбеки на другие DC и у нас свои нюансы с фоллбеками и хелсчеками

т.е. скорее всего kube-proxy будет кастомный

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

в AWS у тебя все по сетке работает

вообще все

у тебя rootfs тоже по сетке

так вроде бы сперва в контейнеры, потом их в к8с, не?

у меня вообще основное приложение хрен в контейнеры засунешь, слишком много проблем

всё мечтаю в k8s это как-то засунуть

в aws у меня сейчас ничего не работает (

разве что ты instance storage используешь (скорее всего нет)

Ну я эластик запихнул в кубик

ну как показывает практика - в AWS все отлично (в основном) работает

Монга там же )

ну и да - PV - это глобальный network-attached storage

в своем DC - какой-нибудь ceph

в теории с petset-ами наверное можно и локальный сторадж юзать

там по крайней мере автоматом оно не будет переносится на другие ноды