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

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

Головна фундаментальна відмінність полягає в рівні абстракції віртуалізації:

🐳 Docker Kubernetes 📄 Вихідний Markdown

🟢 Junior Level

30-секундна відповідь

Головна фундаментальна відмінність полягає в рівні абстракції віртуалізації:

  • Віртуальна машина (ВМ) віртуалізує апаратне забезпечення (Hardware): поверх фізичного сервера працює гіпервізор (KVM, VMware ESXi, VirtualBox), а кожна ВМ запускає свою власну повноцінну гостьову операційну систему (Guest OS) зі своїм власним ядром, драйверами та системними демонами.
  • Контейнер віртуалізує операційну систему (OS): усі контейнери на сервері працюють як звичайні ізольовані процеси, що розділяють одне спільне ядро хоста (Host OS Kernel).

Наочна аналогія з життя

  • Віртуальна машина — це окремий приватний будинок: у нього власний фундамент, свої стіни, дах, автономний водопровід та котельня. Це гарантує максимальну незалежність, але вимагає величезних витрат на будівництво та обслуговування.
  • Контейнер — це квартира в сучасному житловому комплексі: у всіх квартир спільний фундамент, дах, єдині труби опалення та охорона будинку (спільне ядро ОС), але всередині вашої квартири є свої стіни, лічильники ресурсів і замок на дверях (namespaces та cgroups).

Зведена таблиця базових відмінностей

| Критерій | Віртуальна машина (ВМ) | Контейнер (Docker / Podman) | | :— | :— | :— | | Що віртуалізується | Фізичне залізо (CPU, RAM, BIOS, NIC) | Операційна система (системні виклики ядра) | | Ядро ОС | Своє незалежне ядро в кожній ВМ | Одне спільне ядро хостової системи | | Час старту | 1–5 хвилин (повне завантаження ОС) | < 1 секунди (запуск звичайного процесу) | | Розмір образу | Гігабайти (від 2 до 20+ ГБ) | Мегабайти (від 30 до 300 МБ) | | Оверхед на CPU/RAM | 5–15% CPU + сотні МБ на саму ОС | < 1% CPU, накладні витрати лише на процес | | Ізоляція | Апаратна (максимальна) | Процесна (логічна) |

🟡 Middle Level

Архітектура: Гіпервізор vs Container Engine

1. Будова віртуальної машини

ВМ працює під керуванням гіпервізора:

  • Тип 1 (Bare-Metal): гіпервізор встановлюється прямо на «голе залізо» без проміжної ОС (VMware ESXi, KVM, Xen, Microsoft Hyper-V).
  • Тип 2 (Hosted): гіпервізор запускається як програма поверх звичайної хостової ОС (VirtualBox, VMware Workstation). Гіпервізор емулює віртуальні контролери дисків, віртуальну пам’ять та мережеві адаптери.

2. Будова контейнера

Контейнери керуються Container Runtime (containerd, CRI-O, Docker):

  • Усередині контейнера немає окремого ядра і немає шару емуляції обладнання.
  • Ізоляція процесів забезпечується підсистемою Namespaces (PID, NET, MNT, USER, IPC, UTS).
  • Обмеження пам’яті та процесорного часу забезпечується підсистемою cgroups v2.
  • Контейнер — це нативний процес хоста. Виклик ps aux на хості Linux відобразить процес Java-застосунку поруч із системними демонами.
# Процеси контейнера видно на хості Linux як звичайні системні процеси:
ps aux | grep java

# Отримати реальний PID процесу контейнера в просторі хоста:
docker inspect --format '' payment-service-app

# Перевірити обмеження пам'яті в cgroups v2 для цього контейнера:
cat /sys/fs/cgroup/system.slice/docker-<container-id>.scope/memory.max

Дискова підсистема: Блочні образи vs Layered FS (Overlay2)

  • Віртуальна машина: працює з монолітним віртуальним диском фіксованого або динамічного розміру (.qcow2, .vmdk), що форматується у файлову систему (ext4, NTFS). Образ диска важко версіонувати та перевикористовувати.
  • Контейнер: використовує каскадну файлову систему OverlayFS (Overlay2). Шари є незмінними і поділяються між десятками контейнерів: якщо 20 мікросервісів використовують образ eclipse-temurin:21, шар JRE вагою 200 МБ зберігається на диску і кешується в оперативній пам’яті сервера в єдиному екземплярі.

Гібридний підхід: MicroVMs (Kata Containers, Firecracker)

У публічних хмарах (AWS Lambda, AWS Fargate, Google Cloud Run) для усунення ризику небезпечного розділення ядра застосували технологію MicroVMs:

  • Запуск полегшеної віртуальної машини з мінімалістичним кастомним ядром Linux без застарілих емуляторів BIOS/PCI.
  • Час старту MicroVM становить близько 100–150 мс, а споживання пам’яті — лише близько 5 МБ.
  • Усередині такої MicroVM запускається стандартний OCI-контейнер, забезпечуючи швидкість контейнерів та апаратний захист ВМ.

🔴 Senior Level

Апаратні накладні витрати: Двовимірна трансляція сторінок (SLAT / EPT)

Senior-інженеру важливо розуміти причину різниці в продуктивності на рівні транзисторів CPU:

  1. У віртуальних машинах (Hardware-Assisted Paging):
    • Процесор використовує апаратну технологію Extended Page Tables (EPT) від Intel або Nested Page Tables (NPT) від AMD.
    • Для доступу до пам’яті процесор змушений виконувати двовимірний прохід таблицями сторінок (Two-Dimensional Page Walk): спочатку транслювати гостьову віртуальну адресу (GVA) в гостьову фізичну адресу (GPA), а потім GPA у фізичну адресу хоста (HPA).
    • При промаху кешу TLB цей прохід вимагає до 24 звернень до пам’яті, викликаючи приховані затримки в застосунках з інтенсивною роботою з купою пам’яті (наприклад, збирач сміття GC у великих JVM).
  2. У контейнерах:
    • Трансляція адрес пам’яті відбувається через стандартні таблиці сторінок ядра хоста (Virtual Address $\to$ Physical Address) в один крок.
    • Накладні витрати на роботу з оперативною пам’яттю дорівнюють строго 0% порівняно з «голим залізом».

Аналіз поверхні атаки: Ядро хоста vs Гіпервізор

| Компонент | Рядків коду (LOC) | Межа ізоляції | Ризик втечі (Escape) | | :— | :— | :— | :— | | Гіпервізор KVM | $\approx 20\,000$ рядків | Апаратні кільця процесора (Intel VMX root mode) | Вкрай низький (вимагає рідкісних уразливостей у virtio) | | Ядро Linux (Контейнери) | $\approx 30\,000\,000$ рядків | Логічні перевірки в коді ядра (syscall checks) | Істотний (уразливості ядра, eBPF, драйвери, race conditions) |

Вектори Container Escape:

  1. Небезпечні Capabilities: наявність прапорця --privileged або привілею CAP_SYS_ADMIN дозволяє контейнеру змонтувати фізичний диск хоста та перезаписати системні файли хостової ОС.
  2. Витік сокета Docker: прокидання /var/run/docker.sock усередину контейнера дає атакуючому права root на всьому сервері.
  3. Експлойти ядра (Dirty COW, Dirty Pipe): перезапис сторінок пам’яті ядра хоста в обхід прав доступу.

Модель пам’яті: Balloon Driver vs cgroups Memory Limits

  • ВМ: пам’ять виділяється монолітно. Для динамічного повернення пам’яті хосту гіпервізор використовує драйвер «роздування пам’яті» (Memory Ballooning): спеціальний драйвер усередині гостьової ОС роздуває свій буфер, змушуючи Guest OS скидати сторінки у своп. Це повільний та інерційний процес.
  • Контейнери: пам’ять виділяється за фактом використання (динамічно). Підсистема cgroups v2 миттєво відстежує використання сторінок (memory.current). При досягненні м’якого ліміту (memory.high) ядро плавно гальмує процес і скидає кеш сторінок; при перевищенні жорсткого ліміту (memory.max) — миттєво активує OOM Killer.

4 Tricky Questions

1. Як технологія апаратної віртуалізації EPT/SLAT впливає на затримки JVM Garbage Collector всередині ВМ порівняно із запуском у Linux-контейнері?

Відповідь: JVM Garbage Collector (особливо G1 та ZGC) безперервно сканує мільйони посилань на об’єкти в купі. Усередині віртуальної машини процесор використовує Extended Page Tables (EPT) для трансляції гостьових адрес у фізичні адреси сервера. При промаху в буфері асоціативної трансляції (TLB Miss) процесору доводиться виконувати вкладений прохід таблицями сторінок (до 24 кроків замість 4). У результаті фази маркування та компактизації GC всередині ВМ можуть витрачати на 10–25% більше процесорних циклів, ніж при запуску в контейнері, де трансляція сторінок пам’яті виконується стандартним однорівневим блоком MMU без участі гіпервізора.

2. Чи можна запустити Linux-контейнер на Windows-сервері та Windows-контейнер на Linux-сервері? Як це влаштовано технічно?

Відповідь:

  • Linux-контейнер на Windows: Так, можна, але лише через приховану віртуалізацію! На Windows (у Docker Desktop) запускається легковага віртуальна машина з ядром Linux (через підсистему WSL 2 або Hyper-V). Linux-контейнери ділять ядро цієї допоміжної ВМ, а не самої Windows.
  • Windows-контейнер на Linux: Фізично неможливо. Windows-контейнери вимагають наявності ядра Windows (ntoskrnl.exe) та системних бібліотек Win32/NTDLL. Ядро Linux не вміє виконувати системні виклики Windows NT Kernel. Запуск можливий лише всередині повноцінної віртуальної машини зі встановленою Windows OS.

3. У чому архітектурна різниця між ізоляцією MicroVM (AWS Firecracker) та пісочницею gVisor (Google)?

Відповідь:

  • AWS Firecracker (MicroVM): запускає реальне легковаге ядро Linux в апаратно ізольованому просторі віртуалізації (KVM). Контейнер спілкується зі своїм власним мікроядром через стандартні системні виклики. Межа безпеки підтримується на апаратному рівні CPU.
  • gVisor (Google): це програмний перехоплювач системних викликів у просторі користувача (User-Space Kernel), написаний на Go (модуль Sentry). Застосунок думає, що робить виклики до ядра Linux, але Sentry емулює та фільтрує системні виклики, ізолюючи процес від реального ядра хоста без створення гіпервізора.

4. Що станеться з контейнером та віртуальною машиною при падінні (Kernel Panic) ядра операційної системи хоста?

Відповідь:

  • Для всіх контейнерів на сервері: оскільки абсолютно всі контейнери поділяють єдине ядро хостової ОС, падіння ядра (Host Kernel Panic) миттєво призводить до одночасної аварійної зупинки абсолютно всіх контейнерів на цій фізичній машині.
  • Для віртуальних машин: падіння ядра гостьової ОС (Guest Kernel Panic) всередині однієї конкретної ВМ ізольовано всередині її віртуального простору: решта віртуальних машин та гіпервізор хоста продовжать працювати без збоїв. Однак якщо впаде сам гіпервізор хоста (Type 1 Bare-Metal OS), усі ВМ на цьому фізичному сервері також синхронно припинять роботу.

🎯 Шпаргалка для інтерв’ю

Топ-5 фундаментальних відмінностей

  1. Ядро ОС: ВМ несе своє власне ядро; контейнери ділять одне спільне ядро хоста Linux.
  2. Абстракція: ВМ віртуалізує апаратне залізо (гіпервізор); контейнери ізолюють процеси (Namespaces + cgroups).
  3. Швидкість: ВМ стартує хвилини; контейнер стартує за мілісекунди.
  4. Ресурси: ВМ вимагає резервування гігабайтів RAM під гостьову ОС; контейнер витрачає пам’ять лише на сам процес та рантайм.
  5. Безпека: ВМ забезпечує апаратну ізоляцію; у контейнерах межа безпеки — це код ядра хоста.

Матриця прийняття рішень (Архітектурний вибір)

| Бізнес-вимога | Рекомендація | Причина | | :— | :— | :— | | Мікросервіси, CI/CD, висока щільність | 🟢 Контейнери | Миттєвий запуск, мінімальний оверхед, ідеальна повторюваність | | Untrusted Multi-Tenancy (публічне SaaS)| 🟢 ВМ або MicroVMs | Гарантія неможливості Container Escape | | Запуск Windows + Linux на одному сервері | 🟢 Віртуальні машини| Контейнери не можуть емулювати чуже ядро ОС | | Legacy-моноліти з жорсткою прив’язкою до драйверів| 🟢 Віртуальні машини| Повний контроль над версією ядра та модулями |

Червоні прапорці на співбесіді (Чого говорити не можна)

  • ❌ «Контейнери абсолютно безпечні, тому що вони повністю ізольовані» — спільне ядро створює ризик Container Breakout.
  • ❌ «Контейнер — це просто урізана ВМ» — грубе архітектурне нерозуміння; у контейнері немає гостьової ОС і немає гіпервізора.
  • ❌ «Усередині кожного Docker-контейнера завантажується своє маленьке ядро Linux» — ядро на сервері завжди рівно одне (ядро хоста).

Пов’язані питання