Как правильно масштабировать Django с Kubernetes?

Question

[bubaley]

Здравствуйте

Немного текущей реализации и возможностях.
Сейчас у нас есть Django + DRF проект завернутый в Docker и docker-compose.
Контейнеры в docker-compose:
- Само приложение
- Redis
- DB
- Celery
- Flower
- PgBouncer
Проект push-ится в github, по ssh (руками) на сервере происходит pull и сборка проекта (все архитектура на одной виртуалке).
Мне такой формат не очень нравится (нет конвейерной разработки, надо подключаться на сервер, нет масштабирования, downtime).

Знаю, что могу вынести DB и pgbouncer на отдельные сервера, сделать еще один контур приложения и настроить балансировщик. Но тогда мне все равно надо будет руками собирать проект, что так себе.

Хочу такой вариант пропустить и сразу перейти к kubernetis (про него знаю в общих чертах)

Подскажите как правильно организовать такой процесс, в какие вещи стоит углубиться (я так понимаю, все контейнеры должны быть в dockerhub, нужны github actions и тд). Но хочется услышать это от людей, который с этим сталкиваются постоянно, заранее спасибо

Comments

[d'Ivan]

и сразу перейти к kubernetis (про него знаю в общих чертах)

а ты уверен, что овчинка стоит выделки?

[Everything_is_bad]

Знаю, что могу вынести DB и pgbouncer на отдельные сервера, сделать еще один контур приложения и настроить балансировщик.

ты точно понимаешь проблемы, которые возникают при разделении на сервера, чтобы не было потом, а чё это всё тормозить стало ;)

[Alexey Dmitriev]

" так понимаю, все контейнеры должны быть в dockerhub, нужны github actions и тд" - вы все неверно понимаете.
k8s не нужны контейнеры. Ему нужны yaml файлы и helm чарты.

Answer 1

[Roman K]

Хочу такой вариант пропустить и сразу перейти к kubernetis

"You think you do, but you don't"

Знаю, что могу вынести DB и pgbouncer на отдельные сервера

Чтобы увеличить RTT?

Для поддержки кубика нужна целая выделенная команда, которая, помимо кубика, ещё настроит и будет поддерживать ёлку (ELK), какой-нибудь vault, графану, прометей, консул, докер реджистри, s3 (типа minio или seaweedfs, ведь контейнеры теперь stateless и хранить на них ничего нельзя) и кучу других сложных штук. Если у тебя нет сотни разработчиков в компании, то не нужно играть в гугл.

Во-первых, какая у тебя нагрузка? Сколько тысяч запросов в секунду приходит и отмасштабировал ли ты вертикально и упёрся уже в потолок? gunicorn оптимально настроен? сколько процессов/потоков, какой тип воркеров? json парсишь и сериализуешь orjson'ом? Приложение профилировал?
Во-вторых, 12 factor
В-третьих, у базы есть реплики? read запросы раскидал на реплики? а редис? Действительно ли нужен zero downtime (это исходит из вопроса про нагрузку)

Если тебе хочется просто поиграть, то поставь локально кубик, поиграй, погрусти и удали. Не нужно это тащить в прод, если нет на это необходимости. А если ты даже название kubernetes не можешь правильно написать, то он тебе не нужен.

P.S. DRF — медленное нетипизированное говно, выкинь его

Comments

[Everything_is_bad]

DRF — медленное нетипизированное говно, выкинь его

ну медленное, ну нетипизированное, но до определенных нагрузок самое то (не у всех же они мега большие), конечно если хочешь чтобы еще и поддерживалось легко, то надо писать не как рекондуют офдоки, а хотя бы вынести бизнес логику из него, ну и serializer чтобы только данные преобразовывал, нормализовал и т.п, а не писал в бд (иногда и валидация на его уровне спорный вопрос). Мне вот тут больше всего не нравится Celery, сколько раз пробовал, то оверхед, то какие-то непонятные проблемы.

[Roman K]

Everything_is_bad, pydantic сделает это быстрее и лучше

[Everything_is_bad]

Roman K, да это понятно, новый проект с rest, а скорее начну на fastapi (еще бы alembic дотянуть до джанговских миграций), но если требуется к django проекту прикрутить rest, я почти всегда drf выберу.

[bubaley]

В целом то, что мне нужно я услышал, спасибо
DRF правда не очень подходит, но он изначально тянется в стеке, отойти от него и перейти в fast api пока нет возможности.

По факту сейчас наверное нет смысла смотреть в кубер, а просто поднять сервак по максимальной производительности, потом поднять еще пару машин и настроить балансировщик на них, логи выбросить в елку и настроить CI/CD + сделать бд реплики и на них перевести запросы для чтения

[Roman K]

Everything_is_bad, django даёт во многих случаях слишком много, чтобы писать что-то на fastapi. fastapi я тоже люблю, но в большинстве кейсов джанга даёт больше

Answer 2

[Vitaly Karasik]

Тут есть два не связанных вопроса:
1) как сделать CI/CD
2) на какой платформе (VM, Docker compose, Nomad, K8S, какой-нибудь cloud app server) оптимально поднимать сервис

Насчет первого - с помощью Github Actions легко сделать CI/CD ничего не меняя в архитектуре.

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