Управление Kubernetes объектами

Инструмент командной строки kubectl поддерживает несколько различных способов создания и управления объектами Kubernetes. В этом посте представлен обзор различных подходов.

Методы управления

Предупреждение: объект Kubernetes должен управляться с использованием только одного метода. Смешивание методов для одного и того же объекта приводит к неопределенному поведению.

Техника управления: Императивные команды
Работает c живыми объектами
Рекомендуемая среда: Разрабатываемые проекты
Кривая обучения: наименьшая

Техника управления: Конфигурация императивного объекта
Работает c отдельными файлами
Рекомендуемая среда: Производственные проекты
Кривая обучения: умеренная

Техника управления: Конфигурация декларативного объекта
Работает c каталогами файлов
Рекомендуемая среда: Производственные проекты
Кривая обучения: наивысшая

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

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

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

Примеры

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

kubectl run nginx --image nginx

Сделайте то же самое, используя другой синтаксис:

kubectl create deployment nginx --image nginx

Компромиссы

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

Команды просты, легки в освоении и легко запоминаются.
Команды требуют только одного шага для внесения изменений в кластер.

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

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

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

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

Предупреждение: императивная команда replace заменяет существующую спецификацию на новую, удаляя все изменения объекта, отсутствующего в файле конфигурации. Этот подход не должен использоваться с типами ресурсов, спецификации которых обновляются независимо от файла конфигурации. Например, для служб типа LoadBalancer поле externalIPs обновляется независимо от конфигурации самим кластером.

Примеры

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

kubectl create -f nginx.yaml

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

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

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

kubectl replace -f nginx.yaml

Компромиссы

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

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

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

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

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

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

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

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

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

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

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

Примеры

Обработайте все файлы конфигурации объектов в каталоге config и создайте или исправьте живые объекты. Вы можете сначала посмотреть, какие изменения будут внесены, а затем применить:

kubectl diff -f configs/
kubectl apply -f configs/

Рекурсивно обрабатывать каталоги:

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

Компромиссы

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

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

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

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

Поиск по этому блогу

Kubernetes блог