kubectl is the Kubernetes command line tool (CLI) that allows you to run commands against Kubernetes clusters. kubectl can be used to deploy applications, inspect and manage cluster resources, and view logs.
In a platform as large as Kubernetes, you will find commands that are similar but serve slightly different purposes. kubectl
create commands are two different approaches for creating Kubernetes resources. In this article, we will explore what these commands do, what the key differences between them are, and when to use each.
Imperative and declarative
Before we discuss
create, it’s important to understand the difference between the imperative and declarative approaches.
In the imperative approach, we need to specify what and how to perform a task.
If the task is preparing a sandwich, for example, you would explain the items needed as well as the step-by-step instructions.
In the declarative approach, we need to specify what to do but not how to do it.
In this case, you would only explain the items needed for the sandwich, without the instructions.
How do the imperative and declarative approaches fit into a Kubernetes context?
Kubectl apply and
Kubectl create are two different approaches in creating resources or updating resource configurations in the Kubernetes cluster environment.
Both these commands accept configuration changes either from the file or stdin, and both accept JSON and YAML file formats.
In simpler terms,
create produces a new object (previously nonexistent or deleted). If a resource already exists, it will raise an error.
Kubectl apply is part of the declarative management approach in which 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.
apply makes incremental changes to an existing object by defining what we need. If a resource already exists, it will not raise an error.
Apply vs create: attributes
|Kubectl apply||Kubectl create|
|1.||It directly updates in the current live source with only the attributes that are given in the file.||It creates resources from the file provided. It shows an error if the resource has already been created.|
|2.||The file used in apply can be an incomplete spec.||The file used in create should be complete.|
|3.||apply works only on some properties of the resources.||create works on every property of the resources..|
|4.||You can apply a file that changes only an annotation without specifying any other properties of the resource.||If you use the same file with a replace command, the command will fail due to the missing information.|
How they work
For this example, let’s use the YAML file below to create a Kubernetes pod.
Now create the pod using the imperative approach with
Let’s verify the pod status along with labels:
→ kubectl get pods --show-labels
Now we’ll edit the YAML file and add an extra label to it (environment: local):
Once again, use the imperative approach to apply the changes:
Note the error message saying the resource
kubectl-create-vs-apply-demo already exists.
Now we’ll do the same operation using the declarative approach with
This time, the resource was configured. Let’s verify the changes we made.
→ kubectl get pods --show-labels
You can see that the new label
environment: local has been applied to the pod.
The differences between these commands can impact your CI/CD pipeline. As we saw above,
Kubectl create can only be used if there are no existing resources and you want to create new resources.
If the resource is already created and running,
create will raise an error, thereby halting your CI/CD. To avoid that, use the
kubectl get command to check if there is already an existing resource; then use
Kubectl apply to update to the latest configuration.
There will be many scenarios where you will want to execute shell scripts after the launch of the resource. You can provide shell scripts as part of your configuration file, which can be triggered just after the resource is created. These commands, once configured, cannot be updated when the resource is already running.
Be aware that these commands can be executed only via
Kubectl create. kubectl won’t allow you to update these commands via
Kubectl apply if the container is already running. We’ll use a simple example to demonstrate.
We will create a pod with a simple
Let’s create the pod using the above configuration.
Now update the
echo command and apply the changes to the pod.
Apply the changes to the pod using the above configuration.
Kubectl apply failed with the stated reason that pod updates cannot change fields other than container specs.
Which should you use?
Choosing to use either
apply depends on your particular use case.
If you want to add a version control to your Kubernetes object, then it’s better to use
Kubectl apply, which helps determine the accuracy of data in Kubernetes objects.
If you want to create a resource for troubleshooting, learning, or interactive experimentation, go with
Now you know what the difference is between imperative and declarative approaches and how they fit into the context of Kubernetes. You should also have a better sense of when to use kubectl
create and in what context. This will help you make more efficient use of your time and resources in Kubernetes and keep your CI/CD workflow at peak performance.
If you're looking for an easy way to monitor your Kubernetes resources and fix issues quickly as they arise, try using Airplane. With Airplane, you can build powerful internal tools that fit your engineering workflows using SQL queries, Python scripts, REST API calls, and more. You can use Airplane Views, a React-based platform for building custom UIs, to quickly build a monitoring dashboard.