Библиотека собеса по DevOps | вопросы с собеседований

COPY vs ADD? COPY для файлов из контекста. ADD ещё умеет tar-распаковку и URL — почти всегда зло. COPY предпочтительнее. ARG vs ENV? ARG виден только на этапе build (не в рантайме). ENV попадает в образ и окружение контейнера. Как уменьшить размер образа? Multi-stage builds, .dockerignore, Alpine/ubi-minimal/Distroless, объединяй RUN, чисти кеши (apt/apk) в том же слое, пинь версии. Библиотека собеса по DevOps

👀 Как вы смотрите видео? Разбираете урок, слушаете интервью фоном или начинаете на телефоне, а продолжаете на большом экране? Хотим узнать, что делает просмотр удобным для вас. Вспомните последнее видео — ролик, урок, фильм или серию сериала — и расскажите о своём опыте. Если детали не запомнились, можно так и ответить. 🕰️ Опрос займёт около 3 минут. В результатах сможете сравнить свои привычки с ответами других участников. А разработчики и инженеры видеоплатформы расскажут, что происходит по ту сторону экрана, пока вы смотрите видео. 🔗 Поделиться опытом 🐸 Библиотека программиста

Почему новый ConfigMap не изменил файл в контейнере? ConfigMap смонтирован одним файлом через subPath. Объект обновили, но приложение продолжает читать старое содержимое. Это обязательно ошибка кеша приложения? Ответ: Нет. Контейнер с ConfigMap через subPath не получает обновления этого тома. Для текущего способа монтирования потребуется пересоздать Pod. При обычном монтировании ConfigMap как каталога обновление проецируется с задержкой, но приложение ещё должно перечитать файл. Переменные окружения из ConfigMap тоже не обновляются автоматически и требуют перезапуска Pod. Сначала различите способ передачи конфигурации, затем проверяйте приложение. Обновление ConfigMap в Kubernetes

Приложение стартует три минуты. Какой probe даст ему время? Проверка liveness начинается рано и перезапускает ещё не готовый контейнер. После старта при этом нужна быстрая реакция на зависание. Что настроить? Ответ: Startup probe с бюджетом, который покрывает худшее время запуска. До её успеха liveness и readiness не выполняются. После успеха вступают в работу обычные проверки. В примере документации 30 неудач с интервалом 10 секунд дают до 300 секунд на старт. Если startup probe так и не успешна, контейнер перезапускается согласно restartPolicy. Readiness отвечает за готовность получать трафик, поэтому сама по себе не решает проблему раннего перезапуска liveness. Startup, liveness и readiness

Переименовали ресурс Terraform. Как обойтись без пересоздания? В Terraform 1.1+ поменяли только имя ресурса: aws_instance.a стал aws_instance.b. Аргументы прежние, но plan предлагает удалить объект и создать новый. Как описать переименование? Ответ: Добавить moved-блок: в from указать aws_instance.a, в to — aws_instance.b. Затем проверить новый plan. Terraform свяжет старый адрес в state с новым, и само переименование не потребует удаления объекта. Другие изменения конфигурации всё ещё могут потребовать пересоздания. В общем модуле moved стоит сохранять для пользователей, которые ещё не прошли миграцию. Переименование ресурсов в Terraform

Forbid у CronJob гарантирует выполнение ровно один раз? Расчёт запускается каждые пять минут через CronJob. Вы указали concurrencyPolicy: Forbid. Достаточно ли этого, чтобы каждый расчёт выполнился ровно один раз? Ответ: Нет. Forbid запрещает перекрытие Jobs одного CronJob. Если предыдущий Job ещё работает, новый в этот момент не запускается. После завершения возможен отложенный запуск с учётом startingDeadlineSeconds. Сам CronJob не гарантирует exactly-once: для одного времени расписания могут появиться два Job или ни одного. Обработку нужно делать идемпотентной, а внешние эффекты защищать от повторов. На Jobs других CronJob эта политика не распространяется. Политики и ограничения CronJob

A-запись появилась. Откуда всё ещё NXDOMAIN? Авторитетный DNS-сервер уже возвращает новую A-запись. Рекурсивный резолвер, к которому обращались до её создания, продолжает отвечать NXDOMAIN. Что проверить? Ответ: Отрицательный DNS-кеш: резолвер мог сохранить ответ об отсутствии имени. По RFC 2308 исходный TTL такого ответа равен меньшему из SOA.MINIMUM и TTL самой SOA. Короткий TTL новой A-записи уже сохранённый NXDOMAIN не обновляет. Сравните ответы авторитетного сервера и нужного резолвера, посмотрите оставшийся TTL SOA в секции authority. У самого резолвера могут быть дополнительные ограничения времени кеширования. RFC 2308: отрицательное кеширование DNS

Запустит ли After базу вместе с приложением? В app.service указано After=db.service. Других связей между этими юнитами нет. db.service существует, остановлен, не включён в автозапуск и не запускается другим способом. Вы запускаете только app.service. Поднимется ли db.service? Нет. After задаёт порядок запуска, когда оба юнита уже участвуют в запуске. Само по себе оно не запускает db.service. Чтобы запуск приложения подтягивал базу, нужна зависимость Wants=db.service или Requires=db.service. Если приложение не должно стартовать при неудачном запуске базы, используют Requires вместе с After. При этом After не проверяет готовность базы принимать SQL-запросы. Документация systemd

Почему PDB блокирует эвакуацию нездорового Pod? В Kubernetes 1.31+ у Deployment три реплики. PDB задаёт minAvailable: 2, но Ready только одна реплика. На ноде, которую нужно освободить, находится Pod с phase=Running и Ready=False. unhealthyPodEvictionPolicy не задана. Другие причины отказа исключены. Почему Eviction API блокирует эвакуацию этого Pod и какая политика её разрешит? По умолчанию действует IfHealthyBudget. При этой политике нездоровый Pod в phase=Running можно эвакуировать, только если currentHealthy не ниже desiredHealthy. Здесь 1 меньше 2, поэтому запрос блокируется. Значение AlwaysAllow у unhealthyPodEvictionPolicy разрешит эвакуацию этого нездорового Pod даже при нарушенном бюджете. Здоровые Pod по-прежнему защищены PDB. После эвакуации этот нездоровый Pod уже не сможет стать Ready на прежней ноде. Документация Kubernetes

Успешный COMMIT уже виден на синхронной реплике? PostgreSQL 18: у primary один синхронный standby, указанный в synchronous_standby_names. Именно он подтверждает COMMIT и обслуживает чтение. Транзакция завершилась с synchronous_commit=on. Затем клиент открывает новый снимок для SELECT на этом standby. Гарантирует ли on видимость изменения? Какой режим ждёт его применения? Нет. on ждёт, пока подтверждающий синхронный standby получит запись о COMMIT и сбросит её в долговечное хранилище. Применение WAL к этому моменту ещё не гарантировано. remote_apply дополнительно ждёт применения записи. Тогда изменение видно запросу с новым снимком на этом подтверждающем standby. Поэтому при COMMIT приходится ждать WAL replay. На произвольную асинхронную реплику или старый снимок эта гарантия не распространяется. Документация PostgreSQL 18

Сколько раз сработает run_once при serial: 2? В Ansible play шесть доступных хостов, стандартная стратегия linear и serial: 2. У одной задачи задано run_once: true. Все хосты проходят play без ошибок. У задачи нет when, повторов и делегирования. Сколько раз она выполнится за этот запуск play? Три раза: по одному запуску в каждой пачке из двух хостов. run_once действует в пределах текущей serial-пачки. Для одного запуска независимо от serial документация предлагает условие when: inventory_hostname == ansible_play_hosts_all[0]. Такая проверка всё равно не заменяет идемпотентность при повторном запуске playbook. Документация Ansible

Куда пропал файл из образа после bind mount? В Docker-образе есть /app/config/settings.yaml. На хосте Docker daemon заранее создан пустой каталог /srv/app-config. Его успешно подключили через bind mount в /app/config контейнера. Приложение больше не видит settings.yaml. Удалил ли Docker файл из образа? Нет. Bind mount перекрыл содержимое /app/config пустым каталогом хоста. Файл образа скрыт этим монтированием и остаётся в образе. Чтобы снова увидеть исходное содержимое, проще пересоздать контейнер без этого mount. Пересборка образа не поможет, пока тот же пустой каталог подключается в ту же точку. Это поведение bind mount, его нельзя переносить на новый именованный volume. Документация Docker

Что меняет слеш в значении proxy_pass? В современном NGINX выбран обычный префиксный location /api/. Нет регулярных выражений, именованных location, rewrite и переменных. Приходит GET /api/users без query string. Сначала значение proxy_pass — http://backend, затем его меняют на http://backend/. Какой путь получит upstream в каждом случае? С http://backend upstream получит /api/users. Здесь в proxy_pass нет URI, поэтому исходный путь передаётся дальше. С http://backend/ upstream получит /users. Завершающий / задаёт URI, который заменяет совпавший префикс /api/. Документация NGINX

Сохранится ли prevent_destroy после удаления resource? Terraform управляет объектом, который остаётся в state. В его resource-блоке был блок lifecycle с prevent_destroy = true. Затем весь resource-блок удалили из конфигурации. State не меняли. Заблокирует ли прежний prevent_destroy удаление объекта при новом plan? Рассматриваем только это правило, без внешних защит. Нет. prevent_destroy действует, пока присутствует в конфигурации. Удаление всего resource-блока убирает и этот запрет, поэтому Terraform может запланировать удаление объекта. Пока prevent_destroy = true остаётся в resource-блоке, Terraform отклоняет план с удалением или заменой этого объекта. Построение плана не запускает apply и ничего не удаляет. Документация Terraform

Можно ли отключить токен ServiceAccount только у одного Pod? ServiceAccount разрешает автоматическое монтирование API-токена. Один из Pod, использующих этот ServiceAccount, не должен получать токен автоматически. Можно ли настроить это, не меняя ServiceAccount для остальных Pod? Да. В spec этого Pod задайте automountServiceAccountToken: false. Если поле указано и у Pod, и у ServiceAccount, значение из Pod имеет приоритет. Это отключает автоматическое монтирование API-учётных данных в этот Pod. Настройка не меняет RBAC и не удаляет учётные данные, явно подключённые другим способом. ServiceAccount в документации Kubernetes

Почему depends_on не дождался готовности базы? В Docker Compose приложение зависит от базы через короткую форму depends_on. Контейнер базы уже запущен, но она ещё не принимает подключения. Должен ли Compose задержать запуск приложения? Нет. Короткая форма depends_on задаёт порядок запуска контейнеров, но не ждёт готовности базы. Чтобы приложение дождалось успешной проверки базы, задайте ей healthcheck, а зависимости — condition: service_healthy. Compose будет ждать прохождения именно этого healthcheck. Его нужно настроить под нужный критерий готовности базы. Если база позже перейдёт в unhealthy, это условие запуска не остановит приложение. Порядок запуска в Docker Compose

Превышение memory.high сразу приводит к OOM? В cgroup v2 расход памяти группы превысил memory.high, но остаётся ниже memory.max. Достаточно ли этого превышения, чтобы ядро немедленно убило процессы группы? Нет. Превышение memory.high само по себе не вызывает OOM killer. Процессы группы замедляются, а ядро активнее освобождает память (reclaim). memory.max задаёт жёсткий предел. Если расход достиг его и память не удаётся освободить, OOM killer вызывается внутри cgroup. Это не гарантирует немедленного завершения процессов при достижении лимита: возможны временные превышения, а некоторые виды выделения памяти не вызывают OOM killer. Контроллер памяти cgroup v2 в документации ядра