Kubernetes Manifest Create Behavior

Kubernetes Manifest Create Behavior is the specific, narrower behavior exhibited by kubectl create -f and equivalent purely-imperative-creation clients, as distinguished from the broader apply flow: a create operation submits a manifest as a request to bring a brand-new object into existence and fails outright if an object with the same identity already exists, with no merging, patching, or reconciliation against prior state involved at all. Where apply is designed for repeated, idempotent use against a manifest that may already correspond to an existing object, create is a strictly one-shot operation whose success depends entirely on no conflicting object already being present.

The Fundamental Difference From Apply

No Existence Check Before Failing

A create request does not first check whether a matching object exists and branch its behavior accordingly the way apply does; it always attempts an unconditional creation, and the API server itself rejects the request with an "already exists" error if an object with the same GroupVersionKind, namespace, and name is already present, placing the burden of checking prior existence entirely on the client if that check matters to the calling context.

No last-applied-configuration Tracking

Because create never anticipates being reapplied against the same object, it does not populate the last-applied-configuration annotation that client-side apply relies on for subsequent three-way merges; an object created via kubectl create and later modified via kubectl apply will have that annotation established only from the point apply is first used against it, meaning the first such apply effectively treats every existing field as the new baseline.

When Create Is the Appropriate Choice

One-Shot, Non-Idempotent Operations

Create is well suited to situations where reapplication against the same object is neither expected nor desired — generating a uniquely named object via generateName, where each invocation is explicitly meant to produce a new, distinct object rather than update an existing one, is a canonical case where apply's update-if-exists behavior would be actively wrong.

Imperative Scripting and One-Off Commands

Interactive, exploratory, or scripted one-off object creation — such as quickly spinning up a test Pod or ConfigMap during debugging — commonly favors create's simpler, more predictable failure mode (fail loudly if something with that name already exists) over apply's more forgiving merge behavior, since the intent in these cases is genuinely "make this specific new thing," not "ensure this state exists."

Failure Behavior

Immediate, Unambiguous Rejection

Because create has no merge logic to fall back on, a naming collision produces an immediate, unambiguous HTTP conflict response rather than any attempt to reconcile the submitted content with the existing object, which some workflows deliberately rely on as a concurrency-safety mechanism — using create as an atomic "claim this name if unclaimed" operation, since the API server's own uniqueness enforcement makes the check-and-create sequence effectively atomic from the perspective of competing clients.

No Automatic Retry or Merge Fallback

A client receiving an already-exists error from create must explicitly decide what to do next — switch to an update, delete and recreate, or simply treat the collision as an expected outcome and move on — since create itself makes no attempt to fall back into an apply-like merge behavior automatically.

Interaction With generateName

Server-Assigned Uniqueness

When a manifest uses metadata.generateName instead of a fixed metadata.name, create is the natural operation to pair it with, since the whole point of generateName is to let the API server assign a fresh, collision-free suffix on each creation; using apply against a generateName-based manifest is largely meaningless, since apply's identity resolution depends on already knowing a specific name to check for prior existence, which a generateName manifest does not supply until after creation has already happened.