# Управління обʼєктами Kubernetes

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

---

<!-- overview -->
Інструмент командного рядка `kubectl` підтримує кілька різних способів створення та управління <a class='glossary-tooltip' title='Сутність у системі Kubernetes, що представляє частину стану вашого кластера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/#kubernetes-objects' target='_blank' aria-label='обʼєктами'>обʼєктами</a> Kubernetes. Цей документ надає огляд різних підходів. Для отримання деталей щодо управління обʼєктами за допомогою Kubectl читайте [Книгу Kubectl](https://kubectl.docs.kubernetes.io).

<!-- body -->

## Техніки управління {#management-techniques}

<div class="alert alert-danger" role="note"><h4 class="alert-heading">Попередження:</h4>Обʼєкт Kubernetes повинен управлятися лише з використанням однієї техніки. Змішування різних технік для того самого обʼєкта призводить до невизначеної поведінки.</div>


| Техніка управління                | Діє на       | Рекомендоване середовище | Підтримувані інструменти  | Крива навчання |
|-----------------------------------|--------------|--------------------------|---------------------------|----------------|
| Імперативні команди               | Живі обʼєкти | Проєкти розробки         | 1+                        | Найлегша       |
| Імперативна конфігурація обʼєктів | Окремі файли | Продуктові проєкти       | 1                         | Середня        |
| Декларативна конфігурація обʼєктів| Теки файлів  | Продуктові проєкти       | 1+                        | Найскладніша   |

## Імперативні команди {#imperative-commands}

При використанні імперативних команд користувач працює безпосередньо з живими обʼєктами в кластері. Користувач надає операції команді `kubectl` у вигляді аргументів чи прапорців.

Це рекомендований спосіб початку роботи або виконання одноразового завдання в кластері. Оскільки цей метод працює безпосередньо з живими обʼєктами, він не зберігає жодної історичної конфігурації.

### Приклади {#examples}

Запустіть екземпляр контейнера nginx, створивши обʼєкт розгортання (Deployment):

```sh
kubectl create deployment nginx --image nginx
```

### Компроміси {#trade-offs}

Переваги порівняно із конфігуруванням обʼєктів:

- Команди виражені як одне слово дії.
- Команди вимагають лише одного кроку для внесення змін до кластера.

Недоліки порівняно із конфігуруванням обʼєктів:

- Команди не інтегруються з процесами перегляду змін.
- Команди не надають логів аудиту, повʼязаних зі змінами.
- Команди не надають джерела записів, окрім того, що є на живому сервері.
- Команди не надають шаблону для створення нових обʼєктів.

## Імперативне конфігурування обʼєктів {#imperative-object-configuration}

У імперативній конфігурації обʼєктів команда `kubectl` вказує операцію (створити, замінити, тощо), необовʼязкові прапорці та принаймні одне імʼя файлу. Зазначений файл повинен містити повне визначення обʼєкта у форматі YAML або JSON.

Див. [API-довідник](/docs/reference/generated/kubernetes-api/v1.36/) для отримання докладніших відомостей щодо визначення обʼєктів.

<div class="alert alert-danger" role="note"><h4 class="alert-heading">Попередження:</h4>Імперативна команда <code>replace</code> замінює поточну специфікацію на нову, вилучаючи всі зміни обʼєкта, які відсутні в файлі конфігурації. Цей підхід не повинен використовуватися із типами ресурсів, специфікації яких оновлюються незалежно від файлу конфігурації. Наприклад, у сервісів типу <code>LoadBalancer</code> поле <code>externalIPs</code> оновлюється кластером незалежно від файлу конфігурації.</div>


### Приклади {#examples-1}

Створити обʼєкти, визначені у файлі конфігурації:

```sh
kubectl create -f nginx.yaml
```

Видалити обʼєкти, визначені у двох файлах конфігурації:

```sh
kubectl delete -f nginx.yaml -f redis.yaml
```

Оновити обʼєкти, визначені у файлі конфігурації, перезаписавши живу конфігурацію:

```sh
kubectl replace -f nginx.yaml
```

### Компроміси {#trade-offs-1}

Переваги порівняно з імперативними командами:

- Конфігурація обʼєктів може зберігатися у системі контролю версій, такій як Git.
- Конфігурація обʼєктів може інтегруватися з процесами, такими як перегляд змін перед публікацією (push) та аудитом.
- Конфігурація обʼєктів надає шаблон для створення нових обʼєктів.

Недоліки порівняно з імперативними командами:

- Конфігурація обʼєктів потребує базового розуміння схеми обʼєкта.
- Конфігурація обʼєктів потребує додаткового кроку у вигляді написання файлу YAML.

Переваги порівняно із декларативною конфігурацією обʼєктів:

- Поведінка імперативної конфігурації обʼєктів простіша та її легше зрозуміти.
- З версії Kubernetes 1.5 імперативна конфігурація обʼєктів більш зріла.

Недоліки порівняно із декларативною конфігурацією обʼєктів:

- Імперативна конфігурація обʼєктів працює краще з файлами, а не з теками.
- Оновлення живих обʼєктів повинно відображатися у файлах конфігурації, або вони будуть втрачені під час наступної заміни.

## Декларативна конфігурація обʼєктів {#declarative-object-configuration}

При використанні декларативної конфігурації обʼєктів користувач працює з конфігураційними файлами обʼєктів, збереженими локально, проте користувач не визначає операції, які слід виконати над файлами. Операції створення, оновлення та видалення автоматично визначаються для кожного обʼєкта за допомогою `kubectl`. Це дозволяє працювати з теками, де для різних обʼєктів можуть бути потрібні різні операції.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Декларативна конфігурація обʼєктів зберігає зміни, внесені іншими учасниками, навіть якщо зміни не зливаються назад у файл конфігурації обʼєкта. Це можливо за допомогою використання операції API <code>patch</code> для запису тільки спостережуваних відмінностей, замість використання операції <code>replace</code> для заміни всього файлу конфігурації обʼєкта.</div>


### Приклади {#examples-2}

Обробити всі файли конфігурації обʼєктів у теці `configs` та створити або внести патчі до живих обʼєктів. Спочатку ви можете використовувати `diff`, щоб побачити, які зміни будуть внесені, а потім застосовувати:

```sh
kubectl diff -f configs/
kubectl apply -f configs/
```

Рекурсивно обробити теки:

```sh
kubectl diff -R -f configs/
kubectl apply -R -f configs/
```

### Компроміси {#trade-offs-2}

Переваги порівняно з імперативною конфігурацією обʼєктів:

- Зміни, внесені безпосередньо в живі обʼєкти, зберігаються, навіть якщо вони не зливаються назад у файли конфігурації.
- Декларативна конфігурація обʼєктів краще підтримує роботу з теками та автоматично визначає типи операцій (створення, патч, видалення) для кожного обʼєкта.

Недоліки порівняно з імперативною конфігурацією обʼєктів:

- Декларативна конфігурація обʼєктів важко налагоджувати, і результати її роботи важко зрозуміти, коли вони несподівані.
- Часткові оновлення за допомогою diffs створюють складні операції злиття та накладання патчів.

## Що далі

- [Управління обʼєктами Kubernetes за допомогою імперативних команд](/docs/tasks/manage-kubernetes-objects/imperative-command/)
- [Імперативне управління обʼєктами Kubernetes за допомогою файлів конфігурації](/docs/tasks/manage-kubernetes-objects/imperative-config/)
- [Декларативне управління обʼєктами Kubernetes за допомогою файлів конфігурації](/docs/tasks/manage-kubernetes-objects/declarative-config/)
- [Декларативне управління обʼєктами Kubernetes за допомогою Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/)
- [Довідник команд Kubectl](/docs/reference/generated/kubectl/kubectl-commands/)
- [Книга Kubectl](https://kubectl.docs.kubernetes.io)
- [Довідник API Kubernetes](/docs/reference/generated/kubernetes-api/v1.36/)