Направление DevOps

Вопросы на собеседовании по DevOps

Голосовые дуэли по DevOps: Kubernetes, Linux, сети, CI/CD, наблюдаемость и другие вопросы с обычного собеседования.

7 вопросов75 секунд на ответ15 рангов

Войти и сыграть

Тренировка и матчи доступны после входа.

Как проходит матч

Ты и соперник отвечаете на одни и те же вопросы.

01
Вопрос
В матче 7 вопросов по DevOps: Kubernetes, Linux, сети, CI/CD, наблюдаемость. Тебе и сопернику достаётся один и тот же вопрос.
02
Ответ голосом
Говоришь вслух, как на живом собеседовании. Таймер идёт у обоих одинаково. Например: зачем в Kubernetes три вида проб, liveness, readiness и startup. На ответ 75 секунд.
03
Разбор от AI
AI-судья засчитывает смысл, а не формулировку. После раунда видишь ключевые пункты: что засчитано, что упущено. Тут судья ищет, назвал ли ты, что liveness-проба перезапускает контейнер, а readiness управляет трафиком.

Пример вопроса и разбора

Так выглядят вопрос и разбор в матче. Это пример, не настоящий матч.

DevOps · Kubernetes75 секунд на ответ

Вопрос

Расскажите, зачем в Kubernetes существуют три разных вида проб — liveness, readiness и startup — и что пойдёт не так, если в манифесте пода настроить только liveness-пробу, не добавляя readiness-пробу.

Разбор AI

Засчитано 3 из 4

Liveness проверяет, жив ли процесс, и при провале kubelet перезапускает контейнер (например, при зависании/deadlock)Засчитано
Readiness определяет, готов ли под принимать трафик, и управляет включением/исключением пода из Endpoints сервиса, не перезапуская контейнерЗасчитано
Startup-проба даёт медленно стартующим приложениям время на инициализацию, откладывая проверки liveness и readiness до её первого успехаУпущено
Без readiness-пробы под считается готовым сразу после старта контейнера, и трафик может пойти в под, который ещё не готов или временно деградировал, но не убит livenessЗасчитано

Эталонный ответ

Liveness-проба проверяет, жив ли процесс внутри контейнера, и при провале kubelet перезапускает контейнер — например, при зависании или deadlock. Readiness-проба определяет, готов ли под принимать трафик, и управляет включением или исключением пода из Endpoints сервиса, не перезапуская контейнер. Startup-проба даёт медленно стартующим приложениям время на инициализацию: пока она не пройдёт успешно хотя бы раз, проверки liveness и readiness не выполняются, поэтому долгий старт не воспринимается ни как зависание, ни как неготовность. Если настроить только liveness-пробу, под по умолчанию считается готовым сразу после старта контейнера, и Kubernetes сразу начнёт направлять на него трафик через сервис — даже если приложение ещё инициализируется или временно не может обслуживать запросы, но при этом не настолько сломано, чтобы liveness посчитала его мёртвым. В результате клиенты получают ошибки в момент раскатки или временной деградации, а под никогда не исключается из балансировки.