What is the difference between kubectl apply and kubectl create?
Understand kubectl apply vs create: imperative one-shot creation versus declarative, idempotent create-or-update ideal for GitOps and CI/CD pipelines.
Expected Interview Answer
kubectl create is imperative and creates a resource from scratch, failing if it already exists, while kubectl apply is declarative and creates or updates a resource to match a manifest, making it safe to run repeatedly.
kubectl create tells Kubernetes exactly what to do once, and re-running it on an existing object returns an 'already exists' error. kubectl apply instead records your manifest as the desired state and computes the difference, using a stored last-applied-configuration annotation (or server-side apply) to merge changes intelligently. This makes apply idempotent and ideal for GitOps and CI pipelines, whereas create is handy for quick one-off resources or generating manifests with --dry-run.
- apply is idempotent and safe to re-run in automation
- apply performs create-or-update in a single command
- apply tracks desired state via last-applied-configuration
- create gives explicit one-shot control and clear errors
- create pairs well with --dry-run to scaffold manifests
AI Mentor Explanation
kubectl create is like declaring a brand-new batting order before play begins; try to declare it twice and the scorer rejects the duplicate. kubectl apply is the captain continuously updating the field placement sheet during the match, so each new version simply amends the positions to match intent without starting the innings over.
Step-by-Step Explanation
Step 1
Choose the intent
Decide whether you want a one-time create (imperative) or ongoing desired-state management (declarative).
Step 2
Run create for new objects
kubectl create -f manifest.yaml builds the resource once and errors if it already exists.
Step 3
Run apply for create-or-update
kubectl apply -f manifest.yaml creates the object if absent or updates it to match the manifest if present.
Step 4
apply records last-applied
apply stores a last-applied-configuration annotation so future diffs know which fields you manage.
Step 5
Re-run safely in CI
Because apply is idempotent, pipelines can run it repeatedly, always converging the cluster to the manifest.
What Interviewer Expects
- create is imperative, apply is declarative
- apply is idempotent; create errors if the object exists
- Understanding of the last-applied-configuration annotation
- Awareness that apply suits GitOps and automation
- Knowing create is fine for quick or one-off resources
Common Mistakes
- Saying apply always deletes and recreates the resource
- Believing create can update an existing object
- Not knowing apply tracks state via an annotation
- Using create in CI pipelines and hitting already-exists errors
- Confusing kubectl apply with kubectl replace
Best Answer (HR Friendly)
“kubectl create makes something brand new and complains if it is already there, while kubectl apply keeps things matching a description you provide, creating or updating as needed. That makes apply safe to run over and over in automated pipelines.”
Code Example
# Imperative: create the deployment once
kubectl create -f deployment.yaml
# Running it again fails:
kubectl create -f deployment.yaml
# Error from server (AlreadyExists): deployments.apps "web" already exists
# Declarative: create or update to match the manifest
kubectl apply -f deployment.yaml
# Running it again is safe and idempotent:
kubectl apply -f deployment.yaml
# deployment.apps/web unchanged
# apply records what you manage:
kubectl get deployment web -o jsonpath='{.metadata.annotations.kubectl\.kubernetes\.io/last-applied-configuration}'Follow-up Questions
- What is the last-applied-configuration annotation used for?
- How does kubectl apply differ from kubectl replace?
- What is server-side apply and when would you use it?
- Why is idempotency important in CI/CD pipelines?
- When would you still prefer kubectl create over apply?
MCQ Practice
1. What happens when you run kubectl create on a resource that already exists?
create is imperative and one-shot; running it against an existing object fails with an AlreadyExists error.
2. Which command is idempotent and safe to run repeatedly in automation?
kubectl apply reconciles the object to the manifest whether it exists or not, so re-running converges without errors.
3. How does kubectl apply know which fields you manage?
apply stores your manifest in a last-applied-configuration annotation (or uses server-side apply) to compute diffs.
Flash Cards
kubectl create is... — Imperative: creates a resource once and errors if it already exists.
kubectl apply is... — Declarative: creates or updates a resource to match a manifest, idempotently.
Why is apply good for CI? — It is idempotent, so repeated runs always converge the cluster to the manifest without errors.
How does apply track changes? — It uses the last-applied-configuration annotation (or server-side apply) to compute field-level diffs.