Приходилось ли писать манифесты и чарты для Kubernetes
Что проверяют
Насколько далеко тянется ваша ответственность за сервис. От Python-разработчика не ждут навыков инженера платформы, но ждут, что вы опишете, как приложение должно запускаться, и не оставите очевидных ловушек вроде миграций, стартующих одновременно на каждой реплике.
Как отвечать
Перечислите объекты, которые описываете сами: Deployment с репликами и стратегией обновления, Service, при необходимости Ingress, ConfigMap и Secret для настроек, пробы, requests и limits, а для периодических задач CronJob. Если используете Helm, скажите про структуру чарта: шаблоны, values.yaml с отличиями окружений, проверка результата рендером до применения.
Дальше специфика Python, в ней и есть содержание ответа:
- веб-приложение запускается сервером приложений с несколькими воркерами, и число воркеров согласуют с лимитом процессора, иначе воркеры отбирают время друг у друга;
- воркеры фоновых задач это отдельный Deployment без Service, со своим числом реплик и своим лимитом памяти;
- корректное завершение: по сигналу воркер должен доработать текущую задачу, а на это нужен запас по времени в настройках пода;
- миграции схемы выносятся в отдельную разовую задачу, привязанную к выкату, а не запускаются при старте приложения.
Хорошо, если добавите про конфигурацию: настройки приходят из окружения, секреты из хранилища, а не из файла значений в репозитории.
Где спотыкаются
Запускают миграции в стартовом контейнере пода. При нескольких репликах они стартуют параллельно и дерутся за блокировки, а при откате версии получается схема, несовместимая со старым кодом.
Ставят в liveness ту же ручку, что ходит в базу и в соседние сервисы. Одна медленная зависимость перезапускает весь сервис целиком. Проба живости отвечает, жив ли процесс, готовность к трафику это readiness.
Хранят пароли в файле значений чарта рядом с кодом. Кодирование в Secret это не шифрование, а способ записи данных, и любой, у кого есть доступ к репозиторию или к пространству имён, эти пароли прочитает.