Kubectl apply vs Kubectl create

Kubectl is the one of the key tools which help you to perform most of the kubernetes operations like deploy apps, inspect, manage, and troubleshoot. With that when we use two of its operations — apply and create — often have confused us. What is that? And when we need to use it? In this post, lets discuss about that in detail.

Before starting, the key difference between kubectl apply and create is that apply creates Kubernetes objects through a declarative syntax, while the create command is imperative. The command set kubectl apply is used at a terminal’s command-line window to create or modify Kubernetes resources defined in a manifest file. This is called a declarative usage. The state of the resource is declared in the manifest file, then kubectl apply is used to implement that state. Check the infographic from the DigitalOcean for more details.

Kubectl create is the command you use to create a Kubernetes resource directly at the command line. You can also use kubectl create against a manifest file to create a new instance of the resource. However, if the resource already exists, you will get an error.

kubectl apply

Let’s explore the details of both kubectl usages. First, let’s look at kubectl apply. Listing 1 below is a manifest file that describes a Kubernetes deployment that has two replicas of our internal tool foxy

apiVersion: apps/v1
kind: Deployment
metadata:
  name: testdeploy
  labels:
    app: foxapp2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: foxapp2
  template:
    metadata:
      labels:
        app: foxapp2
    spec:
      containers:
      - name: foxapp2
        image: foxytool:latest
        ports:
        - containerPort: 80

The name of the deployment manifest file as testdeploy.yaml. If you run the command below, it will create a deployment according to the contents of this manifest file.

# kubectl apply -f testdeploy.yaml
deployment/testdeploy created

When you run the command kubectl get deployment, you’ll get the following output:

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
testdeploy      3/3     3            3          2m50s

Here, we’ve created the deployment named testdeploy, and it is running its two pods.

kubectl create

Now, let’s use kubectl create to try to create a deployment imperatively, like below;

# kubectl create deployment testdeploy --image=foxytool

When you execute the imperative command, you’ll get the following result:

Error from server (AlreadyExists): deployments.apps " testdeploy" already exists

This is expected right, as we seen before if the resource exists already it throws the error.

However, let’s try to execute kubectl create for a resource that doesn’t exist. In this case, we’ll create a Kubernetes deployment named testdeploy2. We’ll create it using the following command:

# kubectl create deployment testdeploy2 --image=foxytool
deployment.apps/testdeploy2 created

Change the deployment

Let’s adjust the first deployment we created: testdeploy. We can do this by updating the manifest file, testdeploy.yaml, as shown below. The number of replicas has been increased from two to five, as shown below in red.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: testdeploy
  labels:
    app: foxapp2
spec:
  replicas: 5
  selector:
    matchLabels:
      app: foxapp2
  template:
    metadata:
      labels:
        app: foxapp2
    spec:
      containers:
      - name: foxapp2
        image: foxytool:latest
        ports:
        - containerPort: 80

To update the deployment from three replicas to five, we can execute following kubectl apply command;

# kubectl apply -f testdeploy.yaml
deployment.apps/testdeploy configured

The output reports that the deployment has been configured. This means a change has been applied to an existing deployment. Let’s run the command set kubectl get deployment to confirm the deployment is indeed running four pods. You’ll get an output like the following:

NAME           READY   UP-TO-DATE   AVAILABLE   AGE
testdeploy      5/5     5            5           2m

CI/CD Issues

The differences between these commands can impact your CI/CD pipeline. As we seen, 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 breaks your pipeline. 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.

Which Should You Use?

Choosing to use either create or 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 kubectl create.