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

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

Мои вопросы

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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/

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

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

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