С форкающимися вещами очень некрасиво это всё работает. А это, зачастую, чище, чем 1000 подов плодить за одним сервисом.
а зачем плодить поды, когда можно плодить контейнеры?
𝚔𝚟𝚊𝚙𝚜
G72K
Andrey
Всякими kubelet'ами и иже с ними.
𝚔𝚟𝚊𝚙𝚜
ну так Kubernetes прекрасно работает с несколькими контейнерами внутри одного пода, оно для того и придумывалось, что бы fork не делать
G72K
Вот только реквест вывалиться с 500 или message вернётся в message queue. В любом случае, крутить resources нужно, но чистой метрики пока нет. У меня есть идея, что нужно напилить в cAdvisor, но времени пока нет.
На уровне ноды (node-exporter) кажется было что, не так точно, но хоть видно будет что-то не так
Andrey
ну так Kubernetes прекрасно работает с несколькими контейнерами внутри одного пода, оно для того и придумывалось, что бы fork не делать
Я про всякие демоны с кучей воркеров. Ты в парадигме нескольких контейнеров в Pod'е не сможешь их красиво скейлить.
G72K
ну так Kubernetes прекрасно работает с несколькими контейнерами внутри одного пода, оно для того и придумывалось, что бы fork не делать
Каждому контейнеру надо жирок ресурсов сверху накинуть, набегает
Andrey
На уровне ноды (node-exporter) кажется было что, не так точно, но хоть видно будет что-то не так
Есть, но глобальный только.
𝚔𝚟𝚊𝚙𝚜
Я про всякие демоны с кучей воркеров. Ты в парадигме нескольких контейнеров в Pod'е не сможешь их красиво скейлить.
так ресурсы же per pod выделяются, так и скейлить.
я не говорю что это хорошая замена микросервисам, но это отличный компромисс когда нужно запустить более одного процесса в поде
Andrey
так ресурсы же per pod выделяются, так и скейлить.
я не говорю что это хорошая замена микросервисам, но это отличный компромисс когда нужно запустить более одного процесса в поде
Мне нужно запускать 8 одинаковых процессов в контейнере. Потому что оно так работает. Я не могу размазать их по контейнерам, потому что они одинаковые и форкаются master процессом.
Andrey
И ресурсы per-container в спеке выделяются.
Andrey
Смотрю на celery, php-fpm, uWSGI и т.д.
𝚔𝚟𝚊𝚙𝚜
Мне нужно запускать 8 одинаковых процессов в контейнере. Потому что оно так работает. Я не могу размазать их по контейнерам, потому что они одинаковые и форкаются master процессом.
если мастер следит за ними и прибивает при выходе, то это не проблема
Andrei
нормальная практика прям с gitlab ci делать типа kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
𝚔𝚟𝚊𝚙𝚜
докер для этого tini юзает
Andrey
если мастер следит за ними и прибивает при выходе, то это не проблема
Тут немного не про то. Вот у тебя есть php-fpm master process, который спавнит 8 worker process'ов. Но проблема, они периодически умирают по OOM, клиенты время от времени вываливаются с 500.
Как бы ты решил эту проблему?
𝚔𝚟𝚊𝚙𝚜
я бы распихал процессы по контейнерам или использовал supervisord
Vadim
Тут немного не про то. Вот у тебя есть php-fpm master process, который спавнит 8 worker process'ов. Но проблема, они периодически умирают по OOM, клиенты время от времени вываливаются с 500.
Как бы ты решил эту проблему?
а оно не умеет создавать tcp socket и коннектится к мастеру через него?
Andrey
я бы распихал процессы по контейнерам или использовал supervisord
Т.е. 8 контейнеров в одном Pod'е?
G72K
Тут немного не про то. Вот у тебя есть php-fpm master process, который спавнит 8 worker process'ов. Но проблема, они периодически умирают по OOM, клиенты время от времени вываливаются с 500.
Как бы ты решил эту проблему?
Читать memcg pressure дескриптор и аккуратно килять процессы
Andrey
а оно не умеет создавать tcp socket и коннектится к мастеру через него?
Нет. Там unix socket или ещё какой-то дубовый IPC.
Andrey
Читать memcg pressure дескриптор и аккуратно килять процессы
Вот, но тут надо что-то делать, я пока жалуюсь. :)
Vadim
Нет. Там unix socket или ещё какой-то дубовый IPC.
тогда шарить этот сокет между 8 воркерами, каждый в отдельном контейнере этого пода
G72K
Не надо по разным контейнерам, copy on write теряется, всякие uwsgi умеют подгружать все приложение перед форком, сильно экономит память
Vadim
Не надо по разным контейнерам, copy on write теряется, всякие uwsgi умеют подгружать все приложение перед форком, сильно экономит память
тогда ловить упавшие воркеры самому?
Andrey
тогда шарить этот сокет между 8 воркерами, каждый в отдельном контейнере этого пода
Не получится, потому что в php-fpm всегда есть один воркер, который не PID 1. Т.е. всегда будет не-PID1, который может сдохнуть по OOM и никак не оповестить об этом.
Andrey
тогда ловить упавшие воркеры самому?
Как их ловить самому, если у них master process - это прямой parent?
Andrey
ну в этом случае php-fpm сам должен за своими процессами следить.
Да, но OOM статистики-то он, сука, не даёт.
Andrey
И с такой логикой придётся патчить каждый такой процесс, чтобы он wait(2) парсил и отдавал метриками.
G72K
тогда ловить упавшие воркеры самому?
Ну тут две не взаимоисключающие стратегии: знать об этом и крутить ресурсы и вторая - пытаться предотвратить , гася распухшие воркеры пока OOMkill не пришел
Andrey
Ну тут две не взаимоисключающие стратегии: знать об этом и крутить ресурсы и вторая - пытаться предотвратить , гася распухшие воркеры пока OOMkill не пришел
Это оверинжиниринг уже пошёл. Достаточно быть в курсе этих смертей, чтобы корректно resources и HPA настроить. Но готового ничего нет.
Andrey
От того и бугурт.
Andrey
А не пишу я патчей, потому что пиздеть - не мешки ворочать. И скоро Новый год вообще. :с
George
George
Проверял ?
Dmitrii
На aws cni + ipvs днс в альпайне не работает, на calico + ipvs все окей.
G72K
На aws cni + ipvs днс в альпайне не работает, на calico + ipvs все окей.
Все равно по хорошему надо DNS на каждой ноде локально ставить (дкмонсетом или Статик подом), как бонус та бага в ядре не триггерится
George
Там не будет copy, потому что не будет форков, значит не будет cow
Хм. Мне казалось, что и между разными процессами из одного исполняемого файла будет cow?
George
Т.е. которые не форки друг друга, а сиблинги
Andrey
На aws cni + ipvs днс в альпайне не работает, на calico + ipvs все окей.
Интересно, чем это обусловлено
Andrey
Чем таким калико отличается от aws-cni
Andrey
Вроде у ipvs свой собственный коннтрэк
Andrey
И в теории одно его использование должно помочь
George
Я имел в виду - процессы. Типа как два инстанса nginx на одной тачке
George
У них все равно парент процесс == один ( и я не про мастер nginx'а, если что)
Andrey
Child'ы одного parent'a - siblings. Красава, я не допёр.
Andrey
You are just not so horosh in angliyskiy language
George
Это реально смешно
Andrey
Kuuuurwa
Andrey
И все же, господа, мне интересно, почему, по вашему, баг нивелируется именно с calico
Andrey
На aws cni + ipvs днс в альпайне не работает, на calico + ipvs все окей.
Инкапсуляция на always или cross-subnet?
Сергей
всем привет. расскажите кто как миграции деплоит в кубернетисе?
Сергей
идеально конечно было бы использовать ttlSecondsAfterFinished, но оно всё ещё альфа и как-то на бою использовать немного страшновато
G72K
Хм. Мне казалось, что и между разными процессами из одного исполняемого файла будет cow?
Между ними шарятся страницы с кодом из бинарников и библиотек
Сергей
Всем привет. Я стал девопсом (лол) и конечно же развернул kubespray'ем кластер k8s. А потом один из мастеров этого кластера внезапно умер, так, что его уже не восстановить. Казалось бы, что все должно быть просто - добавляем нового мастера, реплицируем etcd и вперде. Теперь вопрос: как это сделать с учетом того, что все развернуто было kubespray?
Vadim
Всем привет. Я стал девопсом (лол) и конечно же развернул kubespray'ем кластер k8s. А потом один из мастеров этого кластера внезапно умер, так, что его уже не восстановить. Казалось бы, что все должно быть просто - добавляем нового мастера, реплицируем etcd и вперде. Теперь вопрос: как это сделать с учетом того, что все развернуто было kubespray?
https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes
Grisha
Сергей
https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#adding-nodes
о, вы погулили за меня, спасибо! Нет, серезно, благодарю.
G72K
Всем привет. Я стал девопсом (лол) и конечно же развернул kubespray'ем кластер k8s. А потом один из мастеров этого кластера внезапно умер, так, что его уже не восстановить. Казалось бы, что все должно быть просто - добавляем нового мастера, реплицируем etcd и вперде. Теперь вопрос: как это сделать с учетом того, что все развернуто было kubespray?
У вас порядок перепутан :) сначала взять модный куб, потом раскатать абы как без вникания кубспреем, потом ковыряться и убить наглухо мастер (не забыв сказать что он умер будто сам), потом придти в чат с вопросами и вот только потом можно носить гордое звания девопса :) добро пожаловать, мы тут все такие
Сергей
кстати, не помог гугол.
G72K
У него выходной
uncleroot
Rainbow
кстати, не помог гугол.
открываете github, находите проект и там папочка docs есть с 90% вероятностью. А т.е. kubespray делается через git clone, то далеко ходить не нужно даже
Сергей
да, это я в первую очередь сделал. испробовал все варианты, потом спросил уже
Сергей
а тут только мемасы можно постить?
Rainbow
ещё говорить, что helm какаха 💩