kubectl apply vs kubectl create?

Question

What I understood by the documentation is that:

• kubectl create
  

  Creates a new k8s resource in the cluster

• kubectl replace
  

  Updates a resource in the live cluster

• kubectl apply
  

  If I want to do create + replace (Reference)

My questions are

1. Why are there three operations for doing the same task in a cluster?
2. What are the use cases for these operations?
3. How do they differ from each other under the hood?

Answer 1

Those are two different approaches:

Imperative Management

kubectl create is what we call Imperative Management. On this approach you tell the Kubernetes API what you want to create, replace or delete, not how you want your K8s cluster world to look like.

Declarative Management

kubectl apply is part of the Declarative Management approach, where changes that you may have applied to a live object (i.e. through scale) are "maintained" even if you apply other changes to the object.

You can read more about imperative and declarative management in the Kubernetes Object Management documentation.

In laymans They do different things. If the resource exists, kubectl create will error out and kubectl apply will not error out.

Answer 2

When running in a CI script, you will have trouble with imperative commands as create raises an error if the resource already exists.

What you can do is applying (declarative pattern) the output of your imperative command, by using --dry-run=true and -o yaml options:

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

The command above will not raise an error if the resource already exists (and will update the resource if needed).

This is very useful in some cases where you cannot use the declarative pattern (for instance when creating a docker-registry secret).

Answer 3

One of the finest ways to understand the difference between imperative and declarative patterns for beginner.

---

---

Ref : https://www.digitalocean.com/community/tutorials/imperative-vs-declarative-kubernetes-management-a-digitalocean-comic

---

EDIT

There is error is the example mentioned in image. Please refer comments for better understanding.

You can also refer below example.

Imperative :

• take a pan.
• turn on stove.
• add water, sugar, coffee power, milk in pan
• wait till the preparation of coffee
• serve coffee in cup.

Declarative :

• Tell the waiter you need a cup of coffee. He servers you coffee.

---

From K8s perspective:

Imperative : You have to manage different resources like pods, service, replica sets, etc by your own.

Declarative : K8 will take care of all the resources, all you need have to specify what is your actual requirement.

Answer 4

Just to give a more straight forward answer, from my understanding:

apply - makes incremental changes to an existing object
create - creates a whole new object (previously non-existing / deleted)


Taking this from a DigitalOcean article which was linked by Kubernetes website:

We use apply instead of create here so that in the future we can incrementally apply changes to the Ingress Controller objects instead of completely overwriting them.

Answer 5

┌─────────┬───────────────────────┬────────────────────────┐
│ command │ object does not exist │ object already exists  │
├─────────┼───────────────────────┼────────────────────────┤
│ create  │ create new object     │          ERROR         │ 
│         │                       │                        │
│ apply   │ create new object     │ configure object       │
│         │ (needs complete spec) │ (accepts partial spec) │
│         │                       │                        │
│ replace │         ERROR         │ delete object          │
│         │                       │ create new object      │
└─────────┴───────────────────────┴────────────────────────┘

Answer 6

These are imperative commands :

kubectl run = kubectl create deployment

Advantages:

• Simple, easy to learn and easy to remember.
• Require only a single step to make changes to the cluster.

Disadvantages:

• Do not integrate with change review processes.
• Do not provide an audit trail associated with changes.
• Do not provide a source of records except for what is live.
• Do not provide a template for creating new objects.

These are imperative object config:

kubectl create -f your-object-config.yaml

kubectl delete -f your-object-config.yaml

kubectl replace -f your-object-config.yaml

Advantages compared to imperative commands:

• Can be stored in a source control system such as Git.
• Can integrate with processes such as reviewing changes before push and audit trails.
• Provides a template for creating new objects.

Disadvantages compared to imperative commands:

• Requires basic understanding of the object schema.
• Requires the additional step of writing a YAML file.

Advantages compared to declarative object config:

• Simpler and easier to understand.
• More mature after Kubernetes version 1.5.

Disadvantages compared to declarative object configuration:

• Works best on files, not directories.
• Updates to live objects must be reflected in configuration files, or they will be lost during the next replacement.

These are declarative object config

kubectl diff -f configs/

kubectl apply -f configs/

Advantages compared to imperative object config:

• Changes made directly to live objects are retained, even if they are not merged back into the configuration files.
• Better support for operating on directories and automatically detecting operation types (create, patch, delete) per-object.

Disadvantages compared to imperative object configuration:

• Harder to debug and understand results when they are unexpected.
• Partial updates using diffs create complex merge and patch operations.

Answer 7

This can be concluded with simple examples:-

Lets create a simple yaml for deploying a pod having image of nginx in it.

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: front-end
spec:
  containers:
    - name: nginx-container
      image: nginx

now we create a pod using kubectl command -

kubectl create -f pod.yaml

Now a pod named nginx is created , you can get info about pods running by -

kubectl get pods -o wide

and detailed view about the pod by

kubectl describe pod nginx

Now if i want to make some changes in my pod.yaml file like this -

pod.yaml

apiVersion: v1 
kind: Pod 
metadata:
  name: nginx
  labels:
    app: nginx
    tier: frontend
    title: frontend
spec:
  containers:
    - name: nginx
      image: nginx

now try the command

kubectl create -f pod.yaml

to apply the changes in pod.yaml.

it will have a ouput -

Error from server (AlreadyExists): error when creating "pod.yaml": pods "nginx" already exists

but with the command -

kubectl apply -f pod.yaml

output is -

pod/nginx configured

As in first comment it is very detailed explained that create like imperative commands are focused on their assigned tasks, you can not assign them further tasks to tweak the world of clusters but apply like declarative commands are designed to make it work to tweak the world of clusters.

Answer 8

The explanation below from the official documentation helped me understand kubectl apply.

This command will compare the version of the configuration that you’re pushing with the previous version and apply the changes you’ve made, without overwriting any automated changes to properties you haven’t specified.

kubectl create on the other hand will create (should be non-existing) resources.

Answer 9

kubectl create can work with one object configuration file at a time. This is also known as imperative management

kubectl create -f filename|url

kubectl apply works with directories and its sub directories containing object configuration yaml files. This is also known as declarative management. Multiple object configuration files from directories can be picked up. kubectl apply -f directory/

Details :
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/

Answer 10

This question is very deep and a good one，Next is my thinking on this problem：

K8s has three resource management methods

• Command Based Object Management: directly use commands to operate kubernetes resources. eg:

  kubectl run nginx-pod --image=nginx:1.17.1 --port=80

• Command Type Object Configuration: operate Kubernetes resources through command configuration and configuration files. eg:

  kubectl create/patch -f nginx-pod.yaml

• Declarative Object Configuration: operate kubernetes resources through the apply command and configuration file. eg:

  kubectl apply -f nginx-pod.yaml

Type	Operate Object	Suitable for environment	Advantage	disadvantage
Command Based Object Management	Object	test env	Simple	Only active objects can be operated, but not audited or tracked
Command Type Object Configuration	File	develop evn	Can be audited and tracked	When the project is large, there are many configuration files and the operation is troublesome
Declarative Object Configuration	Directory	develop evn	Support directory operations	It is difficult to debug under unexpected circumstances

Answer 11

We love Kubernetes is because once we give them what we want it goes on to figure out how to achieve it without our any involvement.

"create" is like playing GOD by taking things into our own hands. It is good for local debugging when you only want to work with the POD and not care abt Deployment/Replication Controller.

"apply" is playing by the rules. "apply" is like a master tool that helps you create and modify and requires nothing from you to manage the pods.