🐶
Kubernetes

kubectl apply vs create: Understanding the Differences

By Jan on 01/14/2025

Learn the key differences between kubectl apply and kubectl create for managing Kubernetes resources effectively.

kubectl apply vs create: Understanding the Differences

Table of Contents

Introduction

kubectl create and kubectl apply both create resources in Kubernetes, but they handle pre-existing resources differently. kubectl create creates a resource from a file or stdin. If a resource with the same name already exists, kubectl create throws an error. kubectl apply also creates or updates resources from a file or stdin. However, if the resource already exists, kubectl apply updates the existing resource with the configuration specified in the file. If a field is not defined in the file, kubectl apply will keep the existing value. In short, use kubectl create for initial resource creation. Use kubectl apply for subsequent updates, as it handles both creation and modification.

Step-by-Step Guide

kubectl create and kubectl apply both create resources in Kubernetes, but they handle pre-existing resources differently.

kubectl create creates a resource from a file or stdin.

kubectl create -f deployment.yaml

If a resource with the same name already exists, kubectl create throws an error.

kubectl apply also creates or updates resources from a file or stdin.

kubectl apply -f deployment.yaml

However, if the resource already exists, kubectl apply updates the existing resource with the configuration specified in the file. If a field is not defined in the file, kubectl apply will keep the existing value.

In short, use kubectl create for initial resource creation. Use kubectl apply for subsequent updates, as it handles both creation and modification.

Code Example

The code demonstrates the difference between kubectl create and kubectl apply commands. kubectl create creates a resource and throws an error if a resource with the same name already exists. kubectl apply on the other hand, creates a resource if it doesn't exist and updates it if it does, merging changes and preserving existing values.

deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

1. Create the deployment using kubectl create:

kubectl create -f deployment.yaml

This will create a deployment named "nginx-deployment" with 3 replicas.

2. Try creating the same deployment again:

kubectl create -f deployment.yaml

This will throw an error because a deployment with the same name already exists.

3. Update the deployment using kubectl apply to scale to 5 replicas:

updated-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 5 
kubectl apply -f updated-deployment.yaml

This will update the existing "nginx-deployment" to have 5 replicas. Notice that we didn't specify the selector or template fields in the updated file, but kubectl apply kept the existing values for those fields.

4. Try creating the deployment using kubectl apply:

kubectl apply -f deployment.yaml

This will not throw an error. Instead, it will report that the deployment was unchanged because the configuration in the file matches the existing deployment.

This example demonstrates how kubectl create is suitable for initial resource creation, while kubectl apply is more versatile for both creation and subsequent updates, as it merges changes and preserves existing values.

Additional Notes

  • Idempotency: kubectl apply is idempotent, meaning you can run the same command multiple times without changing the final state of the resource. kubectl create, however, will throw an error if you try to create an already existing resource. This makes kubectl apply more suitable for automation and CI/CD pipelines.
  • Declarative vs. Imperative: kubectl create is more of an imperative command - you tell Kubernetes to create a specific resource. kubectl apply follows a declarative approach - you describe the desired state of the resource, and Kubernetes figures out how to achieve it.
  • Tracking Changes: kubectl apply uses a server-side mechanism to track changes made to resources. This allows for better change tracking and rollback capabilities compared to kubectl create.
  • Use Cases:
    • kubectl create: Best for initial resource creation when you are sure the resource doesn't already exist.
    • kubectl apply: Ideal for managing resource configuration throughout their lifecycle, especially in automated environments. Use it for updates, modifications, and even initial creation if you are unsure about the resource's existence.
  • Alternatives: While less common, commands like kubectl replace and kubectl patch offer more granular control over resource updates. However, kubectl apply is generally preferred for its ease of use and robust features.

In summary:

  • For simple, one-time resource creation, kubectl create might suffice.
  • For managing resources throughout their lifecycle, especially in automated workflows, kubectl apply is the recommended approach due to its idempotency, declarative nature, and change tracking capabilities.

Summary

Feature kubectl create kubectl apply
Action Creates resources Creates or updates resources
Handling Existing Resources Throws an error if a resource with the same name exists Updates the existing resource with the provided configuration
Updating Resources Not applicable Updates existing fields and preserves values for unspecified fields
Ideal Use Case Initial resource creation Subsequent updates and modifications

In essence:

  • Use kubectl create for the initial setup of your resources.
  • Use kubectl apply for ongoing management and updates, leveraging its ability to handle both creation and modification seamlessly.

Conclusion

Choosing between kubectl create and kubectl apply depends on your use case. While kubectl create is suitable for initial resource creation, kubectl apply offers a more robust and flexible approach for managing Kubernetes resources throughout their lifecycle. Its ability to handle both creation and updates, along with its idempotent nature and change tracking mechanisms, makes it the preferred choice for modern, automated Kubernetes workflows.

References

Were You Able to Follow the Instructions?

😍Love it!
😊Yes
😐Meh-gical
😞No
🤮Clickbait