На ноде есть Pods под управлением DaemonSet. Что означает флаг --ignore-daemonsets в kubectl drain?

👾 — Удаляет DaemonSet из кластера
👍 — Переносит все DaemonSet Pods на соседнюю ноду
🥰 — Игнорирует PodDisruptionBudget для всех Pods
⚡️ — Пропускает их, а не удаляет

Разбор: DaemonSet Pods пропускаются и продолжают работать на ноде. Флаг не удаляет DaemonSet и не отменяет PodDisruptionBudget для других Pods.

Документация

Библиотека задач по DevOps

У Job заданы activeDeadlineSeconds=100 и backoffLimit=5. Дедлайн истёк, но лимит повторов ещё не достигнут. Что произойдёт?

👾 — Job автоматически начнётся заново с нуля
👍 — Job станет Complete, потому что повторов осталось меньше пяти
🥰 — Job завершится Failed с DeadlineExceeded
⚡️ — Job продолжит работу до пяти повторов

Разбор: Job завершится Failed с reason DeadlineExceeded. Общий дедлайн имеет приоритет над backoffLimit. Он не ждёт исчерпания повторов и не запускает Job заново.

Документация

Библиотека задач по DevOps

Terraform вернул код 2. План провалился?

В CI команда terraform plan -detailed-exitcode завершилась с кодом 2. Что он означает?

👾 — План построен успешно и содержит изменения
👍 — Terraform уже применил два изменения
🥰 — Возникла ошибка построения плана
⚡️ — План построен успешно, изменений нет

Разбор: Верно 👾. С флагом -detailed-exitcode код 0 означает успех без изменений, 1 — ошибку, 2 — успех с изменениями. Команда plan их не применяет. Проверка CI «любой ненулевой код — ошибка» в этом режиме даст ложное падение.

Документация

Библиотека задач по DevOps

Что отменит cancel-in-progress: true?

В GitHub.com Actions на уровне workflow задано:

concurrency:
  group: deploy-main
  cancel-in-progress: true

Предыдущий запуск ещё выполняется. В том же репозитории появился новый запуск с той же группой. Что произойдёт с предыдущим?

👾 — Продолжится, а новый запуск будет отклонён
👍 — Продолжится параллельно с новым
🥰 — Будет отменён
⚡️ — Дойдёт до конца, отменяются только pending-запуски

Разбор: Верно 🥰. Флаг включает отмену уже выполняющегося запуска с той же concurrency group. Без него concurrency ограничивает параллельность, но не отменяет running-запуск. Отмена не означает откат уже выполненных внешних действий, например деплоя.

Документация

Библиотека задач по DevOps

Что вернёт absent() при значении метрики 0?

В момент запроса серия up{job="api",instance="a:9100"} существует и имеет значение 0. Других серий с job="api" нет. Каков результат absent(up{job="api"})?

👾 — Одна серия со значением 1
👍 — Исходная серия со значением 0
🥰 — Ошибка из-за нулевого значения
⚡️ — Пустой вектор

Разбор: Верно ⚡️. absent() проверяет наличие элементов во входном векторе, а не их значения. Серия со значением 0 всё равно существует, поэтому результат пуст. Одноэлементный вектор со значением 1 функция возвращает при пустом входе.

Документация

Библиотека задач по DevOps

Станет ли | конвейером в Ansible command?

Обычный запуск задачи в ansible-core 2.18 на POSIX-узле, где доступна внешняя программа echo:

ansible.builtin.command: echo hello | wc -c

Как будет обработан символ |?

👾 — Соединит echo с wc, результатом станет число 6
👍 — Попадёт в аргументы echo вместе с wc и -c
🥰 — Разделит echo и wc на две отдельные команды
⚡️ — Вызовет ошибку YAML, задача не запустится

Разбор: Верно 👍. command запускает программу без shell. Здесь |, wc и -c станут аргументами echo, а wc не запустится. Для shell-конвейера нужен ansible.builtin.shell. Подставляемые значения при этом требуют корректного экранирования.

Документация

Библиотека задач по DevOps

Что останется после rm открытого файла?

В Linux у обычного файла в локальной файловой системе одно имя, других жёстких ссылок нет. Процесс открыл файл для чтения. Затем rm успешно удалил его имя, но дескриптор ещё открыт. Какое утверждение верно?

👾 — Имя исчезло, а через открытый дескриптор ещё можно читать
👍 — rm закрыл дескриптор в другом процессе
🥰 — Имя останется в каталоге до завершения процесса
⚡️ — Любое чтение через дескриптор теперь завершится ENOENT

Разбор: Верно 👾. Удаляется имя файла, а открытый файл продолжает существовать. Процесс может читать через свой дескриптор. При отсутствии других ссылок файл удаляется окончательно после закрытия последнего открытого дескриптора. Поэтому удаление имени и завершение работы с файлом — разные события.

Документация

Библиотека задач по DevOps

Какой CPU request получит Pod с init-контейнерами?

У Pod два контейнера приложения с CPU requests 200m и 300m. У двух обычных init-контейнеров — 800m и 100m. Это итоговые requests после admission. Sidecar нет, Pod-level requests не заданы, overhead равен нулю. Какой эффективный CPU request учитывается при размещении Pod?

👾 — 500m
👍 — 900m
🥰 — 800m
⚡️ — 1400m

Разбор: Верно 🥰. Обычные init-контейнеры идут последовательно, их эффективный request — максимум: 800m. У приложений requests складываются: 200m + 300m = 500m. Для Pod берётся большее: max(800m, 500m) = 800m. Это запрос ресурсов для размещения, а не фактическая загрузка CPU.

Документация

Библиотека задач по DevOps

Останется ли разрешён вход на TCP/80 после добавления NetworkPolicy с ingress: []?

В Kubernetes используется networking.k8s.io/v1, CNI применяет NetworkPolicy. Первая Ingress-политика разрешает вход на TCP/80 к целевому Pod от Pod с app=frontend. Затем к тому же целевому Pod добавляют вторую Ingress-политику с ingress: []. Других политик для цели нет.

Обе политики уже действуют. Подключается обычный Pod с app=frontend, а не нода. Его egress и остальные сетевые настройки соединению не мешают.

👾 Нет, последняя политика отменит предыдущее разрешение
👍 Да, разрешения применимых Ingress-политик складываются
🥰 Нет, две политики для одного Pod заблокируют весь вход
⚡️ Да, и вместе с TCP/80 откроются все остальные порты

Разбор:
👍 Разрешение TCP/80 сохранится. В каждом направлении объединяются разрешения всех применимых NetworkPolicy. Пустой ingress не добавляет разрешений и не отменяет разрешения другой политики. Порядок создания здесь не задаёт приоритет. Остальные порты от этого не откроются.

Документация

Библиотека задач по DevOps

Какой файл исключений выберет docker build -f build.Dockerfile .?

Используется современный Docker BuildKit с поддержкой отдельных ignore-файлов для Dockerfile. Из корня проекта выполняют:

docker build -f build.Dockerfile .

В том же корне лежат .dockerignore со строкой secrets/ и build.Dockerfile.dockerignore со строкой logs/. Оба каталога существуют, других правил нет. Какие исключения применятся к контексту сборки?

👾 Только правила корневого .dockerignore
👍 Объединение правил обоих файлов
🥰 Только правила build.Dockerfile.dockerignore
⚡️ Никакие, потому что указан флаг -f

Разбор:
🥰 Применится build.Dockerfile.dockerignore. Отдельный ignore-файл для выбранного Dockerfile имеет приоритет над корневым, а не дополняет его. Поэтому logs/ будет исключён, а правило secrets/ из корневого .dockerignore в этой сборке не сработает.

Документация

Библиотека задач по DevOps

Что запланирует Terraform, если удалить resource-блок вместе с prevent_destroy?

Ресурс существует в state и в инфраструктуре. В его конфигурации был блок:

lifecycle {
  prevent_destroy = true
}

Теперь целиком удалили resource-блок, включая lifecycle, и запускают обычный terraform plan. Блок removed не добавляли, terraform state rm не выполняли. Внешней защиты от удаления и других ограничений нет.

👾 Удаление инфраструктурного объекта
👍 Ошибку, потому что prevent_destroy сохранён в state
🥰 Только удаление записи из state, с сохранением объекта
⚡️ Создание второго объекта взамен прежнего

Разбор:
👾 План будет содержать удаление объекта. prevent_destroy защищает его, пока это правило есть в конфигурации. После удаления всего resource-блока правило исчезает вместе с ним. Сам plan объект ещё не удаляет. Удаление произойдёт при применении плана.

Документация

Библиотека задач по DevOps

Миграция с VMware, домашний кластер, выросший из одного ноутбука, и ИИ для работы с инцидентами

Всё это на митапе Deckhouse User Community 12 ноября в Москве.

В программе три доклада:
— опыт НИУ «МИЭТ»: как университет переходит с VMware на виртуализацию Deckhouse — от пилота до миграции ВМ и резервного копирования;
— 13 лет домашней инфраструктуры: от одного ноутбука до геораспределённого кластера из нескольких квартир и дата-центров;
— IncidentGPT на практике: от участия в Open Source-проекте до внедрения в компании, а заодно переход с Prometheus на Deckhouse Prom++ ради экономии памяти.

Нетворкинг после основной программы тоже будет. :)

Где: People Loft, 1-я улица Энтузиастов, д. 12 (метро и D3 «Авиамоторная»).
Когда: 12 ноября, начало в 19:00. Сбор в 18:15, приходите! Возьмите с собой паспорт или водительское удостоверение.

Митап пройдёт только офлайн. Для участия зарегистрируйтесь на Timepad и дождитесь письма-подтверждения.

Какие значения вернут сравнения PromQL без bool и с bool?

В момент instant query существует ровно одна float-серия queue_depth{job="worker"} со значением 7. Native histogram нет. Выполняют два запроса:

queue_depth{job="worker"} > 5
queue_depth{job="worker"} > bool 5

Нужны только числовые значения единственного элемента каждого результата, в указанном порядке. Имена метрик и labels не рассматриваем.

👾 1 и 1
👍 1 и 7
🥰 Пустой вектор и 1
⚡️ 7 и 1

Разбор:
⚡️ Получатся 7 и 1. Без bool сравнение работает как фильтр: 7 > 5 истинно, поэтому серия остаётся со своим значением 7. С bool истинное сравнение даёт 1, ложное дало бы 0. Модификатор также убирает имя метрики, но вопрос только о числах.

Документация

Библиотека задач по DevOps

Какой доступ к issues останется у GITHUB_TOKEN при permissions: { contents: read }?

GitHub.com Actions, обычный push в свой репозиторий. Используется стандартный GITHUB_TOKEN, без PAT и токена GitHub App. На уровне workflow задано:

permissions:
  contents: read

У job собственного permissions нет. Какой эффективный уровень issues получит токен этой job? Анонимное чтение публичных данных и служебное разрешение metadata не рассматриваем.

👾 read, потому что contents: read даёт чтение всех API
👍 none, потому что неуказанные permissions получают none
🥰 write, если push сделал администратор репозитория
⚡️ Прежний default репозитория без изменений

Разбор:
👍 У issues будет none. Если явно задать хотя бы одно разрешение в permissions, остальные неуказанные разрешения получают none. contents: read даёт чтение содержимого репозитория, но не issues. Права пользователя, сделавшего push, не добавляются к GITHUB_TOKEN автоматически.

Документация

Библиотека задач по DevOps

Сколько раз выполнится handler после двух notify в Ansible?

Один play, один host, обычные последовательные tasks. Две задачи завершились с changed: true и обе уведомили один и тот же handler Restart app. Handler с этим именем определён только один раз.

Нет pre_tasks, post_tasks, meta: flush_handlers, ошибок, других plays и повторных фаз обработки. Раньше handler не выполнялся. Сколько запусков будет при обычной обработке handlers после этих tasks?

👾 Ноль, два уведомления отменят друг друга
👍 Два, сразу после каждой changed-задачи
🥰 Один, повторные уведомления объединятся
⚡️ Один или два, в зависимости от порядка notify

Разбор:
🥰 Handler выполнится один раз после tasks. В этой фазе повторные уведомления одного handler не вызывают дополнительных запусков. После отдельной обработки handlers его можно уведомить заново, но flush_handlers и повторные фазы исключены условиями.

Документация

Библиотека задач по DevOps

Запустит ли After=db.service саму db.service?

Linux с systemd. Обычные app.service и db.service валидны и доступны, оба сейчас inactive. У app.service в секции [Unit] задано только:

After=db.service

Нет Wants, Requires, BindsTo, других зависимостей или путей активации db.service. Выполняется только команда systemctl start app.service, параллельных запросов старта нет. Запустится ли db.service?

👾 Да, systemd сначала запустит db.service
👍 Да, одновременно с app.service
🥰 Нет, а app.service обязательно завершится ошибкой зависимости
⚡️ Нет, After задаёт порядок, но не запрашивает запуск db.service

Разбор:
⚡️ db.service останется inactive. After задаёт порядок, если оба unit участвуют в запуске, но сам не добавляет второй unit в транзакцию. Зависимости Wants и Requires решают отдельную задачу: включают другой unit в запуск. Одного After для этого недостаточно.

Документация

Библиотека задач по DevOps

Что останется от истории Deployment с revisionHistoryLimit: 0 после успешного завершения rollout и очистки истории?

👾 — Предыдущие ReplicaSet сохранятся без ограничения
👍 — Deployment автоматически вернётся к предыдущему образу
🥰 — Сохранится ReplicaSet текущей ревизии, старые будут удалены
⚡ — Удалится сам Deployment вместе с Pod

Разбор:
🥰. Старые ReplicaSet хранят ревизии для отката. При нулевом лимите контроллер удаляет их после завершения rollout. Очистка идёт в фоне. По условию она уже завершилась. Текущая ревизия продолжает работать, а откат к удалённым ревизиям по истории Deployment недоступен.

Документация

Библиотека задач по DevOps

Когда при первоначальном запуске Docker Compose создаст web, если для его зависимости db задано condition: service_healthy и у db настроен healthcheck?

👾 — После того как healthcheck db сообщит healthy
👍 — Сразу после запуска процесса db
🥰 — Только после остановки db
⚡ — После первого запроса от web к db

Разбор:
👾. Compose ждёт успешной проверки healthcheck у зависимости с service_healthy и затем создаёт зависимый сервис. Самого запуска процесса db недостаточно. Условие относится к начальному запуску и не задаёт автоматическую остановку web, если db позднее станет unhealthy.

Документация

Библиотека задач по DevOps

Что сделает Terraform 1.5 или новее, если условие в assert внутри блока check окажется ложным (false)?

👾 — Остановит текущую операцию с ошибкой
👍 — Удалит ресурс, который проверяет check
🥰 — Автоматически применит обратный план
⚡ — Выдаст предупреждение и продолжит текущую операцию

Разбор:
⚡. Неуспешный assert в check выдаёт предупреждение и сам по себе не останавливает plan или apply. Блоки precondition и postcondition могут блокировать выполнение. Ошибки провайдера здесь не рассматриваются.

Документация

Библиотека задач по DevOps