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).