Управление объектами Kubernetes
В инструменте командной строки kubectl
есть несколько разных способов создания и управления объектами Kubernetes. На этой странице рассматриваются различные подходы. Изучите документацию по Kubectl для получения подробной информации по управлению объектами с помощью Kubectl.
Способы управления
Способ управления | Область применения | Рекомендуемое окружение | Количество поддерживаемых авторов | Трудность изучения |
---|---|---|---|---|
Императивные команды | Активные объекты | Проекты в стадии разработки | 1+ | Низкая |
Императивная конфигурация объекта | Отдельные файлы | Продакшен-проекты | 1 | Средняя |
Декларативная конфигурация объекта | Директории или файлы | Продакшен-проекты | 1+ | Сложная |
Императивные команды
При использовании императивных команд пользователь работает непосредственно с активными (текущими) объектами в кластере. Пользователь указывает выполняемые операции команде kubectl
в качестве аргументов или флагов.
Это самый простой способ начать или выполнять одноразовые задачи в кластере. Из-за того, что происходит работа с активными объектами напрямую, нет возможности посмотреть историю предыдущих конфигураций.
Примеры
Запустите экземпляр контейнера nginx, посредством создания объекта Deployment:
kubectl run nginx --image nginx
То же самое, но с другим синтаксисом:
kubectl create deployment nginx --image nginx
Плюсы и минусы
Преимущества по сравнению с конфигурацией объекта:
- Простые команды, которые легко выучить и запомнить.
- Для применения изменений в кластер нужно только выполнить команды.
Недостатки по сравнению с конфигурацией объекта:
- Команды не интегрированы с процессом проверки (обзора) изменений.
- У команд нет журнала с изменениями.
- Команды не дают источник записей, за исключением активных объектов.
- Команды не содержат шаблон для создания новых объектов.
Императивная конфигурация объекта
В случае использования императивной конфигурации объекта команде kubectl устанавливают действие (создание, замена и т.д.), необязательные флаги и как минимум одно имя файла. Файл должен содержать полное определение объекта в формате YAML или JSON.
Посмотрите Справочник API для получения более подробной информации про определения объекта.
replace
заменяет существующую спецификацию новой (переданной), удаляя все изменения в объекте, которые не определены в конфигурационном файле. Такой подход не следует использовать для типов ресурсов, спецификации которых обновляются независимо от конфигурационного файла.
Например, поле externalIPs
в сервисах типа LoadBalancer
обновляется кластером независимо от конфигурации.
Примеры
Создать объекты, определенные в конфигурационном файле:
kubectl create -f nginx.yaml
Удалить объекты, определенные в двух конфигурационных файлах:
kubectl delete -f nginx.yaml -f redis.yaml
Обновить объекты, определенные в конфигурационном файле, перезаписав текущую конфигурацию:
kubectl replace -f nginx.yaml
Плюсы и минусы
Преимущества по сравнению с императивными командами:
- Конфигурация объекта может храниться в системе управления версиями, такой как Git.
- Конфигурация объекта может быть интегрирована с процессами проверки изменений и логирования.
- Конфигурация объекта предусматривает шаблон для создания новых объектов.
Недостатки по сравнению с императивными командами:
- Конфигурация объекта требует наличие общего представления об схеме объекта.
- Конфигурация объекта предусматривает написание файла YAML.
Преимущества по сравнению с декларативной конфигурацией объекта:
- Императивная конфигурация объекта проще и легче для понимания.
- Начиная с Kubernetes 1.5, конфигурация императивных объектов стала лучше и совершеннее.
Недостатки по сравнению с декларативной конфигурацией объекта:
- Императивная конфигурация объекта наилучшим образом работает с файлами, а не с директориями.
- Обновления текущих объектов должны быть описаны в файлах конфигурации, в противном случае они будут потеряны при следующей замене.
Декларативная конфигурация объекта
При использовании декларативной конфигурации объекта пользователь работает с локальными конфигурационными файлами объекта, при этом он не определяет операции, которые будут выполняться над этими файлами. Операции создания, обновления и удаления автоматически для каждого объекта определяются kubectl
. Этот механизм позволяет работать с директориями, в ситуациях, когда для разных объектов может потребоваться выполнение других операций.
patch
, чтобы записать только обнаруженные изменения, а не использовать для этого API-операцию replace
, которая полностью заменяет конфигурацию объекта.
Примеры
Обработать все конфигурационные файлы объектов в директории configs
и создать либо частично обновить активные объекты. Сначала можно выполнить diff
, чтобы посмотреть, какие изменения будут внесены, и только после этого применить их:
kubectl diff -f configs/
kubectl apply -f configs/
Рекурсивная обработка директорий:
kubectl diff -R -f configs/
kubectl apply -R -f configs/
Плюсы и минусы
Преимущества по сравнению с императивной конфигурацией объекта:
- Изменения, внесенные непосредственно в активные объекты, будут сохранены, даже если они не отражены в конфигурационных файлах.
- Декларативная конфигурация объекта лучше работает с директориями и автоматически определяет тип операции (создание, частичное обновление, удаление) каждого объекта.
Недостатки по сравнению с императивной конфигурацией объекта:
- Декларативную конфигурацию объекта сложнее отладить и понять, когда можно получить неожиданные результаты.
- Частичные обновления с использованием различий приводит к сложным операциям слияния и исправления.
Что дальше
- Управление объектами Kubernetes с помощью императивных команд
- Управление объектами Kubernetes с помощью императивной конфигурации объекта
- Управление объектами Kubernetes с помощью декларативной конфигурации объекта
- Управление объектами Kubernetes с помощью Kustomize (декларативный способ)
- Справочник по командам Kubectl
- Документация Kubectl
- Справочник API Kubernetes