Java Interview Questions

Главная / Все ответы / Docker Kubernetes

Вопрос 2 · Раздел 14

В чём отличие контейнера от виртуальной машины?

Представьте, что вам нужно запустить несколько приложений на одном компьютере. Есть два способа:

Russian Docker Kubernetes Исходный Markdown
Версии по языкам: English Russian Ukrainian

🟢 Junior Level

Простое объяснение

Представьте, что вам нужно запустить несколько приложений на одном компьютере. Есть два способа:

Виртуальная машина (ВМ) — это как построить отдельный дом для каждого приложения. У каждого дома свой фундамент, свои стены, своя крыша. Полноценно, но дорого и медленно.

Виртуальная машина (ВМ) – эмуляция полноценного компьютера с собственным ядром ОС, работающая поверх гипервизора. Гипервизор – программный слой, который создаёт и управляет ВМ (KVM, ESXi, VirtualBox).

Контейнер — это как комнаты в одном доме. Все комнаты используют общий фундамент и крышу (ядро ОС), но каждая комната изолирована своими стенами.

Аналогия

  • ВМ = отдельный дом с полной инфраструктурой (электричество, водопровод, отопление)
  • Контейнер = комната в общежитии (общие коммуникации, но своя стена и замок)

Ключевые отличия

  Виртуальная машина Контейнер
Размер Гигабайты Мегабайты
Запуск Минуты Секунды
Ресурсы Каждая ВМ забирает много RAM и CPU Контейнеры делят ресурсы эффективно
ОС У каждой ВМ своя полная операционная система Все контейнеры используют ядро хостовой ОС

Пример

# Виртуальная машина: нужно установить ОС, ждать загрузки, настроить
# Это как купить и настроить новый компьютер

# Контейнер: одна команда
docker run -d -p 8080:8080 myapp
# Это как запустить новую программу на компьютере

Когда что использовать

  • ВМ — когда нужна полная изоляция или разные ОС (например, Windows на Linux-сервере)
  • Контейнеры — для современных приложений, микросервисов, быстрой разработки и деплоя

Что запомнить

  • Контейнеры легче и быстрее виртуальных машин. Легче – потому что нет дублирования ОС (каждая ВМ несёт свою ОС, контейнеры делят ядро хоста). Быстрее – потому что не нужно загружать ядро, только запустить процесс.
  • ВМ дают более строгую изоляцию
  • Контейнеры делят ядро ОС, ВМ имеют своё собственное
  • Для управления контейнерами в продакшене используют Kubernetes

Когда НЕ использовать контейнеры вместо ВМ

  1. Нужна полная изоляция (multi-tenancy) – ВМ надёжнее
  2. Требуется другая ОС (Windows на Linux) – контейнеры делят ядро
  3. Compliance требует аппаратной изоляции – ВМ

🟡 Middle Level

Архитектурные различия

Виртуальные машины (Hardware Virtualization)

ВМ работает на базе гипервизора:

  • Type 1 (bare-metal): ESXi, KVM — работают напрямую с железом
  • Type 2 (hosted): VirtualBox, VMware Workstation — работают поверх ОС

Каждая ВМ включает: полную копию ОС, своё ядро и драйверы, системные утилиты, приложение. Виртуализируется физическое железо (CPU, RAM, Disk).

Контейнеры (OS Virtualization)

Контейнеры работают на базе Container Engine (Docker, containerd). Все контейнеры используют ядро хостовой ОС. Виртуализируются системные ресурсы через механизмы ядра Linux: Namespaces (логическая изоляция) и Cgroups (ограничение потребления).

Детальное сравнение

Характеристика Виртуальные машины Контейнеры
Изоляция Сильная: на уровне аппаратных прерываний Слабая: логическая изоляция процессов
Ресурсы Высокие накладные расходы на Guest OS Минимальные (почти как нативный процесс)
Время старта 1-5 минут (полная загрузка ОС) < 1 секунды (старт процесса)
Размер Гигабайты (дублирование ОС) Мегабайты (только приложение + зависимости)
Файловая система Блочное устройство (Disk Image) Layered FS (UnionFS) — слои переиспользуются

Типичные ошибки

Ошибка Последствие Как избежать
Выбор контейнеров для multi-tenancy Риск container escape Используйте ВМ или MicroVMs
Игнорирование overhead UnionFS Медленный disk I/O Минимизируйте число слоёв
Запуск Windows-приложений в контейнерах Linux Не работает Используйте ВМ или Wine-контейнеры
Ожидание полной изоляции контейнеров Уязвимость ядра = компрометация всех Harden, seccomp, AppArmor

UnionFS — ключ к эффективности

Контейнеры используют многослойные файловые системы (Overlay2, AUFS):

  • Каждый слой — набор изменений
  • Слои переиспользуются между контейнерами
  • Если 10 контейнеров используют openjdk:17, базовые слои хранятся в одном экземпляре

Гибридный подход

MicroVMs для контейнеров (AWS Fargate, Kata Containers, Firecracker) — сочетают скорость контейнеров и изоляцию ВМ. Каждая «контейнерная нагрузка» запускается в собственной микро-ВМ с облегчённым ядром.

Что запомнить

  • Контейнеры — это процессы с улучшенной изоляцией
  • ВМ — полноценные системы с имитацией железа
  • UnionFS позволяет контейнерам экономить ресурсы
  • Контейнеры менее безопасны, но намного быстрее и легче
  • Для критичной изоляции используют гибридные решения

🔴 Senior Level

Фундаментальный анализ: уровни абстракции

Выбор между контейнерами и ВМ — это выбор уровня абстракции, определяющий архитектуру, безопасность, стоимость и операционную модель.

Глубокая архитектура

# ВМ: аппаратная виртуализация
Приложение → Guest OS → Гипервизор (VMX root mode) → Железо

# Контейнеры: виртуализация на уровне ОС
Приложение → Зависимости → Ядро хоста (Namespaces + Cgroups + Seccomp) → Железо

Гипервизор перехватывает привилегированные инструкции CPU (через Intel VT-x / AMD-V) и эмулирует hardware. Это добавляет overhead на каждом системном вызове. Контейнер — обычный процесс Linux, ограниченный syscall’ами ядра. Нет эмуляции, нет промежуточных слоёв.

Анализ безопасности

Аспект ВМ Контейнеры
Attack surface Гипервизор (маленький, проверенный) Ядро Linux (большое, общий доступ)
Escape риск Крайне редкий, но возможен через уязвимости гипервизора (CVE-2021-26326). Реальный (CVE в ядре, runc)
Multi-tenancy Безопасно по умолчанию Требует дополнительных мер
Compliance Подходит для строгих регуляторов Требует харденинга

Container Escape векторы:

  • Уязвимости ядра Linux (Dirty COW, CVE-2022-0492 cgroups)
  • Неправильная настройка capabilities (CAP_SYS_ADMIN = практически root)
  • Монтирование чувствительных путей (/proc, /sys, /var/run/docker.sock)
  • Запуск от root без ограничений

Митигация:

  • Seccomp profiles (ограничивают доступные syscall)
  • AppArmor / SELinux (Mandatory Access Control)
  • Read-only root filesystem
  • Drop all capabilities, add only needed
  • User namespaces (UID mapping: root в контейнере ≠ root на хосте)

Производительность: детальный анализ

Контейнеры:

  • CPU overhead: < 1% (прямой вызов syscall)
  • Memory overhead: ~несколько МБ на контейнер
  • Network: практически native (использует хостовой стек)
  • Disk I/O: возможен overhead из-за UnionFS (Overlay2 добавляет один слой копирования при записи — copy-on-write)

ВМ:

  • CPU overhead: 5-15% (зависит от гипервизора, paravirtualization снижает)
  • Memory overhead: ГБ на Guest OS
  • Network: требует виртуализации NIC (virtio снижает overhead)
  • Disk I/O: требует виртуализации storage controller

Экономический анализ

Метрика Контейнеры ВМ
Плотность 100+ на сервер 10-30 на сервер
Утилизация CPU 60-80% 20-40%
Время деплоя Секунды Минуты
Операционные расходы Ниже (автоматизация) Выше (ручное управление)

Современные тренды

  1. MicroVMs: Firecracker (AWS Lambda/Fargate), Kata Containers — безопасность ВМ + скорость контейнеров. Firecracker запускает микро-ВМ за ~125ms с overhead ~5MB RAM.
  2. WebAssembly (Wasm): ещё более лёгкая изоляция, sandbox на уровне пользовательского пространства, потенциальный конкурент контейнеров.
  3. eBPF: позволяет кастомизировать поведение ядра без модификации кода — новая парадигма наблюдения и безопасности контейнеров.
  4. Confidential Containers: Intel TDX, AMD SEV-SNP — шифрование памяти контейнера на уровне CPU, защита от compromised hypervisor.

Trade-offs

Требование Лучший выбор Почему
Максимальная скорость деплоя Контейнеры Запуск за миллисекунды
Multi-tenancy / строгий compliance ВМ / MicroVMs Аппаратная изоляция
Гетерогенные ОС ВМ Каждая ВМ со своим ядром
High-density microservices Контейнеры 100+ на сервер
Legacy приложения с kernel dependencies ВМ Полный контроль ядра

Edge Cases

  • Nested virtualization: ВМ внутри ВМ. Нужно для CI/CD с Docker-in-Docker на ВМ. Поддерживается не всеми гипервизорами.
  • Real-time kernels: Контейнеры на хостах с PREEMPT_RT ядром могут получать гарантированное время отклика, но cgroups не даёт real-time гарантий.
  • GPU passthrough: ВМ — SR-IOV или NVIDIA vGPU. Контейнеры — NVIDIA Container Toolkit (прямой доступ к GPU через device cgroup).

Резюме

  • Контейнеры — процессы с улучшенной изоляцией. ВМ — полноценные системы с имитацией железа.
  • Выбор определяется требованиями безопасности, а не только производительностью.
  • Для multi-tenancy и строгих compliance — ВМ или MicroVMs. Для скорости и CI/CD — контейнеры.
  • На масштабе контейнеры дают 3-5x лучшую утилизацию ресурсов.
  • Гибридные подходы (MicroVMs, Kata) стирают границу между технологиями.
  • Понимайте trade-offs: безопасность vs скорость, изоляция vs эффективность.

🎯 Шпаргалка для интервью

Обязательно знать:

  • ВМ виртуализирует железо (гипервизор), контейнеры — ОС (namespaces + cgroups)
  • Контейнеры: старт за секунды, размер в МБ, overhead CPU < 1%
  • ВМ: старт за минуты, размер в ГБ, overhead CPU 5-15%
  • UnionFS позволяет контейнерам переиспользовать слои (экономия disk/RAM)
  • MicroVMs (Firecracker, Kata) сочетают скорость контейнеров + изоляцию ВМ
  • Container escape возможен через уязвимости ядра, неправильные capabilities
  • Для multi-tenancy — ВМ, для CI/CD — контейнеры

Частые уточняющие вопросы:

  • «Что такое гипервизор?» — Слой между железом и ВМ (KVM, ESXi). Type 1 — bare-metal, Type 2 — hosted
  • «Почему контейнеры менее безопасны?» — Общее ядро: уязвимость ядра = компрометация всех контейнеров
  • «Что такое MicroVM?» — Лёгкая ВМ (~5MB RAM, 125ms запуск) с безопасностью ВМ и скоростью контейнера
  • «Что даёт seccomp?» — Ограничивает доступные syscall контейнера, уменьшает attack surface

Красные флаги (НЕ говорить):

  • «Контейнеры безопаснее ВМ» (наоборот, общая атака через ядро)
  • «ВМ и контейнеры — одно и то же» (разные уровни абстракции)
  • «Container escape невозможен» (реален через CVE в ядре/runc)
  • «Контейнер может загрузить своё ядро» (делит ядро хоста)

Связанные темы:

  • [[Что такое контейнеризация и зачем она нужна]] — основы контейнеризации
  • [[Что такое Pod в Kubernetes]] — контейнеры в K8s
  • [[Что такое Dockerfile]] — создание образов