это наилучший вариант. делаем контейнер с unicron+django и размножаем. Главный вопрос – как джанго прожует работу в кластере, штатных средств кластеризации там не было.

зачем в контейнере запускать несколько процессов? вам проще несколько контейнеров запускать

ну стейт лежит в кешах всяких и базах

зачем в контейнере запускать несколько процессов? вам проще несколько контейнеров запускать

С этим я не спорю

так что небольшая проблема

стейт в кеше это проблема ;)

прометеем метрики при 1 воркере неудобно снимать %)

стейт в кеше это проблема ;)

угу

так что небольшая проблема

нет, это не то, что бы проблема. Это вопрос. И вопрос звучит очень просто – может ли существующий воркер работать в кластере. и этот вопрос надо задавать программисту. Может там все разумно сделано под кластер. А кеша на запись в джанго по умолчанию нет (и я не представляю, кому может в джанго такая светлая мысль вообще в голову прийти)

а кеши на чтение решаются элементарными sticky sessions

ну или шаровым кешем в редисе или мемкеше

Итак, самый оптимальный вариант это сунуть гуникорн в контейнер с апом в один воркер, а потом эти контейнеры плодить и балансить, я правильно понимаю? И есть ли какой нибудь оверхед в этом, кроме того что контейнер в размере больше становится?

А и чем лучше балансить, нжинксом или средствами куба?

Если я не корректно задаю вопрос подправьте, я не силен в предметной области

а "средства куба" это у тебя что?

nginx ingress?

а статику джанговскую ты как раздаёшь кстати?

nginx ingress?

Ingress controller вроде он называется

а статику джанговскую ты как раздаёшь кстати?

Nginx

а он у тебя где?

Ingress Controller может быть не только nginx прост

а он у тебя где?

Отдельный контейнер

ok

и деплоится отдельным Deployment?

и деплоится отдельным Deployment?

Нет, сейчас он вместе с апом деплоиться, апп через него и баланситься

а есть ли контроллер который умеет несколько разных Deployment создавать и контролировать чтобы там были всегда те версии которые надо и делать rollback на предыдущие версии для всех подконтрольных деплойментов?

ться

а есть ли контроллер который умеет несколько разных Deployment создавать и контролировать чтобы там были всегда те версии которые надо и делать rollback на предыдущие версии для всех подконтрольных деплойментов?

ну то есть по-сути мне бы хотелось чтобы при фейле деплоймента откатывался и соседний например

Подозреваю что нет, я сейчас пытаюсь разобраться с инфраструктурой в новом проекте и спрашиваю бест вейс

это я не у тебя лично спрашиваю, а у чата вообще

ну то есть по-сути мне бы хотелось чтобы при фейле деплоймента откатывался и соседний например

Вообще как мне известно делают чтобы infrastructere as a code, и тогда при изменении кода апа, связные контейнеры тоже меняются

Вообще как мне известно делают чтобы infrastructere as a code, и тогда при изменении кода апа, связные контейнеры тоже меняются

В плане, вспомогательные типа того же nginx

ну так я спрашиваю как раз про то чтобы контроллер контролировал эту "связанность контейнеров"

поднимите в одном поде контейнер с nginx и статикой и контейнер с джанго бекендом

да так и делаем щас

но хотелось бы статику отделить

правда не знаю зачем %)

перфекционизм %)

тогда надо широко шагать

статику на сдн

написать свой контроллер?

ну CDN надо будет как-то вычищать при деплоях, что может быть не так удобно

да ладно.... живут же как-то люди

да я не спорю

но у нас вообще CDN нету для этого щас :)

ну тогда принцип - работает, не трогай )

ну тоже верно

Вот к примеру есть statefelset с двумя репликами. Нафиг им headless сервис?

чтобы можно было все поды одного стейтфулсета дискаверить по днс и им общаться между собой (например, монга)

alertmanager в прометее :)

Ребут не помог) это тестовый кластер, могу себе позволить ребут всего)

бывало такое на версии 1.4 часто, обычно делал kubectl delete pod <pod name> --force и помогало

Не помогло(

1.10.1

orphaned pod может появиться когда идет rolling update деплоймента а тут старый под удалили вручную или там нода умерла и под перешедулился на другую. В итоге выходит что куб заскейлил rs от этого пода в 0 но при этом его перезапустил

но при этом сам RS ещё жив, верно?

Это бы я еще понял, тут же на ровном месте

Гуникорн внутри контейнера в один воркер и эти контейнеры плодить?

мы запускаем 2 воркера гюникорна в одном поде, поду даем реквест-лимитс 1 цпу (как в документации гюникорна советуют 2 воркера на цпу) и дальше HPA это дело скейлит. Уже 9 месяцев - полёт нормальный

но у нас не джанго а фласк если что и апп простой как табуретку - принять json и запихнуть в очередь

он у вас и асинхронный наверное до кучи

ну CDN надо будет как-то вычищать при деплоях, что может быть не так удобно

О_О это еще зачем? девелоперы не умеют версионировать статику нормально штоле?

сам-то как думаешь? :)

Не помогло(

ну тут хз, может завезли новых багов

но конечно лучше версионировать и не трахать мозги

один хер s3 есть

но при этом сам RS ещё жив, верно?

RC может быть жив с desired=0 а может и быть удален уже если кто-то вручную удаляет что-то варварски. Но под уже к RC не привязан даже если он жив (по крайней мере в 1.4 и 1.5 так)

он у вас и асинхронный наверное до кучи

хз, внутрь особо не заглядывал

у тебя кстати HPA по стандартным метрикам работает?

или кастом подключал?

сам-то как думаешь? :)

так дело нехитрое же, у меня вот в одном проекте есть версионирование для убогих - просто рандомный хеш генерируется при деплое и потом все ссылки на статику выглядят /static/<hash 32 chars>/<css|js|img|...>/...

да у нас можно просто циферки по версии релиза

и потом тупо реврайтом нжинкса вырезается хеш из угла и на папку /static/<css|js|img|...>/... мапится

или даже хардкодить заставлять

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

да допинаю когда-нибудь

но потом %)

и дальше можно и в сдн, и ингрессом все что /static отправить в отдельный под и т.д. и т.п.

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

тогда уж в несколько поддоменов чтобы сделать domain sharding и грузилось шустрее

но это уже оффтоп пошёл совсем

Коллеги, немного нубский вопрос, но стесняться некого. Headless сервис для чего вообще юзается? Можете кратко пояснить?

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

чтобы можно было все поды одного стейтфулсета дискаверить по днс и им общаться между собой (например, монга)

Большое спасибо