# Статичні Podʼи

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

---

Статичні Podʼи (_Static Pods_) керуються безпосередньо демоном kubelet на конкретному вузлі, без спостереження за ними з боку <a class='glossary-tooltip' title='Компонент панелі управління, що обслуговує API Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/architecture/#kube-apiserver' target='_blank' aria-label='API server'>API server</a>. На відміну від Podʼів, які керуються панеллю управління (наприклад, <a class='glossary-tooltip' title='Керує реплікованим застосунком у вашому кластері.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/controllers/deployment/' target='_blank' aria-label='Deployment'>Deployment</a>), kubelet стежить за кожним статичним Podʼом і перезапускає його у разі збою.

Статичні Podʼи завжди привʼязані до одного <a class='glossary-tooltip' title='Агент, запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів у Podʼах.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/command-line-tools-reference/kubelet' target='_blank' aria-label='kubelet'>kubelet</a> на конкретному вузлі.

Основне призначення статичних Podів — запуск самостійно розміщеної панелі управління: іншими словами, використання kubelet для контролю окремих [компонентів панелі управління](/docs/concepts/overview/components/#control-plane-components). Наприклад, [kubeadm](/docs/reference/setup-tools/kubeadm/) використовує статичні Podʼи для запуску `kube-apiserver`, `kube-controller-manager`, `kube-scheduler` та `etcd` на вузлах панелі управління.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Якщо ваш кластер запускає компоненти панелі управління як Podʼи, вони, ймовірно, є статичними Podʼами. Ви можете розпізнати їхні дзеркальні Podʼи в просторі імен <code>kube-system</code> за анотацією <code>kubernetes.io/config.mirror</code>.</div>


## Дзеркальні Podʼи {#mirror-pods}

Kubelet автоматично намагається створити <a class='glossary-tooltip' title='Обʼєкт в API-сервері, який відстежує статичний Pod на kubelet.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/glossary/?all=true#term-mirror-pod' target='_blank' aria-label='дзеркальний Pod'>дзеркальний Pod</a> на сервері API Kubernetes для кожного статичного Podʼа. Це означає, що Podʼи, що працюють на вузлі, видимі на сервері API, але не можуть бути керовані звідти. До назв Podів буде додано імʼя хоста вузла з дефісом перед ним.

Kubelet передає <a class='glossary-tooltip' title='Позначає обʼєкти атрибутами ідентифікації, які мають значення і є важливими для користувачів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/labels' target='_blank' aria-label='мітки'>мітки</a> зі статичного Podʼа до дзеркального Podʼа. Ви можете використовувати ці мітки як зазвичай через <a class='glossary-tooltip' title='Дозволяє користувачам фільтрувати ресурси за мітками.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/labels/' target='_blank' aria-label='селектори'>селектори</a>.

Якщо ви спробуєте використати `kubectl` для видалення дзеркального Podʼа з сервера API, kubelet _не_ видалить статичний Pod. Kubelet відтворить дзеркальний Pod.

## Обмеження {#limitations}

Специфікація статичного Podʼа не може посилатися на інші обʼєкти API, такі як <a class='glossary-tooltip' title='Забезпечує ідентифікацію для процесів, які працюють в Podʼі.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/tasks/configure-pod-container/configure-service-account/' target='_blank' aria-label='ServiceAccount'>ServiceAccount</a>, <a class='glossary-tooltip' title='Обʼєкт API, призначений для зберігання неконфіденційних даних у вигляді пар ключ-значення. Може використовуватися як змінні середовища, аргументи командного рядка чи файли конфігурації у томі.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/configuration/configmap/' target='_blank' aria-label='ConfigMap'>ConfigMap</a>, або <a class='glossary-tooltip' title='Зберігає конфіденційну інформацію, таку як паролі, токени OAuth та ключі SSH.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/configuration/secret/' target='_blank' aria-label='Secret'>Secret</a>.

Статичні Podʼи не підтримують [ефемерні контейнери](/docs/concepts/workloads/pods/ephemeral-containers/).

## Статичні Podʼи чи DaemonSets {#static-pods-vs-daemonsets}

<!-- Source: tasks/configure-pod-container/static-pod/ -->
Якщо ви запускаєте кластер Kubernetes і використовуєте статичні Podʼи для запуску Podʼів на кожному вузлі, вам, ймовірно, слід використовувати <a class='glossary-tooltip' title='Забезпечує запуск копії обʼєкта Pod на певному наборі вузлів у кластері.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/controllers/daemonset' target='_blank' aria-label='DaemonSet'>DaemonSet</a>.

Статичні Podʼи не керуються панеллю управління, тому їх не можна розгортати, відкатувати або масштабувати за допомогою стандартних механізмів Kubernetes. DaemonSet надає ці можливості і є рекомендованим підходом для запуску робочих навантажень на рівні вузла.

Статичні Podʼи запускаються kubelet до того, як API сервер стане доступним, що робить їх придатними для ініціалізації компонентів панелі управління. DaemonSet вимагає працюючої панелі управління.

## Що далі

- Дізнайтеся, як [створювати статичні Podʼи](/docs/tasks/configure-pod-container/static-pod/).
- Дізнайтеся про [компоненти Kubernetes](/docs/concepts/overview/components/) та як панель управління використовує статичні Podʼи.
- Дізнайтеся про [DaemonSets](/docs/concepts/workloads/controllers/daemonset/) як альтернативу статичним Podʼам.