---
title: Управление объектами Kubernetes
content_type: concept
weight: 15
---

<!-- overview -->

В инструменте командной строки `kubectl` есть несколько разных способов создания и управления объектами Kubernetes. На этой странице рассматриваются различные подходы. Изучите [документацию по Kubectl](https://kubectl.docs.kubernetes.io) для получения подробной информации по управлению объектами с помощью Kubectl.



<!-- body -->

## Способы управления

{{< warning >}}

Используйте только один способ для управления объектами Kubernetes. Применение нескольких методов управления к одному и тому же объекту может привести к неопределенному поведению.

{{< /warning >}}

| Способ управления             | Область применения          |Рекомендуемое окружение | Количество поддерживаемых авторов  | Трудность изучения |
|----------------------------------|----------------------|------------------------|--------------------|----------------|
| Императивные команды              | Активные объекты         | Проекты в стадии разработки   | 1+                 | Низкая         |
| Императивная конфигурация объекта  | Отдельные файлы     | Продакшен-проекты    | 1                  | Средняя       |
| Декларативная конфигурация объекта | Директории или файлы | Продакшен-проекты    | 1+                 | Сложная        |

## Императивные команды

При использовании императивных команд пользователь работает непосредственно с активными (текущими) объектами в кластере. Пользователь указывает выполняемые операции команде `kubectl` в качестве аргументов или флагов.

Это самый простой способ начать или выполнять одноразовые задачи в кластере. Из-за того, что происходит работа с активными объектами напрямую, нет возможности посмотреть историю предыдущих конфигураций.

### Примеры

Запустите экземпляр контейнера nginx, посредством создания объекта Deployment:

```sh
kubectl run nginx --image nginx
```

То же самое, но с другим синтаксисом:

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

### Плюсы и минусы

Преимущества по сравнению с конфигурацией объекта:

- Простые команды, которые легко выучить и запомнить.
- Для применения изменений в кластер нужно только выполнить команды.

Недостатки по сравнению с конфигурацией объекта:

- Команды не интегрированы с процессом проверки (обзора) изменений.
- У команд нет журнала с изменениями.
- Команды не дают источник записей, за исключением активных объектов.
- Команды не содержат шаблон для создания новых объектов.

## Императивная конфигурация объекта

В случае использования императивной конфигурации объекта команде kubectl устанавливают действие (создание, замена и т.д.), необязательные флаги и как минимум одно имя файла. Файл должен содержать полное определение объекта в формате YAML или JSON.

Посмотрите [Справочник API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) для получения более подробной информации про определения объекта.

{{< warning >}}

Императивная команда `replace` заменяет существующую спецификацию новой (переданной), удаляя все изменения в объекте, которые не определены в конфигурационном файле. Такой подход не следует использовать для типов ресурсов, спецификации которых обновляются независимо от конфигурационного файла.
Например, поле `externalIPs` в сервисах типа `LoadBalancer` обновляется кластером независимо от конфигурации.

{{< /warning >}}

### Примеры

Создать объекты, определенные в конфигурационном файле:

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

Удалить объекты, определенные в двух конфигурационных файлах:

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

Обновить объекты, определенные в конфигурационном файле, перезаписав текущую конфигурацию:

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

### Плюсы и минусы

Преимущества по сравнению с императивными командами:

- Конфигурация объекта может храниться в системе управления версиями, такой как Git.
- Конфигурация объекта может быть интегрирована с процессами проверки изменений и логирования.
- Конфигурация объекта предусматривает шаблон для создания новых объектов.

Недостатки по сравнению с императивными командами:

- Конфигурация объекта требует наличие общего представления об схеме объекта.
- Конфигурация объекта предусматривает написание файла YAML.

Преимущества по сравнению с декларативной конфигурацией объекта:

- Императивная конфигурация объекта проще и легче для понимания.
- Начиная с Kubernetes 1.5, конфигурация императивных объектов стала лучше и совершеннее.

Недостатки по сравнению с декларативной конфигурацией объекта:

- Императивная конфигурация объекта наилучшим образом работает с файлами, а не с директориями.
- Обновления текущих объектов должны быть описаны в файлах конфигурации, в противном случае они будут потеряны при следующей замене.

## Декларативная конфигурация объекта

При использовании декларативной конфигурации объекта пользователь работает с локальными конфигурационными файлами объекта, при этом он не определяет операции, которые будут выполняться над этими файлами. Операции создания, обновления и удаления автоматически для каждого объекта определяются `kubectl`. Этот механизм позволяет работать с директориями, в ситуациях, когда для разных объектов может потребоваться выполнение других операций.

{{< note >}}
Декларативная конфигурация объекта сохраняет изменения, сделанные другими, даже если эти изменения не будут зафиксированы снова в конфигурационный файл объекта.
Это достигается путем использования API-операции `patch`, чтобы записать только обнаруженные изменения, а не использовать для этого API-операцию `replace`, которая полностью заменяет конфигурацию объекта.
{{< /note >}}

### Примеры

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

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

Рекурсивная обработка директорий:

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

### Плюсы и минусы

Преимущества по сравнению с императивной конфигурацией объекта:

- Изменения, внесенные непосредственно в активные объекты, будут сохранены, даже если они не отражены в конфигурационных файлах.
- Декларативная конфигурация объекта лучше работает с директориями и автоматически определяет тип операции (создание, частичное обновление, удаление) каждого объекта.

Недостатки по сравнению с императивной конфигурацией объекта:

- Декларативную конфигурацию объекта сложнее отладить и понять, когда можно получить неожиданные результаты.
- Частичные обновления с использованием различий приводит к сложным операциям слияния и исправления.



## {{% heading "whatsnext" %}}


- [Управление объектами 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/{{< param "version" >}}/)