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


267

Что я понял из документации, так это:

  • kubectl create = Создает новый ресурс k8s в кластере
  • kubectl replace = Обновляет ресурс в живом кластере
  • kubectl apply = если я хочу сделать создать + заменить ( ссылка )

Мои вопросы

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

Ответы:


317

Это два разных подхода:

Императивное управление

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

Декларативное управление

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

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


24
Какой из них будет использоваться в производстве?
Йогеш Джилхавар

11
@YogeshJilhawar - оба допустимых способа работать в производстве.
Гиваль

2
Так по сути, это как модификация целого объекта против частичного патча?
Ryall

12
Ответ на этот вопрос не подтвердил ли эти две операции kubectl createи kubectl applyимеет одинаковый эффект или нет.
Наваз

63
@ Наваз - Они делают разные вещи. kubectl createвыдаст ошибку, если ресурс уже существует. kubectl applyне будет. Разница в том, что в kubectl createчастности говорится «создай эту вещь», а в kubectl applyдругой - «делай все, что нужно (создай, обнови и т. Д.), Чтобы она выглядела так»
Мистер Лама

44

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

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

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

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

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


Либо удалите ресурс перед его созданием с флагом --ignore-not-found . Это не вызовет ошибку AlreadyExists . Например:kubectl delete deployment nginx --ignore-not-found; kubectl create deployment nginx --image=nginx
Ноам Манос

33

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

apply- вносит постепенные изменения в существующий объект
create- создает совершенно новый объект (ранее не существовавший / удаленный).


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

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


Это? например, когда мы используем docker-compose: + использовать applyкак docker-compose up -d+ использовать createкак docker-compose up -d --build?
Whoiskp

8

Это обязательные команды :

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 создают сложные операции слияния и исправления.

3

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

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

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


1

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

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

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

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


0

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

«творить» - это все равно что играть БОГА, взяв вещи в свои руки. Это хорошо для локальной отладки, когда вы хотите работать только с POD и не заботиться о Deployment / Replication Controller.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.