# Цикл синхронізації Kubelet

LLMS index: [llms.txt](/llms.txt)

---

[Kubelet](/docs/reference/command-line-tools-reference/kubelet/) — це основний "агент вузла", який створює та відстежує Podʼи на кожному вузлі. `kubelet` запускає цикл синхронізації, який періодично узгоджує бажаний стан (специфікацію Podʼів) з фактичним станом запущених контейнерів.

1. **Цикл синхронізації (Sync Loop)**: Цикл синхронізації ставить у чергу роботу (агреговану з багатьох джерел) для Podʼів, призначених для його вузла (де `nodeName` збігається з вузлом). Протягом кожного циклу субпроцеси, що називаються «pod workers», намагатимуться узгодити бажаний стан цих Podʼів з поточним станом запущених контейнерів.
2. **Синхронізація Podʼів (Sync Pod)**: Більшість логіки `kubelet` зберігається в наборі функцій у межах інтерфейсу `podSyncer`, включаючи функцію `SyncPod` та її варіанти (наприклад, `SyncTerminatingPod` та `SyncTerminatedPod`). Під час кожного циклу синхронізації відповідна функція `podSyncer` буде виконана для кожного Podʼа, намагаючись привести його стан на вузлі до бажаного стану.
3. **<a class='glossary-tooltip' title='Протокол для звʼязку між kubelet та локальним середовищем виконання контейнера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/architecture/cri' target='_blank' aria-label='Container Runtime Interface'>Container Runtime Interface</a> (CRI)**: Щоб фактично запускати контейнери, `kubelet` використовує CRI для взаємодії з середовищем виконання контейнерів (наприклад, containerd або CRI-O). `kubelet` виступає як клієнт, надаючи вказівки середовищу виконання створити "пісочницю Podʼа", а потім створити/запустити окремі контейнери, визначені в специфікації Podʼа.
4. **PLEG (Pod Lifecycle Event Generator)**: `kubelet` потрібно знати, коли контейнери запускаються, зупиняються або виходять з ладу. Він покладається на компонент з назвою PLEG, який періодично опитує середовище виконання для стандартного стану всіх контейнерів. PLEG генерує події, які пробуджують цикл синхронізації для оновлення статусу Podʼа.

Через цей механізм опитування стан, який видно в API (наприклад, за допомогою команди `kubectl get pod`), може дещо запізнюватися порівняно з тим, що насправді відбувається на вузлі.