Дмитрий

Ты эту БД давно используешь? Просто новички часто споыткаются о простой факт. Запросы вида CREATE TABLE IF NOT EXISTS создадут отсутствующую таблицу, но не изменят таблицу, если она уже существует. Даже если структура таблицы отличается от заданной. Скажем, если ты добавил автоинкремент в запрос CREATE позднее, то в реальной таблице его не будет.
В таком случае проще всего снести файл базы, чтобы она пересоздалась, и снова наполнить его данными.

Также можешь попробовать узнать реальную структуру твоей таблицы так:

SELECT sql FROM sqlite_schema WHERE type = 'table' AND name = 'customers'

Ну, как возможный вариант:
Система охлаждения неисправна (забита грязью или сломан куллер)
Пр питании от батареи в профиле стоит ограничение по потреблению CPU и система охлаждения справляется.
При наличии сети - производительность максимальная, но система охлаждения уже не тянят...

В конфиге сервера нехватает параметра
crl-verify /path/to/crl.pem

"Ответ получать быстро и от живых людей" - обычно стоит много денег, иногда неприлично много.

Тебе совсем про другое пишет, открывай доки и читай как правильно писать тег csrf_token

grub классически использует систему "MBR gap".
первый кластер содержит классический boot.img размером 442 байта, в который ничего "большого" не впихнешь.
поэтому после идет "разрыв" между первым кластером и началом первого раздела (хватает пары-тройки мегабайт) в который вписывается core.img бинарный код, динамически компилируемый грубом во время grub-install из своих модулей, для загрузки с текущего набора фс и разделов.

т.е. в boot.img содержится только загрузчик core.img.
а размер core.img уже не ограничен 442 байтами и может многое чего хитрого загрузить.

если у тебя gpt, то там вообще спец.раздел с загрузчиком, туда много чего умного впихнуть можно.

Без расшифровки HTTPS, слава богу, никак.

Если коммит уже сделали, то делайте cherry-pick в нужную ветку
https://git-scm.com/docs/git-cherry-pick

Если коммит еще не сделали, то сделайте stash изменений, переключитесь на нужную ветку и примените то, что положили в stash
https://git-scm.com/docs/git-stash

Хочу такой вариант пропустить и сразу перейти к 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 — медленное нетипизированное говно, выкинь его