Java Interview Questions

Головна / Усі відповіді / Docker Kubernetes

Питання 2 · Розділ 14

В чому відмінність контейнера від віртуальної машини?

Уявіть, що вам потрібно запустити кілька додатків на одному комп'ютері. Є два способи:

Ukrainian 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]] — створення образів