kubernetes - kubectl run vs create and apply

Я только начинаю с kubernetes и настраиваю кластер на AWS, используя kops. Во многих примерах, которые я прочитал (и попробую), будут такие команды:

kubectl run my-app --image=mycompany/myapp:latest --replicas=1 --port=8080

kubectl expose deployment my=app --port=80 --type=LoadBalancer

Похоже, что это делает некоторые вещи за кулисами, и я могу просматривать файлы манифеста, созданные с помощью kubectl edit deployment, и т.д. Однако я вижу много примеров, когда люди создают файлы манифеста вручную и используют такие команды, как kubectl create -f или kubectl apply -f

Правильно ли я предположить, что оба подхода выполняют одни и те же цели, но что, создавая файлы манифеста самостоятельно, вы получаете более тонкое управление?

Должен ли я сам создавать спецификации Service, ReplicationController и Pod?

Наконец, если вы создаете файлы манифеста самостоятельно, как люди обычно структурируют свои проекты так, чтобы хранить эти файлы? Они просто находятся в каталоге вместе с проектом, который они развертывают?

ОТВЕТЫ

Ответ 1

Основной вопрос заключается в том, как применять все объекты K8s в кластере k8s. Существует несколько способов сделать эту работу.

  • Использование генераторов (Run, Expose)
  • Использование императивного способа (Create)
  • Использование декларативного пути (Apply)

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

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

Развертывание, ReplicaSet и Pods - это разные уровни, которые решают разные проблемы. Все эти концепции обеспечивают гибкость для k8s.

  • Поддоны: он гарантирует, что связанные контейнеры вместе и обеспечивают эффективность.
  • ReplicaSet: он гарантирует, что кластер k8s имеет желательные реплики стручков
  • Развертывание: оно гарантирует, что вы можете иметь другую версию Pods и предоставить возможность отката к предыдущей версии

Наконец, это зависит от варианта использования, как вы хотите использовать эти концепции или методологию. Это не о том, что хорошо, а что плохо.