kubectl применить против kubectl создать?

В документации я понял, что kubectl apply= kubectl create + kubectl replace. Ссылка

Насколько я понимаю, если я хочу создать новый ресурс k8s в кластере, я должен использовать операцию kubectl create. Теперь, если я хочу обновить что-либо в живых ресурсах k8s, я должен использовать операцию kubectl replace.

Если я хочу выполнить обе операции (создать новый ресурс k8s, а также обновить живые ресурсы k8s), я должен использовать операцию kubectl apply

Мои вопросы: почему в кластере есть три операции для выполнения одной и той же задачи? Каковы варианты использования для этих операций? Чем они отличаются друг от друга под капотом?

В данный момент я использую kubectl create для создания новых ресурсов в кластере. Спасибо

Ответы

Ответ 1

Это два разных подхода. kubectl create - это то, что мы называем императивным управлением. При таком подходе вы сообщаете Kubernetes API, что вы хотите создать, заменить или удалить, а не то, как вы хотите, чтобы ваш кластерный мир K8s выглядел.

kubectl apply является частью подхода декларативного управления, в котором изменения, которые вы, возможно, применили к живому объекту (т.е. через scale), сохраняются, даже если вы apply вносите другие изменения в объект.

Подробнее об императивном и декларативном управлении вы можете прочитать в документации Kubernetes Object Management.

Ответ 2

При запуске в скрипте CI у вас будут проблемы с императивными командами, так как create вызывает ошибку, если ресурс уже существует.

Что вы можете сделать, это применить (декларативный шаблон) вывод вашей императивной команды, используя параметры --dry-run=true и -o yaml:

kubectl create whatever --dry-run=true -o yaml | kubectl apply -f -

Команда выше не вызовет ошибку, если ресурс уже существует (и при необходимости обновит ресурс).

Это очень полезно в некоторых случаях, когда вы не можете использовать декларативный шаблон (например, при создании секрета реестра Docker).

Ответ 3

Просто чтобы дать более прямой ответ, исходя из моего понимания:

apply - вносит дополнительные изменения
create - перезаписывает все изменения


Взяв это из статьи DigitalOcean, которая была связана с веб-сайтом Kubernetes:

Мы используем apply вместо create здесь, чтобы в будущем мы могли постепенно применять изменения к объектам Ingress Controller вместо того, чтобы полностью перезаписывать их.

Ответ 4

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

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

kubectl create другой стороны, kubectl create создаст (не должно быть) ресурсы.

Ответ 5

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

kubectl run = kubectl create deployment

Преимущества:

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

Недостатки:

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

Это императивный объект конфигурации:

kubectl create -f your-object-config.yaml

kubectl delete -f your-object-config.yaml

kubectl replace -f your-object-config.yaml

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

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

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

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

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

  • Проще и проще для понимания.
  • Более зрелый после Kubernetes версии 1.5.

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

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

Это декларативный объектный конфиг

kubectl diff -f configs/

kubectl apply -f configs/

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

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

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

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

Ответ 6

kubectl create может одновременно работать с одним файлом конфигурации объекта. Это также известно как императивное управление

kubectl создать -f имя файла | URL

kubectl apply работает с каталогами и их подкаталогами, содержащими файлы конфигурации объектов yaml. Это также известно как декларативное управление. Можно выбрать несколько файлов конфигурации объектов из каталогов. kubectl apply -f каталог /

Подробности :
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/