Контейнеры и оркестрация

Все темы DevOps

За счёт чего Docker изолирует контейнеры?

Docker использует namespaces ядра для отдельных представлений процессов, сети, mount points, IPC и других ресурсов. Cgroups учитывают и ограничивают CPU, память и I/O. Capabilities позволяют убрать часть привилегий root, seccomp и LSM вроде AppArmor или SELinux ограничивают системные вызовы и доступ, а слои файловой системы дают отдельное изменяемое представление образа. Это изоляция общим ядром, а не виртуальная машина: уязвимость ядра или избыточные capabilities могут пробить границу. Поэтому нужны обновления, rootless или non-root запуск, минимальные права и запрет ненужных mounts.

Почему контейнер не следует запускать от root?

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 привилегиям хоста.

Чем livenessProbe отличается от readinessProbe?

readinessProbe отвечает, можно ли сейчас направлять трафик в контейнер. При ошибке Pod остаётся запущенным, но удаляется из ready endpoints. livenessProbe отвечает, нужно ли перезапустить контейнер; ошибочная проверка может создать цикл рестартов и усилить аварию. startupProbe даёт медленно запускающемуся приложению время и до успеха подавляет liveness и readiness. Проверки настраивают с initialDelaySeconds, periodSeconds, timeout и thresholds по реальному времени запуска и восстановления. Liveness не должна зависеть от временно недоступной внешней БД, если restart приложения не исправляет проблему.

Чем pod отличается от контейнера?

Контейнер является отдельным процессом с образом и настройками runtime. Pod является минимальной единицей развёртывания Kubernetes и содержит один или несколько тесно связанных контейнеров. Контейнеры Pod разделяют network namespace, IP и порты, могут обмениваться через localhost и подключать общие volumes. Их планируют на один node, а жизненный цикл Pod задаёт общую границу перезапуска и размещения. Sidecar уместен для тесно связанной вспомогательной функции, но обычные независимые сервисы не следует складывать в один Pod: они теряют раздельное масштабирование и выпуск.

Когда выбрать StatefulSet вместо Deployment?

StatefulSet выбирают, когда репликам нужны стабильные имена, отдельные persistent volumes и предсказуемый порядок создания, обновления или удаления, например для некоторых кластеров БД. Deployment подходит взаимозаменяемым stateless-репликам, которые можно свободно заменять и масштабировать. StatefulSet не делает приложение stateful безопасным сам по себе: репликация, quorum, backup, failover и миграции остаются ответственностью приложения или оператора. Порядок операций можно настраивать, а связность обычно опирается на headless Service. Если устойчивую идентичность и storage предоставляет внешняя система, Deployment часто остаётся проще.

Чем CMD отличается от ENTRYPOINT в Docker?

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, чтобы приложение получало сигналы.

Чем DaemonSet отличается от Deployment?

Deployment поддерживает заданное число взаимозаменяемых Pod и размещает их на доступных nodes. DaemonSet стремится запустить по одному подходящему Pod на каждом выбранном node; новые nodes получают Pod автоматически. Он подходит для node-level агентов логов, мониторинга, сети или storage. nodeSelector, affinity и tolerations ограничивают набор nodes, а стратегия обновления контролирует замену агентов. DaemonSet не нужен только ради «запустить много реплик»: для сервиса без привязки к каждому node подходит Deployment. Ресурсные requests особенно важны, потому что агент занимает место на всей группе узлов.