kubectl apply vs create. Which command to use to create resources in a clustered Kubernetes environment?

kubectl apply and kubectl create are two different approaches to creating resources in a clustered Kubernetes environment.

They both create resources either from a file or from STDIN.

kubectl apply and create: two approaches to creating resources

Now let’s go over the details and understand how kubectl apply and create differ from each other when implemented.

kubectl create: imperative control

kubectl create is what we call imperative control. With this approach, you tell the Kubernetes API what you want to create, replace, or delete.

In simple terms, create creates a completely new object (previously non-existent or deleted).

kubectl apply: declarative control

kubectl apply is part of a declarative management approach in which changes that you may have applied to a live object (that is, through scale) will be “maintained” even if you apply other changes to the object.

In simpler terms, apply makes additional changes to an existing object, defining what we need.

Note: Both kubectl create and apply approaches accept both JSON and YAML file formats.

Understanding the difference between kubectl create and apply by example

We will use the below YAML file to create a Kubernetes pod.

[email protected]:~/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

Let’s create a Pod imperatively, that is, using the kubectl create command:

[email protected]:~/pod-create# kubectl create -f mypod.yml
pod/create-vs-apply-demo created

List the status of the module along with the labels:

[email protected]:~/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

Now edit the YAML file and add an extra label to it (demo: applyVScreate).

[email protected]:~/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

Now let’s take the imperative approach again to apply the changes.

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

Throws an error and reports that the resource already exists.

Now let’s do the same operation using a declarative approach, i.e. kubectl apply command.

[email protected]:~/pod-create# kubectl apply -f mypod.yml
pod/create-vs-apply-demo configured

So, this time the resource is configured. Check your changes.

[email protected]:~/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

You can see that a new shortcut has been applied to the module.

We believe that you should now be clear about the two approaches.

Kubectl apply vs create? Which one to use?

How you want to use these concepts or methodology depends on the use case. It’s not about what’s good and what’s bad.

If you want to version control a k8s object, it is better to use the declarative way (kubectl apply), which helps you determine the precision of the data in k8s objects.

And if you just want to create some kind of resource for troubleshooting, learning or experimenting goal interactive go with an imperative approach (kubectl create).

Sidebar