Информация этой страницы может быть устаревшей
Оригинальная (английская) версия этого документа обновлялась с момента последнего перевода, поэтому информация может быть устаревшей. Если вы читаете на английском, посмотрите на оригинальную версию с наиболее актуальной информацией: Kubernetes Object Management
В инструменте командной строки 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
Преимущества по сравнению с императивными командами:
Недостатки по сравнению с императивными командами:
Преимущества по сравнению с декларативной конфигурацией объекта:
Недостатки по сравнению с декларативной конфигурацией объекта:
При использовании декларативной конфигурации объекта пользователь работает с локальными конфигурационными файлами объекта, при этом он не определяет операции, которые будут выполняться над этими файлами. Операции создания, обновления и удаления автоматически для каждого объекта определяются kubectl. Этот механизм позволяет работать с директориями, в ситуациях, когда для разных объектов может потребоваться выполнение других операций.
patch, чтобы записать только обнаруженные изменения, а не использовать для этого API-операцию replace, которая полностью заменяет конфигурацию объекта.Обработать все конфигурационные файлы объектов в директории configs и создать либо частично обновить активные объекты. Сначала можно выполнить diff, чтобы посмотреть, какие изменения будут внесены, и только после этого применить их:
kubectl diff -f configs/
kubectl apply -f configs/
Рекурсивная обработка директорий:
kubectl diff -R -f configs/
kubectl apply -R -f configs/
Преимущества по сравнению с императивной конфигурацией объекта:
Недостатки по сравнению с императивной конфигурацией объекта: