---

Junior рівень

Просте пояснення

Node (Вузол) — це робочий сервер, на який K8s «садить» Pod’и. Scheduler вирішує, на який Node посадити кожен Pod. В Kubernetes Node — це “робоча конячка”, яка виконує команди від керуючого центру (Control Plane).

Проста аналогія

Якщо Kubernetes — це будівельна компанія, то:

• Control Plane — офіс менеджерів (приймає рішення)
• Node — будівельний майданчик (де реально йде робота)
• Pod — бригада робітників на майданчику

Що є на кожному Node?

1. kubelet — агент, який стежить за контейнерами і звітує перед Control Plane
2. kube-proxy — відповідає за мережеві правила
3. Container Runtime — програма для запуску контейнерів (зазвичай containerd)

Типи Node

• Worker Node — запускає додатки (Pod’и)
• Control Plane Node — керує кластером (зазвичай не запускає додатки)

Що робить Node?

• Отримує команди від Control Plane
• Запускає Pod’и
• Стежить за їхнім здоров’ям
• Надсилає інформацію про ресурси (CPU, RAM)

Що запам’ятати Junior-розробнику

• Node — це сервер, на якому працюють контейнери
• На кожному Node: kubelet, kube-proxy, container runtime
• Worker Nodes запускають додатки
• Control Plane Nodes керують кластером
• Якщо Node падає, K8s чекає ~5 хвилин (pod-eviction-timeout), щоб переконатися, що Node дійсно мертвий, а не тимчасово втратив мережу. Лише потім переносить Pod’и.

---

Middle рівень

Внутрішні компоненти Node

kubelet

kubelet – агент на кожному Node, який «доповідає» Control Plane про стан контейнерів.

Найважливіший агент на Node:

• Стежить за Pod’ами, призначеними цьому Node
• Спілкується з API-сервером
• Запускає і зупиняє контейнери
• Виконує health checks
• Надсилає статус Node (Ready, NotReady)

kube-proxy

Мережевий проксі:

• Підтримує правила маршрутизації (iptables/IPVS)
• Забезпечує роботу Services (балансування трафіку)
• Переспрямовує трафік до потрібних Pod’ів

Container Runtime

Середовище запуску контейнерів:

• Сучасний стандарт: containerd або CRI-O
• Docker-shim видалено в K8s v1.24+. Замість Docker використовуються containerd або CRI-O.

Ресурси Node

Capacity:          8 CPU, 32 GiB RAM    (фізичні ресурси)
kube-reserved:     1 CPU, 2 GiB RAM     (резерв для K8s)
system-reserved:   0.5 CPU, 1 GiB RAM   (резерв для ОС)
─────────────────────────────────────────
Allocatable:       6.5 CPU, 29 GiB RAM  (доступно для Pod'ів)

Pod’и можуть використовувати лише Allocatable ресурси.

Стани Node (Conditions)

Condition	Що означає
Ready	Node здоровий і може приймати Pod’и
MemoryPressure	Мало вільної RAM
DiskPressure	Мало місця на диску
PIDPressure	Занадто багато процесів
NetworkUnavailable	Проблема з мережею

Eviction (Витіснення Pod’ів)

Коли ресурси Node закінчуються, kubelet починає видаляти Pod’и:

1. BestEffort (немає requests/limits) — видаляються першими
2. Burstable (requests < limits) — видаляються другими
3. Guaranteed (requests == limits) — видаляються останніми

Діагностика

# Інформація про Node
kubectl describe node <name>

# Споживання ресурсів
kubectl top node

# Логи kubelet
journalctl -u kubelet

Що запам’ятати Middle-розробнику

• kubelet — ключовий процес, його падіння паралізує Node
• Завжди задавайте Resources Requests & Limits
• Allocatable < Capacity (частина резервується для ОС і K8s)
• Eviction захищає Node від перевантаження
• kubectl describe node — основна команда діагностики

Коли НЕ керувати Node вручну

НЕ керуйте Node вручну в продакшені – використовуйте managed node groups (EKS, GKE) або IaC (Terraform).

---

Senior рівень

Node як абстракція інфраструктури

Node — це міст між фізичною інфраструктурою і абстрактним світом Kubernetes. Розуміння його роботи критичне для capacity planning, troubleshooting і оптимізації.

Node Pressure і Eviction: глибокий аналіз

Thresholds

Kubelet використовує пороги для переходу в режим тиску:

memory.available < 100Mi       → MemoryPressure
nodefs.available < 15%         → DiskPressure
nodefs.inodesFree < 10%        → DiskPressure (Inodes)
pid.available < 5%             → PIDPressure

Eviction алгоритм

1. Kubelet виявляє pressure condition
2. Позначає Node з відповідним Condition
3. Починає eviction process:
   a. Знаходить Pod'и для видалення (за QoS класом)
   b. Graceful termination (SIGTERM → wait → SIGKILL)
   c. Звільняє ресурси
4. Якщо pressure зберігається — повторює

Graceful vs Forceful Eviction

• Graceful: kubelet надсилає SIGTERM, чекає terminationGracePeriodSeconds
• Forceful: Якщо Node NotReady > pod-eviction-timeout (5 хв за замовчуванням), Control Forcefully видаляє Pod’и

Node Allocatable: детальний аналіз

# kubelet конфігурація
kubeReserved:
  cpu: "500m"
  memory: "1Gi"
  ephemeral-storage: "1Gi"
systemReserved:
  cpu: "200m"
  memory: "500Mi"
evictionHard:
  memory.available: "200Mi"
  nodefs.available: "10%"

Важливо: kubeReserved і systemReserved не забезпечують реальне резервування — це лише інформаційні значення для schedulera. Для жорсткого обмеження потрібні cgroups.

Highload considerations

Density (Щільність Pod’ів)

• За замовчуванням K8s обмежує ~110 Pod’ів на Node
• Обмеження:
  • Кількість IP в VPC (AWS)
  • Навантаження на kube-proxy (iptables rules)
  • Навантаження на etcd (більше Pod’ів = більше об’єктів)
  • CPU overhead від kubelet

HugePages

Для важких додатків (БД, in-memory caches):

resources:
  limits:
    hugepages-2Mi: 1Gi
    memory: 4Gi

Потребує налаштування на рівні ОС:

sysctl -w vm.nr_hugepages=512

Edge Cases

NotReady Node

Timeline:
T+0s:    Node перестає слати heartbeats
T+40s:   Node condition = NotReady
T+5m:    Pod eviction починається
T+5m+:   Pod'и перестворюються на інших Node

Tuning:

# kube-controller-manager flags
--node-monitor-period=5s
--node-monitor-grace-period=40s
--pod-eviction-timeout=5m

Kernel Panic

Якщо ядро падає — kubelet не може повідомити про це. Control Plane чекає heartbeat timeout. Це найскладніший випадок для автоматизації.

Node Affinity і Taints

Taints (Відштовхування)

# Позначити Node
kubectl taint nodes node1 gpu=true:NoSchedule

# Лише Pod з toleration запуститься

tolerations:
- key: "gpu"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"

Node Affinity (Притягнення)

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: disktype
          operator: In
          values: [ssd]

Node Problem Detector

DaemonSet для моніторингу здоров’я Node:

• Моніторить ядро, диски, мережу
• Повідомляє про проблеми в API
• Інтегрується з Prometheus

Autoscaling Node

Cluster Autoscaler:

• Додає Node при Pending Pod’ах
• Видаляє недогружені Node
• Інтегрується з cloud provider

Karpenter (AWS):

• Швидший і гнучкіший
• Обирає оптимальний тип інстансу
• Підтримка Spot instances

Резюме для Senior

• Node — абстракція над “залізом”. kubelet — ключовий процес.
• Завжди конфігуруйте Resources Requests & Limits для коректного eviction.
• Розрізняйте Capacity (фізичний ресурс) і Allocatable (доступний для Pod’ів).
• Eviction алгоритм пріоритезує за QoS класами.
• На highload: density limits, HugePages, node affinity.
• NotReady timeout (5 хв) — tunable параметр для критичних систем.
• Taints/Tolerations + Node Affinity — інструменти для спеціалізованих Node.

---

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

Обов’язково знати:

• Node — робочий сервер K8s; Worker Node запускає Pod’и, Control Plane керує кластером
• Компоненти Node: kubelet (агент), kube-proxy (мережа), container runtime (containerd)
• Allocatable < Capacity — частина ресурсів резервується для ОС і K8s
• Eviction видаляє Pod’и за QoS класом: BestEffort → Burstable → Guaranteed
• NotReady Node: K8s чекає ~5 хвилин (pod-eviction-timeout) перед переносом Pod’ів
• Taints (відштовхування) + Tolerations (допуск) + Node Affinity (притягнення) — scheduling
• Cluster Autoscaler / Karpenter — автоматичне додавання/видалення Node

Часті уточнюючі питання:

• «Що буде якщо kubelet впаде?» — Pod’и на Node перестають керуватися; Node → NotReady
• «Що таке Allocatable?» — Ресурси доступні для Pod’ів (Capacity мінус резерв ОС і K8s)
• «Коли Pod eviction спрацьовує?» — При MemoryPressure, DiskPressure, PIDPressure на Node
• «Чим Cluster Autoscaler відрізняється від Karpenter?» — Karpenter швидший, розумніше обирає інстанси

Червоні прапорці (НЕ говорити):

• «Node = Pod» (Node — сервер, Pod — одиниця запуску на ньому)
• «kubelet на Control Plane» (kubelet лише на Worker Nodes)
• «Capacity = ресурси для Pod’ів» (Allocatable, не Capacity)
• «Docker-shim все ще використовується» (видалено в K8s v1.24; containerd/CRI-O)

Пов’язані теми:

• [[Що таке Pod в Kubernetes]] — що запускається на Node
• [[Що таке Kubernetes і навіщо він потрібен]] — загальна архітектура
• [[Як відбувається масштабування в Kubernetes]] — Cluster Autoscaler