Модуль 2.1: Планування

Складність: [СЕРЕДНІЙ] - Концепції оркестрації

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

Передумови: Частина 1 (Основи Kubernetes)

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

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

Пояснити як планувальник Kubernetes обирає вузли за допомогою фільтрації та оцінювання
Порівняти механізми планування: nodeSelector, affinity, taints та tolerations
Визначити чому Pod перебуває у стані Pending на основі обмежень планувальника та доступності ресурсів
Оцінити стратегії планування для різних вимог розміщення навантажень

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

Планування — це спосіб, яким Kubernetes вирішує, де запускати ваші Поди. Розуміння концепцій планування допомагає передбачити, де працюватимуть навантаження та як впливати на розміщення. KCNA перевіряє ваше концептуальне розуміння планування.

Що таке планування?

Планування — це процес призначення Подів на вузли:

┌─────────────────────────────────────────────────────────────┐
│              ОГЛЯД ПЛАНУВАННЯ                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Новий Под створено                                        │
│       │                                                     │
│       │ Вузол не призначений (spec.nodeName порожній)      │
│       ▼                                                     │
│  ┌──────────────────────────────────────────────────────┐  │
│  │              KUBE-SCHEDULER                           │  │
│  │                                                       │  │
│  │  1. Фільтрація: Які вузли МОЖУТЬ запустити цей Под? │  │
│  │     • Достатньо ресурсів?                             │  │
│  │     • Задовольняє обмеження?                          │  │
│  │                                                       │  │
│  │  2. Оцінювання: Який вузол НАЙКРАЩИЙ?               │  │
│  │     • Розподілити навантаження                        │  │
│  │     • Образ вже присутній?                            │  │
│  │     • Користувацькі пріоритети                        │  │
│  │                                                       │  │
│  │  3. Прив'язка: Призначити Под на вузол-переможець    │  │
│  └──────────────────────────────────────────────────────┘  │
│       │                                                     │
│       ▼                                                     │
│  Под призначено на Вузол 2                                 │
│       │                                                     │
│       ▼                                                     │
│  kubelet на Вузлі 2 запускає Под                          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Методи вибору вузлів

1. nodeSelector

Просте збігання міток:

# Специфікація Пода
spec:
  nodeSelector:
    disk: ssd
    region: us-west

# Тільки вузли з ОБОМА мітками розглядаються

2. Node Affinity

Більш виразний за nodeSelector:

┌─────────────────────────────────────────────────────────────┐
│              NODE AFFINITY                                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Два типи:                                                 │
│                                                             │
│  requiredDuringSchedulingIgnoredDuringExecution:          │
│  • ПОВИНЕН збігатися                                       │
│  • Под не запланується, якщо жоден вузол не відповідає    │
│  • Як nodeSelector, але потужніший                         │
│                                                             │
│  preferredDuringSchedulingIgnoredDuringExecution:         │
│  • НАДАЄ ПЕРЕВАГУ збігу                                    │
│  • Под запланується навіть без збігу                       │
│  • М'яка перевага                                          │
│                                                             │
│  "IgnoredDuringExecution" означає:                        │
│  • Мітки перевіряються тільки під час планування          │
│  • Якщо мітки змінюються пізніше, Под залишається         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

3. Pod Affinity/Anti-Affinity

Розміщення Подів відносно інших Подів:

Pod Affinity: “Запланувати поруч з іншими Подами” (напр., кеш на тому ж вузлі, що й веб)
Pod Anti-Affinity: “Запланувати далеко від інших Подів” (напр., розподілити репліки між різними вузлами для високої доступності)

Taints та Tolerations

Taints відштовхують Поди. Tolerations дозволяють Подам плануватися на вузлах з taints:

┌─────────────────────────────────────────────────────────────┐
│              TAINTS ТА TOLERATIONS                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Вузол має taint:                                          │
│  gpu=true:NoSchedule                                       │
│  "Не плануй звичайні Поди тут"                            │
│                                                             │
│  Звичайний Под:              Под GPU з toleration:         │
│  Без toleration              tolerations:                  │
│  → ✗ Відштовхнутий           - key: gpu                   │
│                                 value: true                 │
│                                 effect: NoSchedule          │
│                               → ✓ Може плануватися         │
│                                                             │
│  Ефекти taint:                                             │
│  • NoSchedule: Не планувати нові Поди                     │
│  • PreferNoSchedule: Намагатися уникати, але дозволити    │
│  • NoExecute: Виселити існуючі Поди теж                   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Запити та обмеження ресурсів

┌─────────────────────────────────────────────────────────────┐
│              REQUESTS проти LIMITS                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  resources:                                                │
│    requests:         # Мінімум гарантований                │
│      cpu: "500m"     # 0.5 ядра CPU                       │
│      memory: "256Mi" # 256 MiB                            │
│    limits:           # Максимум дозволений                 │
│      cpu: "1000m"    # 1 ядро CPU                         │
│      memory: "512Mi" # 512 MiB                            │
│                                                             │
│  REQUESTS:                                                 │
│  • Використовуються планувальником для пошуку вузлів      │
│  • Вузол повинен мати стільки доступних ресурсів          │
│  • Гарантовані контейнеру                                 │
│                                                             │
│  LIMITS:                                                   │
│  • Максимум, який контейнер може використати              │
│  • CPU: Обмежується при перевищенні                       │
│  • Пам'ять: OOMKilled при перевищенні                     │
│                                                             │
│  Планування використовує REQUESTS, не limits:             │
│  "Чи може цей вузол вмістити запитані ресурси?"           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чи знали ви?

Планувальник замінний - Ви можете запускати власні планувальники або кілька планувальників у кластері.
DaemonSets обходять звичайне планування - Вони використовують власний контролер для забезпечення одного Пода на вузол.
Витіснення - Якщо жоден вузол не може вмістити високопріоритетний Под, планувальник може виселити низькопріоритетні Поди.
Топологічний розподіл - Kubernetes може розподіляти Поди між зонами, стійками або будь-яким топологічним доменом для високої доступності.

Типові помилки

Помилка	Чому це шкодить	Правильне розуміння
Без resource requests	Планувальник не може приймати хороші рішення	Завжди задавайте requests
Requests завеликі	Марнування ресурсів	Відповідайте фактичним потребам
Плутання типів affinity	Под може не заплануватися	required = повинен; preferred = спроба
Забування tolerations	Поди не можуть використовувати вузли з taints	Додайте tolerations для спеціальних вузлів

Вікторина

Які дві фази використовує планувальник?

Відповідь
Фільтрація (які вузли МОЖУТЬ запустити Под) та Оцінювання (який вузол НАЙКРАЩИЙ). Після них Под прив'язується до вузла-переможця.
Яка різниця між nodeSelector та node affinity?

Відповідь
nodeSelector — просте збігання міток (повинні мати точні мітки). Node affinity більш виразний з правилами required/preferred та операторами як In, NotIn, Exists.
Що робить taint?

Відповідь
Taint відштовхує Поди від планування на вузлі. Тільки Поди з відповідними tolerations можуть плануватися на вузлах з taints.
Resource requests чи limits використовуються для планування?

Відповідь
Requests. Планувальник перевіряє, чи має вузол достатньо доступних ресурсів для задоволення requests Пода. Limits застосовуються під час виконання.
Для чого використовується pod anti-affinity?

Відповідь
Розподіл Подів між вузлами/зонами. Наприклад, забезпечення того, що репліки Deployment працюють на різних вузлах для високої доступності.

Підсумок

Процес планування:

Фільтрація: Пошук придатних вузлів
Оцінювання: Ранжування за перевагою
Прив’язка: Призначення на найкращий вузол

Методи вибору вузлів:

nodeSelector: Просте збігання міток
Node affinity: Обов’язкові або рекомендовані правила
Pod affinity/anti-affinity: Розміщення відносно інших Подів
Taints/tolerations: Відштовхування або дозвіл певних Подів

Ресурси:

Requests: Використовуються планувальником, гарантований мінімум
Limits: Максимум дозволений, застосовується під час виконання

Наступний модуль

Модуль 2.2: Масштабування - Як Kubernetes автоматично масштабує застосунки.