Docker и Kubernetes на собеседовании: глубокий разбор вопросов и сценариев

Введение: зачем глубоко знать контейнеризацию в 2026 году

К 2026 году рынок облачных вычислений окончательно перешел на модель Serverless Kubernetes и Managed Container Services. Если пять лет назад на собеседовании достаточно было знать разницу между образом и контейнером, то сегодня от кандидата ждут понимания работы CRI (Container Runtime Interface), механизмов eBPF для мониторинга сети и специфики работы с эфемерными хранилищами. Компании ищут инженеров, которые могут не только запустить приложение, но и оптимизировать потребление ресурсов в условиях жестких квот.

Эта статья структурирована как справочник-интенсив. Мы пройдем путь от низкоуровневых механизмов ядра Linux, на которых строится Docker, до сложных паттернов развертывания в кластерах Kubernetes. Материал разбит на 12 тематических блоков, каждый из которых закрывает определенную область знаний, проверяемую на интервью. Вы узнаете, как отвечать на каверзные вопросы про зомби-процессы в контейнерах, зачем нужен Sidecar-контейнер в эпоху Service Mesh и как бороться с «шумными соседями» в мультиарендных кластерах.

Для кого этот материал

Статья ориентирована на DevOps-инженеров, SRE, системных администраторов и Backend-разработчиков. Мы опускаем базовые вещи вроде установки Docker Desktop и сразу переходим к «подкапотным» процессам. Если вы претендуете на зарплату выше среднего по рынку, вы должны понимать, как планировщик Kubernetes принимает решения и почему ваш контейнер может быть убит по OOM (Out of Memory), даже если лимиты выставлены корректно.

1. Архитектура Docker и механизмы изоляции ядра

Один из самых частых вопросов на интервью: «Является ли Docker технологией виртуализации?». Правильный ответ — нет, это технология контейнеризации, использующая общую ОС. В 2026 году важно уточнять, что Docker — это высокоуровневый интерфейс над средой выполнения (runtime). Основу составляют пространства имен (Namespaces) и контрольные группы (Cgroups). Без понимания этих концепций невозможно объяснить, как процессы внутри контейнера отделены друг от друга.

Namespaces: создание иллюзии владения ресурсами

Namespaces отвечают за то, что процесс «видит». Существует несколько ключевых типов пространств имен, которые вы должны перечислить. PID namespace изолирует дерево процессов, поэтому процесс с ID 1 в контейнере — это не тот же PID 1 на хосте. NET namespace дает контейнеру собственный сетевой стек, включая IP-адрес и таблицу маршрутизации. MNT namespace позволяет монтировать файловые системы, не влияя на хостовую ОС. На интервью могут спросить про User Namespace — это механизм, позволяющий root-пользователю внутри контейнера иметь права обычного пользователя на хосте, что критично для безопасности.

Cgroups: управление жадностью процессов

Если Namespaces ограничивают видимость, то Control Groups ограничивают потребление. В 2026 году актуальна версия cgroups v2, которая обеспечивает более плавное управление ресурсами. С помощью cgroups ядро ограничивает использование CPU, RAM, I/O и сетевой полосы пропускания. Типичный вопрос: «Что произойдет, если процесс в контейнере превысит memory limit?». Ответ: ядро вызовет OOM Killer, и процесс будет немедленно завершен. В случае с CPU процесс просто будет «придушен» (throttling), но продолжит работу.

2. Оптимизация Docker-образов: от слоев до Multi-stage

На собеседовании часто просят провести ревью Dockerfile. Основная претензия обычно — огромный размер образа. В 2026 году стандартом считается использование минималистичных базовых образов, таких как Alpine или Distroless. Важно понимать концепцию слоев: каждая инструкция (RUN, COPY, ADD) создает новый слой. Если вы установили пакет и удалили кэш в разных инструкциях RUN, размер образа не уменьшится, так как кэш останется в предыдущем слое.

Multi-stage builds как стандарт индустрии

Использование нескольких стадий (stages) позволяет разделить среду сборки и среду выполнения. В первой стадии мы устанавливаем компиляторы, зависимости и собираем бинарный файл. Во второй стадии мы копируем только готовый артефакт в чистый образ. Это позволяет сократить размер образа с 1.5 ГБ (например, для Java-приложения) до 100-150 МБ. На интервью стоит упомянуть, что это не только экономит место на диске, но и уменьшает поверхность атаки, так как в финальном образе нет лишних утилит.

Порядок инструкций и кэширование

Docker кэширует слои. Если вы изменили файл, на который ссылается инструкция COPY, Docker пересоберет этот слой и все последующие. Поэтому правило хорошего тона — сначала копировать файлы со списком зависимостей (package.json, go.mod), запускать установку зависимостей, и только потом копировать исходный код. Это позволяет не скачивать библиотеки заново при каждом изменении одной строки кода.

# Пример эффективного Dockerfile 2026
FROM golang:1.24-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o main .

FROM scratch
COPY --from=builder /app/main /main
ENTRYPOINT ["/main"]

3. Сетевое взаимодействие в Docker: Bridge, Host, Overlay

Вопросы по сети часто ставят в тупик. Начните с объяснения стандартного драйвера Bridge. По умолчанию Docker создает виртуальный мост (обычно docker0), к которому подключаются контейнеры. Каждый контейнер получает внутренний IP. Но как они общаются с внешним миром? Через NAT (Network Address Translation). На интервью могут спросить про разницу между `--net=host` и `--net=bridge`. Режим host убирает сетевую изоляцию: контейнер использует порты хоста напрямую, что дает выигрыш в производительности, но снижает безопасность.

Overlay-сети и Docker Swarm/K8s

Если речь заходит о распределенных системах, всплывают Overlay-сети. Они позволяют контейнерам на разных физических хостах общаться так, будто они находятся в одной локальной сети. Это реализуется через инкапсуляцию пакетов (например, VXLAN). В 2026 году на замену многим стандартным решениям пришел eBPF-based networking (например, через Cilium), который работает быстрее за счет обработки пакетов напрямую в ядре, минуя стандартный стек iptables.

Публикация портов и Service Discovery

Как работает `-p 8080:80`? Docker использует iptables для проброса трафика. Важно понимать, что если вы не укажете IP при публикации порта, Docker привяжется к 0.0.0.0, что может быть небезопасно. В современных системах для обнаружения сервисов (Service Discovery) используются внутренние DNS-серверы Docker, которые позволяют обращаться к контейнерам по их именам внутри одной сети.

4. Безопасность контейнеров: Rootless и Сканирование

Безопасность — критическая тема в 2026 году. Первый вопрос: «Почему запускать процессы от root внутри контейнера — плохая идея?». Ответ связан с возможностью Container Escape. Если злоумышленник взломает приложение и выйдет за пределы контейнера, он получит права root на хосте. Решение — использование инструкции `USER` в Dockerfile или переход на Rootless Docker, где даже демон Docker работает от обычного пользователя.

Сканирование уязвимостей (CVE)

Кандидат должен знать инструменты сканирования образов, такие как Trivy, Grype или встроенные сканеры в реестрах (Harbor, AWS ECR). В 2026 году в CI/CD пайплайны обязательно встраивается этап блокировки сборки, если обнаружены критические уязвимости. Также стоит упомянуть SBOM (Software Bill of Materials) — это паспорт образа, содержащий список всех библиотек и их версий, что упрощает аудит безопасности.

Read-only файловая система и Capabilities

Еще один продвинутый метод защиты — запуск контейнера с `--read-only` флагом. Это запрещает любые изменения в файловой системе контейнера во время выполнения. Также важно понимать Linux Capabilities. Вместо того чтобы давать процессу полные права root, мы можем дать только специфические разрешения, например `NET_ADMIN` для настройки сети, используя флаги `--cap-add` или `--cap-drop`.

• Никогда не храните секреты в переменных окружения Dockerfile.
• Используйте Docker Secrets или внешние хранилища (Vault).
• Регулярно обновляйте базовые образы для получения патчей безопасности.
• Ограничивайте доступ к Docker Socket (/var/run/docker.sock).

5. Kubernetes: Компоненты Control Plane и Worker Nodes

Переходим к Kubernetes. Первый вопрос на Senior-позицию: «Опишите путь запроса при создании Pod». Вы должны четко представлять взаимодействие компонентов. Пользователь отправляет YAML через `kubectl`, запрос попадает в `kube-apiserver`. API-сервер проверяет права и записывает данные в `etcd`. `kube-scheduler` видит новый Pod без назначенного узла, выбирает подходящий хост и обновляет запись. `kubelet` на целевом узле замечает изменение, вызывает Container Runtime для запуска контейнеров и рапортует о статусе.

Etcd: сердце кластера

Etcd — это распределенное хранилище типа ключ-значение. На интервью спросят про консистентность и алгоритм Raft. Важно помнить, что если etcd «упадет» или потеряет кворум, кластер перейдет в состояние Read-only: существующие приложения продолжат работать, но внести изменения (масштабировать, обновить) будет невозможно. Поэтому в продакшене всегда используют нечетное количество узлов etcd (3 или 5).

Kube-proxy и сетевые политики

Kube-proxy отвечает за поддержание сетевых правил на узлах. Раньше он работал в основном на iptables, но в 2026 году стандартом стал режим IPVS или использование eBPF. Он обеспечивает работу абстракции Service, перенаправляя трафик на нужные Pods. Если вас спросят, как изолировать трафик между отделами, отвечайте — Network Policies. Это встроенный механизм фаервола в K8s, который работает на уровне L3/L4.

6. Жизненный цикл Pod: Пробы и Статусы

Pod — это минимальная единица развертывания. Важно понимать, что Pod может содержать несколько контейнеров (паттерны Sidecar, Ambassador). Вопрос с подвохом: «В чем разница между Liveness, Readiness и Startup пробами?». Если вы ошибетесь в настройке, ваше приложение может попасть в бесконечный цикл перезагрузок или начать получать трафик до того, как будет готово.

Liveness vs Readiness vs Startup

Liveness probe проверяет, живо ли приложение. Если проверка провалена, K8s убивает контейнер и запускает новый. Readiness probe определяет, готово ли приложение принимать трафик. Если она не проходит, Pod исключается из балансировщика Service, но не перезагружается. Startup probe нужна для тяжелых приложений, которые долго стартуют; она блокирует остальные проверки на время запуска. В 2026 году также часто используют gRPC для проб вместо обычного HTTP GET.

Статусы Pod и причины сбоев

Вы обязаны знать основные статусы: Pending (планировщик ищет узел), Running, Succeeded, Failed и Unknown. Но интереснее причины ошибок: `CrashLoopBackOff` (приложение падает сразу после старта), `ImagePullBackOff` (неверные учетные данные или имя образа), `OOMKilled` (превышен лимит памяти). Понимание этих кодов позволяет быстро диагностировать проблемы на «живом» кластере во время технического интервью.

7. Контроллеры: Deployment, StatefulSet, DaemonSet

Зачем нужен Deployment, если есть Pod? Потому что Pod эфемерен. Deployment обеспечивает декларативное обновление и самовосстановление. Если узел упадет, Deployment пересоздаст Pod на другом узле. На интервью часто просят сравнить разные типы контроллеров. Например, DaemonSet гарантирует запуск ровно одной копии Pod на каждом узле (подходит для сбора логов или мониторинга).

StatefulSet: работа с состоянием

StatefulSet используется для баз данных (PostgreSQL, MongoDB). В отличие от Deployment, здесь каждый Pod имеет стабильный идентификатор (pod-0, pod-1) и постоянное хранилище (Persistent Volume), которое переподключается к тому же индексу при перезагрузке. Это критично для кластеризации БД, где важен порядок запуска и уникальность имен узлов.

Job и CronJob: разовые задачи

Для фоновых задач, таких как генерация отчетов или миграция базы данных, используются Job (выполнить один раз и завершить) и CronJob (выполнять по расписанию). В 2026 году хорошим тоном считается использование `ttlSecondsAfterFinished` для автоматической очистки завершенных задач, чтобы не засорять историю кластера.

8. Управление ресурсами и планирование (Scheduling)

Как Kubernetes решает, куда поместить ваш Pod? Планировщик проходит через две стадии: Filtering (отсеивание узлов, где нет ресурсов) и Scoring (ранжирование оставшихся узлов). На собеседовании могут спросить про механизмы управления этим процессом: NodeSelector, Affinity/Anti-Affinity и Taints/Tolerations.

Taints и Tolerations: «отталкивание» и «терпимость»

Taints вешаются на узлы, чтобы запретить на них запуск определенных Pods. Например, мы можем пометить узлы с GPU, чтобы там не запускались обычные веб-серверы. Чтобы Pod все-таки попал на такой узел, у него должен быть соответствующий Toleration. Это механизм «отталкивания». Напротив, Node Affinity — это механизм «притяжения», позволяющий указать предпочтения или жесткие требования к характеристикам узла.

Requests и Limits: в чем разница?

Это база. Request — это то, что гарантированно резервируется для контейнера. Scheduler использует это значение для выбора узла. Limit — это потолок. Если Request установлен в 256MB, а Limit в 512MB, приложение может кратковременно потреблять больше 256MB, если на узле есть свободная память. Но если оно попытается взять больше 512MB — оно будет убито. В 2026 году для динамического управления этими параметрами часто используют VPA (Vertical Pod Autoscaler).

9. Хранение данных: PV, PVC и StorageClass

Контейнеры по своей природе не имеют состояния (stateless). Чтобы сохранить данные после перезагрузки, нужны тома. В K8s это реализовано через абстракцию Persistent Volume (PV) — физический кусок диска, и Persistent Volume Claim (PVC) — запрос пользователя на этот диск. Разделение нужно для того, чтобы разработчик не думал о том, где именно лежит диск (на AWS, Azure или локальной СХД).

Динамическое выделение ресурсов

В современных кластерах никто не создает PV вручную. Используется StorageClass. Когда разработчик создает PVC, StorageClass автоматически «нарезает» нужный объем на облачном диске и создает PV. На интервью могут спросить про Access Modes: ReadWriteOnce (доступ только с одного узла), ReadWriteMany (с нескольких узлов одновременно, например NFS) и ReadOnlyMany. Понимание этих режимов важно при проектировании отказоустойчивых систем.

Эфемерные тома и ConfigMaps

Не все данные нужно хранить вечно. EmptyDir живет столько же, сколько Pod, и полезен для временных файлов или кэша. ConfigMap и Secret — это специальные типы томов, которые позволяют пробрасывать конфигурационные файлы и пароли внутрь контейнера без изменения самого образа. В 2026 году секреты часто монтируются как файлы, а не переменные окружения, для повышения безопасности.

10. Трафик и Service Mesh: Ingress, Gateway API и Istio

Как внешний пользователь попадает в ваше приложение? Стандартный путь: External Load Balancer -> Ingress Controller -> Service -> Pod. В 2026 году на смену классическому Ingress активно приходит Gateway API. Это более гибкий стандарт, который разделяет зоны ответственности между инфраструктурными инженерами и разработчиками приложений.

Service Mesh: зачем это нужно?

Когда микросервисов становится сотни, управлять связями между ними через обычные Service становится невозможно. Тут на сцену выходит Service Mesh (например, Istio или Linkerd). Он добавляет Sidecar-контейнер к каждому приложению. Этот Sidecar берет на себя функции шифрования трафика (mTLS), повторных попыток (retries), автоматического прерывания запросов при сбоях (circuit breaking) и детального мониторинга. На Senior-интервью это обязательная тема.

Canary и Blue-Green развертывания

Благодаря Service Mesh или продвинутым Ingress-контроллерам (например, Argo Rollouts) можно реализовать сложные стратегии деплоя. Canary позволяет направить 5% трафика на новую версию приложения и проверить ее на ошибки. Blue-Green полностью переключает трафик между старой и новой версиями. Кандидат должен уметь объяснить, как K8s помогает минимизировать Downtime при обновлении.

11. Мониторинг, Логирование и Трассировка (Observability)

«Ваше приложение в Kubernetes тормозит. Ваши действия?». Это классический вопрос на проверку навыков отладки. Ответ должен включать три столпа Observability: метрики (Prometheus/Grafana), логи (Loki/Fluentd/ELK) и трассировку (Jaeger/Tempo). В 2026 году к ним добавился eBPF-профайлинг для анализа производительности на уровне ядра без изменения кода приложения.

Prometheus и метрики

Вы должны понимать, как работает pull-модель Prometheus: он сам опрашивает приложения по эндпоинту `/metrics`. Важно знать разницу между типами метрик: Counter (только растет, например количество запросов), Gauge (может расти и падать, например использование памяти), Histogram и Summary. На интервью могут попросить написать простой PromQL запрос для расчета процента ошибок (Error Rate).

Распределенная трассировка

В мире микросервисов один запрос может проходить через 10 сервисов. Чтобы найти, где именно происходит задержка, используется Trace ID, который передается в заголовках HTTP. На собеседовании полезно упомянуть OpenTelemetry (OTel) — это стандарт сбора данных, который стал общепринятым к 2026 году, позволяя не привязываться к конкретному вендору мониторинга.

12. Автоматизация и GitOps: Helm, Kustomize и ArgoCD

Как вы деплоите в Kubernetes? Ответ «через kubectl apply -f» допустим только для Junior. Для серьезных проектов используются пакетные менеджеры, такие как Helm. Helm позволяет шаблонизировать YAML-манифесты, создавая графики (Charts), где параметры (пароли, количество реплик) вынесены в отдельный файл values.yaml. Это упрощает управление разными окружениями (dev, staging, prod).

GitOps: декларативный подход

В 2026 году GitOps стал доминирующей методологией. Суть проста: состояние кластера должно полностью соответствовать тому, что описано в Git-репозитории. Инструменты вроде ArgoCD или FluxCD постоянно сравнивают текущее состояние в K8s с целевым в Git. Если кто-то вручную изменит количество реплик через консоль, ArgoCD автоматически вернет его к значению из Git. Это исключает «дрейф конфигурации».

CI/CD пайплайны для контейнеров

Типичный пайплайн в 2026 году: разработчик пушит код -> запускаются тесты -> собирается Docker-образ (Multi-stage) -> образ сканируется на уязвимости (Trivy) -> образ пушится в Registry -> в Git-репозитории с манифестами обновляется тег образа -> ArgoCD синхронизирует изменения в кластер. Умение описать этот процесс целиком показывает системное мышление инженера.

Заключение: стратегия подготовки

Подготовка к собеседованию по Docker и Kubernetes требует не только зазубривания ответов, но и практического опыта. Технологии развиваются быстро: то, что было актуально в 2022 году (например, Docker-shim), в 2026 году уже стало историей. Сегодня фокус сместился в сторону безопасности, эффективности использования ресурсов и автоматизации через GitOps.

Чек-лист для самопроверки

• Вы можете объяснить разницу между контейнером и виртуальной машиной на уровне ядра.
• Вы знаете, как написать Dockerfile, который собирается быстро и весит мало.
• Вы понимаете, как связаны Service, Endpoint и Pod.
• Вы можете объяснить, зачем нужны Taints и Tolerations в больших кластерах.
• Вы понимаете концепцию Infrastructure as Code и роль GitOps в современном DevOps.

Не бойтесь признавать отсутствие опыта с конкретным инструментом (например, если вы не работали именно с Linkerd), но демонстрируйте понимание общих принципов (зачем нужен Service Mesh). В 2026 году компании ценят инженеров, которые видят за инструментами архитектурные паттерны и бизнес-цели: надежность, скорость доставки кода и экономию облачного бюджета.