How to Use kubectl apply vs kubectl create

In this tutorial, you'll learn about How to Use kubectl apply vs kubectl create. We cover key concepts, practical examples, and best practices.

The Problem

You are unsure whether to use kubectl apply or kubectl create to deploy resources. Using the wrong command leads to AlreadyExists errors, unexpected updates, or resources not being managed declaratively.

Quick Fix

Step 1: Use kubectl apply for declarative management

kubectl apply creates or updates resources from a YAML file. It tracks the last applied state in annotations:

kubectl apply -f deployment.yaml

deployment.apps/nginx created

Run the same command again to update:

kubectl apply -f deployment.yaml

deployment.apps/nginx configured

Step 2: Use kubectl create for one-off imperative creation

kubectl create fails if the resource already exists:

kubectl create deployment nginx --image=nginx

deployment.apps/nginx created

Running it again:

kubectl create deployment nginx --image=nginx

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

Step 3: Use kubectl create --save-config for later apply

If you use kubectl create but plan to switch to kubectl apply later:

kubectl create -f deployment.yaml --save-config --record

This stores the last-applied annotation so kubectl apply can calculate diffs.

Step 4: Use kubectl replace for destructive updates

kubectl replace deletes and recreates the resource:

kubectl replace -f deployment.yaml

This is useful when apply cannot handle certain immutable field changes.

Step 5: Delete a resource

Both commands use the same delete syntax:

kubectl delete -f deployment.yaml

or

kubectl delete deployment nginx

Alternative Solutions

Use kustomize for declarative management

Kustomize applies all resources in a directory:

kubectl apply -k overlays/production/

Use kubectl create --dry-run for validation

Validate a resource definition without creating it:

kubectl create deployment nginx --image=nginx --dry-run=client -o yaml

Common Mistakes to Avoid

Using create when you mean apply. kubectl create fails if the resource exists. Use apply for declarative management.

Using apply without understanding the last-applied annotation. kubectl apply uses the last-applied state to calculate diffs. If it is missing, behavior may be unexpected.

Creating resources imperatively in production. Imperative commands do not leave a record of what was deployed. Use YAML files version-controlled in Git.

Pro Tips

Use kubectl diff before applying in CI. Run kubectl diff -f manifest.yaml to see what changes will be made before actually applying them.

Use kubectl apply --server-side for large clusters. Server-side apply distributes the processing load and handles conflicts better than client-side apply.

Use kustomize for environment-specific overlays. Manage dev, staging, and production variations from a common base without duplicating manifests.

Use kubectl apply --dry-run=client -o yaml to preview output. When debugging resource definitions, use dry-run combined with output to see what Kubernetes would create without actually applying it.

Prevention

• Use kubectl apply -f for all resources managed by CI/CD or version control.
• Use kubectl create for quick, throwaway resources during development.
• Add --save-config to kubectl create if you might switch to kubectl apply later.