Що я зрозумів під документацією, це те, що:

• kubectl create = Створює новий ресурс k8s у кластері
• kubectl substitu = Оновлення ресурсу в реальному кластері
• kubectl apply = Якщо я хочу створити + замінити ( довідник )

Мої запитання є

1. Чому існують три операції для виконання одного і того ж завдання в кластері?
2. Які випадки використання для цих операцій?
3. Чим вони відрізняються один від одного під капотом?

Це два різні підходи:

Управління імперативом

kubectl createце те, що ми називаємо імперативним управлінням . При такому підході ви кажете Kubernetes API, що ви хочете створити, замінити чи видалити, а не як ви хочете виглядати у вашому світі кластерів K8s.

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

kubectl applyє частиною підходу до Декларативного управління , де зміни, які ви, можливо, застосували до живого об'єкта (тобто через scale), " підтримуються ", навіть якщо ви applyінші змінили об'єкт.

Детальніше про імперативне та декларативне управління ви можете прочитати в документації Kubernetes Object Management .

Під час запуску в сценарії CI у вас виникнуть проблеми з імперативними командами, оскільки створення створює помилку, якщо ресурс вже існує.

Що ви можете зробити, це застосувати (декларативний зразок) вихід своєї імперативної команди, використовуючи --dry-run=trueта -o yamlпараметри:

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

Команда, наведена вище, не призведе до помилки, якщо ресурс уже існує (і оновить ресурс, якщо це потрібно).

Це дуже корисно в деяких випадках, коли ви не можете використовувати декларативний шаблон (наприклад, при створенні секрету док-реєстру).

Просто, щоб дати більш пряму відповідь, з мого розуміння:

apply- робить поступові зміни в існуючий об'єкт
create- створює абсолютно новий об'єкт (раніше неіснуючі / видалено)


Беручи це з DigitalOcean статті , яка була пов'язана з допомогою сайту Kubernetes:

Ми використовуємо Apply, а не створюємо тут, щоб у майбутньому ми могли поступово застосовувати зміни до об'єктів Contress 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/

Переваги порівняно з імперативним конфігурацією об'єкта:

• Зміни, внесені безпосередньо до живих об'єктів, зберігаються, навіть якщо вони не об'єднані назад у файли конфігурації.
• Краща підтримка роботи в каталогах та автоматичного виявлення типів операцій (створення, виправлення, видалення) на кожен об'єкт.

Недоліки порівняно з імперативною конфігурацією об'єкта:

• Складніше налагоджувати та розуміти результати, коли вони несподівані.
• Часткові оновлення за допомогою diff створюють складні операції злиття та виправлення.

Пояснення нижче з офіційної документації допомогло мені зрозуміти kubectl apply.

Ця команда порівняє версію конфігурації, яку ви натискаєте, з попередньою версією та застосує внесені вами зміни, не перезаписуючи автоматичні зміни властивостей, які ви не вказали.

kubectl create з іншого боку створить (повинні бути неіснуючі) ресурси.

kubectl create може працювати з одним файлом конфігурації об'єкта одночасно. Це також відоме як імперативне управління

kubectl створити -f ім'я файлу | URL

kubectl застосовує роботи з каталогами та його підкаталогами, що містять файли Yaml з конфігурацією об'єкта. Це також відоме як декларативне управління. Можна вибрати декілька файлів конфігурації об'єктів з каталогів. kubectl застосувати -f каталог /

Детальніше:
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/

Ми любимо Кубернетів через те, що коли ми даємо їм те, що ми хочемо, то ми зрозуміємо, як цього досягти без будь-якої участі.

"творити" - це як грати з БОГом, беручи речі у свої руки. Це добре для локальної налагодження, коли ви хочете працювати лише з ПОД і не турбуватися про контролер розгортання / реплікації.

"застосувати" - це гра за правилами. "застосовувати" - це як основний інструмент, який допомагає вам створювати та змінювати, і не вимагає від вас нічого для управління стручками.