--- title: Контейнеры и оркестрация questionDates: q-transfer-0414: '2026-10-01' q-transfer-0415: '2026-10-01' q-transfer-0416: '2026-10-01' q-transfer-0417: '2026-10-01' q-transfer-0418: '2026-10-01' q-transfer-0428: '2026-10-01' q-transfer-0429: '2026-10-01' seo: description: >- Тема «Контейнеры и оркестрация» для собеседования DevOps. За счёт чего Docker изолирует контейнеры? Почему контейнер не следует запускать от root? title: Контейнеры и оркестрация — DevOps --- [Все темы DevOps](/prep/devops) ## За счёт чего Docker изолирует контейнеры? [#q-transfer-0414] Docker использует namespaces ядра для отдельных представлений процессов, сети, mount points, IPC и других ресурсов. Cgroups учитывают и ограничивают CPU, память и I/O. Capabilities позволяют убрать часть привилегий root, seccomp и LSM вроде AppArmor или SELinux ограничивают системные вызовы и доступ, а слои файловой системы дают отдельное изменяемое представление образа. Это изоляция общим ядром, а не виртуальная машина: уязвимость ядра или избыточные capabilities могут пробить границу. Поэтому нужны обновления, rootless или non-root запуск, минимальные права и запрет ненужных mounts. :::note[Ссылки для изучения] 1. [Как контейнеры изолируются: namespaces, cgroups и общее ядро](https://selectel.ru/blog/what-is-containerization/) 1. [Docker: capabilities, mounts и профили безопасности](https://habr.com/ru/companies/selectel/articles/815803/) ::: --- ## Почему контейнер не следует запускать от root? [#q-transfer-0415] Root внутри обычного контейнера имеет UID 0 и при ошибочной конфигурации, лишних capabilities, hostPath или уязвимости runtime получает больший ущерб. В образе создают отдельного пользователя и задают `USER`, права на файлы выдают только нужным UID/GID. В runtime включают `runAsNonRoot`, запрещают privilege escalation, удаляют capabilities и по возможности используют read-only root filesystem. Сам `USER` не решает всё: процессу могут оставить опасный socket Docker или привилегированный mount. Rootless containers и user namespaces дополнительно уменьшают соответствие container root привилегиям хоста. :::note[Ссылки для изучения] 1. [Non-root в Dockerfile: отдельный пользователь, права файлов и USER](https://selectel.ru/blog/docker-security-2/) 1. [Ограничение привилегий Docker-контейнера и профили безопасности](https://habr.com/ru/companies/selectel/articles/815803/) ::: --- ## Чем livenessProbe отличается от readinessProbe? [#q-transfer-0416] `readinessProbe` отвечает, можно ли сейчас направлять трафик в контейнер. При ошибке Pod остаётся запущенным, но удаляется из ready endpoints. `livenessProbe` отвечает, нужно ли перезапустить контейнер; ошибочная проверка может создать цикл рестартов и усилить аварию. `startupProbe` даёт медленно запускающемуся приложению время и до успеха подавляет liveness и readiness. Проверки настраивают с `initialDelaySeconds`, `periodSeconds`, timeout и thresholds по реальному времени запуска и восстановления. Liveness не должна зависеть от временно недоступной внешней БД, если restart приложения не исправляет проблему. :::note[Ссылки для изучения] 1. [Kubernetes: настройка liveness, readiness и startup probes](https://kubernetes.io/ru/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) 2. [Разница livenessProbe и readinessProbe. BAKAVETS, с 16:38](https://www.youtube.com/watch?v=BgADHZ2JTUM&t=998s) ::: --- ## Чем pod отличается от контейнера? [#q-transfer-0417] Контейнер является отдельным процессом с образом и настройками runtime. Pod является минимальной единицей развёртывания Kubernetes и содержит один или несколько тесно связанных контейнеров. Контейнеры Pod разделяют network namespace, IP и порты, могут обмениваться через `localhost` и подключать общие volumes. Их планируют на один node, а жизненный цикл Pod задаёт общую границу перезапуска и размещения. Sidecar уместен для тесно связанной вспомогательной функции, но обычные независимые сервисы не следует складывать в один Pod: они теряют раздельное масштабирование и выпуск. :::note[Ссылки для изучения] 1. [Поды Kubernetes: контейнеры, общая сеть и хранилище](https://kubernetes.io/ru/docs/concepts/workloads/pods/) 2. [Pod как единица запуска контейнеров. Артём Шумейко, с 13:56](https://www.youtube.com/watch?v=TwyhnBDOHPw&t=836s) ::: --- ## Когда выбрать StatefulSet вместо Deployment? [#q-transfer-0418] StatefulSet выбирают, когда репликам нужны стабильные имена, отдельные persistent volumes и предсказуемый порядок создания, обновления или удаления, например для некоторых кластеров БД. Deployment подходит взаимозаменяемым stateless-репликам, которые можно свободно заменять и масштабировать. StatefulSet не делает приложение stateful безопасным сам по себе: репликация, quorum, backup, failover и миграции остаются ответственностью приложения или оператора. Порядок операций можно настраивать, а связность обычно опирается на headless Service. Если устойчивую идентичность и storage предоставляет внешняя система, Deployment часто остаётся проще. :::note[Ссылки для изучения] 1. [StatefulSet и Deployment: идентичность, тома и эксплуатация БД в Авито](https://habr.com/ru/companies/avito/articles/881728/) ::: --- ## Чем CMD отличается от ENTRYPOINT в Docker? [#q-transfer-0428] `ENTRYPOINT` задаёт основной исполняемый файл контейнера, а `CMD` передаёт ему аргументы по умолчанию либо становится командой, если `ENTRYPOINT` нет. Аргументы после имени образа в `docker run` заменяют `CMD`; сам `ENTRYPOINT` меняют через `--entrypoint`. В exec form массив запускается без shell и лучше передаёт сигналы процессу. Shell form идёт через `/bin/sh -c`, влияет на подстановки, аргументы и PID 1. Частый шаблон: стабильный exec-form `ENTRYPOINT` и переопределяемый exec-form `CMD`. Скрипт entrypoint должен завершаться `exec`, чтобы приложение получало сигналы. :::note[Ссылки для изучения] 1. [Docker CMD и ENTRYPOINT: переопределение, shell/exec и сигналы](https://habr.com/ru/companies/nixys/articles/830830/) ::: --- ## Чем DaemonSet отличается от Deployment? [#q-transfer-0429] Deployment поддерживает заданное число взаимозаменяемых Pod и размещает их на доступных nodes. DaemonSet стремится запустить по одному подходящему Pod на каждом выбранном node; новые nodes получают Pod автоматически. Он подходит для node-level агентов логов, мониторинга, сети или storage. `nodeSelector`, affinity и tolerations ограничивают набор nodes, а стратегия обновления контролирует замену агентов. DaemonSet не нужен только ради «запустить много реплик»: для сервиса без привязки к каждому node подходит Deployment. Ресурсные requests особенно важны, потому что агент занимает место на всей группе узлов. :::note[Ссылки для изучения] 1. [Kubernetes DaemonSet: по одному Pod на выбранном узле](https://kubernetes.io/ru/docs/concepts/workloads/controllers/daemonset/) 2. [DaemonSet и экземпляр на каждой ноде. Артём Шумейко, с 23:35](https://www.youtube.com/watch?v=TwyhnBDOHPw&t=1415s) :::