# Створення статичних Podʼів

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

---

<!-- overview -->

Ця сторінка показує, як створювати _статичні Podʼи_ на вузлі. Для огляду того, що таке статичні Podʼи і коли їх використовувати, див. [Статичні Podʼи](/docs/concepts/workloads/pods/static-pods/).

## Перш ніж ви розпочнете

<p>Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою <a href="https://minikube.sigs.k8s.io/docs/tutorials/multi_node/">minikube</a> або використовувати одну з цих пісочниць:</p>
<ul>
<li><a href="https://labs.iximiuz.com/playgrounds?category=kubernetes&filter=all">iximiuz Labs</a></li>
<li><a href="https://killercoda.com/playgrounds/scenario/kubernetes">Killercoda</a></li>
<li><a href="https://kodekloud.com/public-playgrounds">KodeKloud</a></li>
</ul>
 
  <p>Для перевірки версії введіть  <code>kubectl version</code>.</p>


На цій сторінці передбачається, що ви використовуєте <a class='glossary-tooltip' title='CRI-O — це легке середовище виконання контейнерів, спеціально розроблене для Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='https://cri-o.io/#what-is-cri-o' target='_blank' aria-label='CRI-O'>CRI-O</a> для запуску Podʼів, а також що ваші вузли працюють під управлінням операційної системи Fedora. Інструкції для інших дистрибутивів або встановлень Kubernetes можуть відрізнятися.

<!-- steps -->

## Створення статичного Podʼа {#static-pod-creation}

Ви можете налаштувати статичний Pod з використанням [файлу конфігурації, що зберігається в файловій системі](#configuration-files) або [файлу конфігурації, що зберігається на вебсервері](#pods-created-via-http).

### Статичний Pod з файлової системи {#configuration-files}

Маніфести — це стандартні визначення Podʼів у форматі JSON або YAML в певній теці. Використовуйте поле `staticPodPath: <тека>` у [конфігураційному файлі kubelet](/docs/reference/config-api/kubelet-config.v1beta1/), який періодично сканує теку і створює/видаляє статичні Podʼи, коли у цій теці зʼявляються/зникають файли YAML/JSON. Зверніть увагу, що kubelet ігнорує файли, що починаються з крапки при скануванні вказаної теки.

<div class="alert alert-caution" role="note"><h4 class="alert-heading">Увага:</h4>Kubelet обробляє <strong>всі файли, що не починаються з крапки</strong>, у теці статичних Podʼів — фільтрування за розширенням файлу не здійснюється. Наприклад, якщо ви створюєте резервну копію маніфесту, виконавши команду <code>cp kube-apiserver.yaml kube-apiserver.yaml.backup</code>, kubelet прочитає <strong>обидва</strong> файли і спробує створити статичний Pod з кожного з них. Коли два файли визначають Pod з однаковою назвою, результат є невизначеним і може призвести до того, що застаріла специфікація резервної копії буде тихо застосована замість поточного маніфесту. Якщо ви створюєте резервну копію, зберігайте її <strong>поза</strong> текою статичних Podʼів (наприклад, у <code>/etc/kubernetes/backup/</code>).</div>


Наприклад, так можна запустити простий вебсервер як статичний Pod:

1. Виберіть вузол, на якому ви хочете запустити статичний Pod. У цьому прикладі це `my-node1`.

   ```shell
   ssh my-node1
   ```

2. Виберіть теку, наприклад `/etc/kubernetes/manifests`, і помістіть туди визначення Podʼа вебсервера, наприклад, `/etc/kubernetes/manifests/static-web.yaml`:

   ```shell
   # Виконайте цю команду на вузлі, де працює kubelet
   mkdir -p /etc/kubernetes/manifests/
   cat <<EOF >/etc/kubernetes/manifests/static-web.yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: static-web
     labels:
       role: myrole
   spec:
     containers:
       - name: web
         image: nginx
         ports:
           - name: web
             containerPort: 80
             protocol: TCP
   EOF
   ```

3. Налаштуйте kubelet на тому вузлі, щоб встановити значення `staticPodPath` в [конфігураційному файлі kubelet](/docs/reference/config-api/kubelet-config.v1beta1/). Див. [Встановлення параметрів kubelet через конфігураційний файл](/docs/tasks/administer-cluster/kubelet-config-file/) для отримання додаткової інформації.

   Альтернативний і застарілий метод полягає в налаштуванні kubelet на тому вузлі, щоб він шукав маніфести статичного Podʼа локально, використовуючи аргумент командного рядка. Щоб використовувати застарілий підхід, запустіть kubelet з аргументом `--pod-manifest-path=/etc/kubernetes/manifests/`.

4. Перезапустіть kubelet. У Fedora ви виконаєте:

   ```shell
   # Виконайте цю команду на вузлі, де працює kubelet
   systemctl restart kubelet
   ```

### Маніфест Podʼа, розміщений на вебсервері {#pods-created-via-http}

Kubelet періодично завантажує файл, вказаний аргументом `--manifest-url=<URL>`, і розглядає його як файл JSON/YAML, який містить визначення Podʼів. Подібно до того, як працюють [маніфести, розміщені в файловій системі](#configuration-files), kubelet перевіряє маніфест за розкладом. Якщо відбулися зміни в списку статичних Podʼів, kubelet застосовує їх.

Щоб скористатися цим підходом:

1. Створіть YAML-файл і збережіть його на веб-сервері, щоб ви могли передати URL цього файлу kubelet.

   ```yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: static-web
     labels:
       role: myrole
   spec:
     containers:
       - name: web
         image: nginx
         ports:
           - name: web
             containerPort: 80
             protocol: TCP
   ```

2. Налаштуйте kubelet на обраному вузлі для використання цього веб-маніфесту, оновивши файл конфігурації kubelet, щоб включити поле `staticPodURL`:

   ```yaml
   apiVersion: kubelet.config.k8s.io/v1beta1
   kind: KubeletConfiguration
   staticPodURL: "<URL-маніфесту>"
   ```

3. Перезапустіть kubelet. У Fedora ви виконаєте:

   ```shell
   # Виконайте цю команду на вузлі, де працює kubelet
   systemctl restart kubelet
   ```

## Спостереження за поведінкою статичного Podʼа {#behavior-of-static-pods}

Після запуску kubelet автоматично запускає всі визначені статичні Podʼи. Оскільки ви визначили статичний Pod і перезапустили kubelet, новий статичний Pod вже має бути запущений.

Ви можете переглянути запущені контейнери (включно зі статичними Podʼами), виконавши (на вузлі):

```shell
# Виконайте цю команду на вузлі, де працює kubelet
crictl ps
```

Вивід може бути наступним:

```console
CONTAINER       IMAGE                                 CREATED           STATE      NAME    ATTEMPT    POD ID
129fd7d382018   docker.io/library/nginx@sha256:...    11 minutes ago    Running    web     0          34533c6729106
```


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4><code>crictl</code> виводить URI образу та контрольну суму SHA-256. <code>NAME</code> буде виглядати більш подібним до: <code>docker.io/library/nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31</code>.</div>


Ви можете побачити дзеркальний Pod на сервері API:

```shell
kubectl get pods
```

```console
NAME                  READY   STATUS    RESTARTS        AGE
static-web-my-node1   1/1     Running   0               2m
```


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Переконайтеся, що kubelet має дозвіл на створення дзеркального Podʼа на сервері API. Якщо ні, запит на створення буде відхилено сервером API.</div>


<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:

```shell
kubectl delete pod static-web-my-node1
```

```console
pod "static-web-my-node1" deleted
```

Ви побачите, що Pod все ще працює:

```shell
kubectl get pods
```

```console
NAME                  READY   STATUS    RESTARTS   AGE
static-web-my-node1   1/1     Running   0          4s
```

Поверніться на вузол, де працює kubelet, і спробуйте вручну зупинити контейнер. Ви побачите, що після певного часу kubelet помітить це та автоматично перезапустить Pod:

```shell
# Виконайте ці команди на вузлі, де працює kubelet
crictl stop 129fd7d382018 # замініть на ID вашого контейнера
sleep 20
crictl ps
```

```console
CONTAINER       IMAGE                                 CREATED           STATE      NAME    ATTEMPT    POD ID
89db4553e1eeb   docker.io/library/nginx@sha256:...    19 seconds ago    Running    web     1          34533c6729106
```

Після того як ви визначите потрібний контейнер, ви можете отримати журнал для цього контейнера за допомогою `crictl`:

```shell
# Виконайте ці команди на вузлі, де працює контейнер
crictl logs <container_id>
```

```console
10.240.0.48 - - [16/Nov/2022:12:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
10.240.0.48 - - [16/Nov/2022:12:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
10.240.0.48 - - [16/Nove/2022:12:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
```

Щоб дізнатися більше про те, як налагоджувати за допомогою `crictl`, відвідайте [_Налагодження вузлів Kubernetes за допомогою crictl_](/docs/tasks/debug/debug-cluster/crictl/).

## Динамічне додавання та видалення статичних Podʼів {#dynamic-addition-and-removal-of-static-pods}

Запущений kubelet періодично сканує налаштовану теку (`/etc/kubernetes/manifests` у нашому прикладі) на предмет змін та додає/видаляє Podʼи при появі/зникненні файлів в цій теці.

```shell
# Це передбачає, що ви використовуєте файлову конфігурацію статичних Podʼів
# Виконайте ці команди на вузлі, де працює контейнер
mv /etc/kubernetes/manifests/static-web.yaml /tmp
sleep 20
crictl ps
# Ви бачите, що ніякий контейнер nginx не працює
mv /tmp/static-web.yaml  /etc/kubernetes/manifests/
sleep 20
crictl ps
```

```console
CONTAINER       IMAGE                                 CREATED           STATE      NAME    ATTEMPT    POD ID
f427638871c35   docker.io/library/nginx@sha256:...    19 seconds ago    Running    web     1          34533c6729106
```

## Що далі

* [Статичні Podʼи](/docs/concepts/workloads/pods/static-pods/)
* [Створення статичних файлів маніфестів Podʼів для компонентів панелі управління](/docs/reference/setup-tools/kubeadm/implementation-details/#generate-static-pod-manifests-for-control-plane-components)
* [Створення статичного файлу маніфесту Podʼа для локального etcd](/docs/reference/setup-tools/kubeadm/implementation-details/#generate-static-pod-manifest-for-local-etcd)
* [Налагодження вузлів Kubernetes за допомогою `crictl`](/docs/tasks/debug/debug-cluster/crictl/)
* [Дізнайтеся більше про `crictl`](https://github.com/kubernetes-sigs/cri-tools)
* [Налаштування екземплярів etcd як статичних Podʼів, керованих kubelet](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)