kubectl apply vs create. Какую команду использовать для создания ресурсов в кластерной среде Kubernetes?

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

Оба они создают ресурсы либо из файла, либо из STDIN.

kubectl apply и create: два подхода к созданию ресурсов

Теперь давайте рассмотрим детали и поймем, как kubectl apply и create отличаются друг от друга при реализации.

kubectl create: императивное управление

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

Проще говоря, create создает полностью новый объект (ранее не существовавший или удаленный).

kubectl apply: декларативное управление

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

Проще говоря, apply вносит дополнительные изменения в существующий объект, определяя, что нам нужно.

Понимание разницы между kubectl create и apply на примере

Мы будем использовать приведенный ниже файл YAML для создания модуля Kubernetes.

root@andreyex:~/pod-create# cat mypod.yml
apiVersion: v1
kind: Pod
metadata:
   name: create-vs-apply-demo
   labels:
      app: front-end
      rel: dev
spec:
  containers:
  - name: httpd
    image: docker.io/httpd
    imagePullPolicy: IfNotPresent
    ports:
      - containerPort: 80

Создадим Pod императивным способом, т. е. командой kubectl create:

root@andreyex:~/pod-create# kubectl create -f mypod.yml
pod/create-vs-apply-demo created

Перечислим статус модуля вместе с ярлыками:

root@andreyex:~/pod-create# kubectl get pods --show-labels
NAME                   READY   STATUS    RESTARTS   AGE   LABELS
create-vs-apply-demo   1/1     Running   0          8s    app=front-end,rel=dev

Теперь отредактируйте файл YAML и добавлю к нему дополнительную метку (демонстрация: applyVScreate).

root@andreyex:~/pod-create# cat mypod.yml
apiVersion: v1
kind: Pod
metadata:
   name: create-vs-apply-demo
   labels:
      app: front-end
      rel: dev
      demo: applyVscreate
spec:
  containers:
  - name: httpd
    image: docker.io/httpd
    imagePullPolicy: IfNotPresent
    ports:
      - containerPort: 80

Теперь давайте снова воспользуемся императивным подходом для применения изменений.

root@andreyex:~/pod-create# kubectl create -f mypod.yml
Error from server (AlreadyExists): error when creating "mypod.yml": pods "create-vs-apply-demo" already exists

Выдает ошибку и сообщает, что ресурс уже существует.

Теперь проделаем ту же операцию, используя декларативный подход, т.е. команду kubectl apply.

root@andreyex:~/pod-create# kubectl apply -f mypod.yml
pod/create-vs-apply-demo configured

Итак, на этот раз ресурс настроен. Проверьте сделанные изменения.

root@andreyex:~/pod-create# kubectl get pods --show-labels
NAME                   READY   STATUS    RESTARTS   AGE     LABELS
create-vs-apply-demo   1/1     Running   0          3m19s   app=front-end,demo=applyVscreate,rel=dev

Вы можете видеть, что к модулю был применен новый ярлык.

Мы считаем, что теперь вы должны иметь четкое представление о двух подходах.

Kubectl apply или create? Какой использовать?

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

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

И если вы хотите просто создать какой — либо ресурс для поиска неисправностей, обучения или экспериментирование цели интерактивной идти с императивным подходом (kubectl create).

(3 оценок, среднее: 5,00 из 5)

Загрузка...