Перейти до вмісту

Модуль 1.2: Основи контейнерів

Складність: [ШВИДКО] - Базові концепції

Час на виконання: 20-25 хвилин

Передумови: Модуль 1.1


Що ви зможете робити

Розділ «Що ви зможете робити»

Після завершення цього модуля ви зможете:

  • Пояснити що таке контейнери та чим вони відрізняються від віртуальних машин
  • Визначити функції ядра Linux (namespaces, cgroups), що забезпечують ізоляцію контейнерів
  • Порівняти середовища виконання контейнерів (Docker, containerd, CRI-O) та їхні ролі в Kubernetes
  • Пояснити специфікації OCI для образів та середовищ виконання та чому вони важливі для переносимості

Чому цей модуль важливий

Розділ «Чому цей модуль важливий»

Ви не зможете зрозуміти Kubernetes без розуміння контейнерів. KCNA перевіряє ваші знання концепцій контейнерів — не як будувати Dockerfile, а що таке контейнери та як вони працюють.


Контейнер — це легкий, автономний, виконуваний пакет, який включає все необхідне для запуску програмного забезпечення:

┌─────────────────────────────────────────────────────────────┐
│ ЩО ВСЕРЕДИНІ КОНТЕЙНЕРА │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ КОНТЕЙНЕР │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ Код застосунку │ │ │
│ │ │ (ваш застосунок, скрипти, бінарні файли) │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ Залежності │ │ │
│ │ │ (бібліотеки, пакети, фреймворки) │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ Середовище виконання │ │ │
│ │ │ (Python, Node.js, Java JVM тощо) │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ Системні інструменти та бібліотеки │ │ │
│ │ │ (мінімальний простір користувача ОС) │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ НЕ включено: Ядро (спільне з хостом) │
│ │
└─────────────────────────────────────────────────────────────┘

Контейнери проти віртуальних машин

Розділ «Контейнери проти віртуальних машин»
┌─────────────────────────────────────────────────────────────┐
│ ВІРТУАЛЬНІ МАШИНИ проти КОНТЕЙНЕРІВ │
├─────────────────────────────────────────────────────────────┤
│ │
│ ВІРТУАЛЬНІ МАШИНИ КОНТЕЙНЕРИ │
│ ───────────────────────────────────────────────────────── │
│ │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │App A│ │App B│ │App C│ │App A│ │App B│ │App C│ │
│ ├─────┤ ├─────┤ ├─────┤ ├─────┤ ├─────┤ ├─────┤ │
│ │Bins │ │Bins │ │Bins │ │Bins │ │Bins │ │Bins │ │
│ │Libs │ │Libs │ │Libs │ │Libs │ │Libs │ │Libs │ │
│ ├─────┤ ├─────┤ ├─────┤ └──┬──┘ └──┬──┘ └──┬──┘ │
│ │Гост.│ │Гост.│ │Гост.│ │ │ │ │
│ │ ОС │ │ ОС │ │ ОС │ │ │ │ │
│ └──┬──┘ └──┬──┘ └──┬──┘ └───────┼───────┘ │
│ └───────┼───────┘ │ │
│ │ ┌───────┴───────┐ │
│ ┌───────┴───────┐ │Середовище │ │
│ │ Гіпервізор │ │виконання │ │
│ └───────┬───────┘ └───────┬───────┘ │
│ │ │ │
│ ┌───────┴───────┐ ┌───────┴───────┐ │
│ │ ОС хоста │ │ ОС хоста │ │
│ └───────┬───────┘ └───────┬───────┘ │
│ │ │ │
│ ┌───────┴───────┐ ┌───────┴───────┐ │
│ │ Обладнання │ │ Обладнання │ │
│ └───────────────┘ └───────────────┘ │
│ │
│ Кожна ВМ має повну ОС Контейнери спільно │
│ (важка, повільний запуск) використовують ядро │
│ хоста (легкі) │
│ │
└─────────────────────────────────────────────────────────────┘

Таблиця порівняння

Розділ «Таблиця порівняння»
АспектВіртуальна машинаКонтейнер
РозмірГБМБ
ЗапускХвилиниСекунди
ІзоляціяСильна (окреме ядро)Рівень процесу (спільне ядро)
Накладні витратиВисокіНизькі
Щільність~десятки на хост~сотні на хост
ПортативністьСередняВисока

Як працюють контейнери

Розділ «Як працюють контейнери»

Контейнери використовують функції ядра Linux:

1. Простори імен (Ізоляція)

Розділ «1. Простори імен (Ізоляція)»
┌─────────────────────────────────────────────────────────────┐
│ ПРОСТОРИ ІМЕН LINUX │
├─────────────────────────────────────────────────────────────┤
│ │
│ Простір імен Що ізолює │
│ ───────────────────────────────────────────────────────── │
│ PID Ідентифікатори процесів (контейнер бачить │
│ власні PID) │
│ Network Мережеві інтерфейси, IP, порти │
│ Mount Монтування файлових систем │
│ UTS Ім'я хоста та доменне ім'я │
│ IPC Міжпроцесна комунікація │
│ User Ідентифікатори користувачів та груп │
│ │
│ Кожен контейнер отримує власні простори імен │
│ → Виглядає як власна ізольована система │
│ │
└─────────────────────────────────────────────────────────────┘

2. Групи керування (Обмеження ресурсів)

Розділ «2. Групи керування (Обмеження ресурсів)»
┌─────────────────────────────────────────────────────────────┐
│ ГРУПИ КЕРУВАННЯ (cgroups) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Cgroups обмежують та відстежують ресурси: │
│ │
│ CPU: "Контейнер A отримує макс. 2 ядра" │
│ Пам'ять: "Контейнер B отримує макс. 512МБ" │
│ Диск I/O: "Контейнер C отримує макс. 100МБ/с" │
│ Мережа: "Контейнер D отримує макс. 100Мбіт/с" │
│ │
│ Без cgroups: │
│ Один контейнер може спожити ВСІ ресурси │
│ │
└─────────────────────────────────────────────────────────────┘

3. Об’єднані файлові системи (Шари)

Розділ «3. Об’єднані файлові системи (Шари)»
┌─────────────────────────────────────────────────────────────┐
│ ШАРИ ОБРАЗУ КОНТЕЙНЕРА │
├─────────────────────────────────────────────────────────────┤
│ │
│ Образ контейнера (шари тільки для читання): │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Шар 4: Код застосунку (ваш застосунок) │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ Шар 3: Залежності (npm пакети) │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ Шар 2: Середовище виконання (Node.js) │ │
│ ├─────────────────────────────────────────────────────┤ │
│ │ Шар 1: Базова ОС (Ubuntu slim) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Запущений контейнер додає: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Шар для запису (зміни, логи, тимчасові файли) │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Переваги: │
│ • Шари кешуються та повторно використовуються │
│ • Кілька контейнерів спільно використовують базові шари │
│ • Ефективне зберігання та передача │
│ │
└─────────────────────────────────────────────────────────────┘

Образи контейнерів

Розділ «Образи контейнерів»

Образ — це шаблон тільки для читання, який використовується для створення контейнерів:

КонцепціяАналогія
ОбразРецепт / Креслення
КонтейнерТорт / Будівля

Конвенція найменування образів

Розділ «Конвенція найменування образів»
registry/repository:tag
Приклади:
docker.io/library/nginx:1.25
gcr.io/google-containers/pause:3.9
mycompany.com/myapp:v2.1.0
Частини:
• registry: Де зберігається образ (docker.io, gcr.io)
• repository: Назва образу (nginx, myapp)
• tag: Ідентифікатор версії (1.25, latest, v2.1.0)
РеєстрОпис
Docker HubПублічний реєстр за замовчуванням
gcr.ioGoogle Container Registry
ECRAmazon Elastic Container Registry
ACRAzure Container Registry
Quay.ioРеєстр Red Hat

Середовища виконання контейнерів

Розділ «Середовища виконання контейнерів»

Kubernetes не запускає контейнери безпосередньо — він використовує середовище виконання контейнерів:

┌─────────────────────────────────────────────────────────────┐
│ CONTAINER RUNTIME INTERFACE (CRI) │
├─────────────────────────────────────────────────────────────┤
│ │
│ Kubernetes │
│ │ │
│ │ CRI (стандартний інтерфейс) │
│ │ │
│ ┌───────────────┼───────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │containerd│ │ CRI-O │ │ Docker │ │
│ │ │ │ │ │(через │ │
│ │ │ │ │ │ shim) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ containerd: За замовчуванням у більшості дистрибутивів K8s│
│ CRI-O: Легкий, орієнтований на Kubernetes │
│ Docker: Застарілий у K8s 1.24+ │
│ │
└─────────────────────────────────────────────────────────────┘

Ключовий момент для KCNA: Kubernetes використовує CRI для комунікації з середовищами виконання контейнерів. Найпоширенішим є containerd.


Життєвий цикл контейнера

Розділ «Життєвий цикл контейнера»
┌─────────────────────────────────────────────────────────────┐
│ ЖИТТЄВИЙ ЦИКЛ КОНТЕЙНЕРА │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. Завантаження образу │
│ Скачування образу з реєстру │
│ │ │
│ ▼ │
│ 2. Створення контейнера │
│ Підготовка файлової системи, просторів імен, cgroups │
│ │ │
│ ▼ │
│ 3. Запуск контейнера │
│ Виконання точки входу контейнера │
│ │ │
│ ▼ │
│ 4. Працює │
│ Контейнер виконується │
│ │ │
│ ┌─────────┴─────────┐ │
│ │ │ │
│ ▼ ▼ │
│ 5a. Зупинка 5b. Збій │
│ Плавне Несподіване │
│ завершення завершення │
│ │ │ │
│ └─────────┬─────────┘ │
│ │ │
│ ▼ │
│ 6. Видалення контейнера │
│ Очищення ресурсів │
│ │
└─────────────────────────────────────────────────────────────┘

  • Контейнери — не нове явище - Концепції сягають Unix chroot (1979) та FreeBSD jails (2000). Docker популяризував їх у 2013 році.

  • Docker не обов’язковий для Kubernetes - Починаючи з K8s 1.24, containerd є стандартним. Docker як середовище виконання застарілий.

  • OCI визначає стандарти - Open Container Initiative стандартизує формати образів та середовища виконання, забезпечуючи портативність.

  • Контейнери спільно використовують ядро хоста - Ось чому контейнери Windows не можуть працювати на Linux і навпаки (без віртуалізації).


ПомилкаЧому це шкодитьПравильне розуміння
”Контейнери — це легкі ВМ”Втрачено архітектурну різницюКонтейнери спільно використовують ядро; ВМ — ні
”Кожен контейнер має свою ОС”Марнує ресурси ментальноКонтейнери спільно використовують ядро хоста
”Docker = Контейнери”Docker — лише одне середовище виконанняcontainerd, CRI-O також запускають контейнери
”Образи та контейнери — одне й те саме”Плутання шаблону та екземпляраОбраз — шаблон; контейнер — запущений екземпляр

  1. Яка функція Linux забезпечує ізоляцію процесів для контейнерів?

    Відповідь Простори імен. Вони ізолюють PID, мережу, монтування, ім'я хоста, IPC та користувачів для кожного контейнера.
  2. Яка функція Linux обмежує використання ресурсів контейнерами?

    Відповідь Групи керування (cgroups). Вони обмежують CPU, пам'ять, дисковий I/O та пропускну здатність мережі.
  3. Який зв’язок між образом та контейнером?

    Відповідь Образ — це шаблон тільки для читання (як рецепт). Контейнер — це запущений екземпляр, створений з цього образу (як торт з рецепту).
  4. Яке стандартне середовище виконання контейнерів у сучасному Kubernetes?

    Відповідь containerd. Docker як середовище виконання було застарілим у Kubernetes 1.24.
  5. Чому контейнери ефективніші за ВМ?

    Відповідь Контейнери спільно використовують ядро хоста замість запуску повної ОС. Це робить їх меншими (МБ замість ГБ), швидшими для запуску (секунди замість хвилин) та дозволяє вищу щільність (сотні замість десятків на хост).

Контейнери — це:

  • Легкі, ізольовані процеси
  • Упаковані з залежностями
  • Створені з образів
  • Спільно використовують ядро хоста

Ключові технології:

  • Простори імен: Ізоляція процесів
  • Cgroups: Обмеження ресурсів
  • Об’єднані файлові системи: Шаровані образи

Середовища виконання контейнерів:

  • containerd (за замовчуванням)
  • CRI-O
  • Docker (застарілий у K8s)

Образи проти контейнерів:

  • Образ = шаблон тільки для читання
  • Контейнер = запущений екземпляр

Модуль 1.3: Архітектура Kubernetes - Площина управління - Розуміння мозку Kubernetes.