6.11 Kubernetes Manifest Create Behavior

Kubernetes Manifest Create Behavior is the strict, single-shot semantics that apply when a manifest is submitted through a create operation rather than an apply operation, characterized by an unconditional failure if an object matching the manifest's identity already exists, no merge logic of any kind, and no ongoing tracking of the manifest as a reusable, reapplyable source for future updates.

Create as a One-Time Operation

No Existence Check Before Failure

Unlike apply, which checks whether a matching object exists and branches into either creation or a merge-based update, a create operation makes no such check on the client side beyond what the API server itself performs; it simply attempts to create a new object, and the API server rejects the request outright with an "already exists" conflict error if an object with the same identity is already present.

No Tracking Annotation

Because create is not designed to be reapplied, it does not populate a last-applied-configuration annotation or rely on server-side apply's field-ownership tracking in the way apply does, meaning an object created this way has no built-in record of the manifest that originally produced it beyond whatever fields the manifest itself directly set.

When Create Behavior Is Appropriate

Genuinely One-Shot Objects

Create is well suited to objects that are inherently meant to be created once and not revised in place, such as a Job intended to run a single batch task to completion, where reapplying an updated manifest against the same identity is not a meaningful operation in the first place.

Fail-Fast Pipelines

Automation pipelines that want to fail loudly if an expected object already exists, rather than silently merging into it, sometimes deliberately choose create over apply specifically for this fail-fast behavior, treating an unexpected pre-existing object as a signal of a pipeline bug or an unexpected concurrent process rather than something to gracefully reconcile with.

Bootstrapping Scenarios

Initial bootstrap scripts that populate a freshly created cluster with a known-empty starting state sometimes favor create for its simplicity and its strict guarantee that no unintended object is silently overwritten, since there should be nothing pre-existing to conflict with in a truly fresh environment.

Behavioral Contrast With Apply

No Field Removal Semantics

Create has no notion of field removal on reapplication, since there is no reapplication concept at all in its intended use; every field present in the manifest at creation time becomes part of the object exactly once, and any subsequent change to that object requires an entirely separate update or patch operation using different tooling.

No Conflict Detection

Because create either succeeds by producing a genuinely new object or fails outright due to a name collision, it has no equivalent to apply's field-ownership conflict detection; the binary success-or-failure outcome of create is a simpler, but far less flexible, contract than apply's nuanced, ownership-aware merge behavior.

Practical Client Tooling Behavior

kubectl create Command Semantics

The kubectl create -f command implements this strict create-only behavior directly: given a manifest, it issues a create request and reports a clear error if the target object already exists, without attempting any fallback merge or update, in direct contrast to kubectl apply -f against the same manifest and target cluster state.

Generators and Imperative Object Creation

Beyond manifest-based creation, kubectl create also supports imperative generator subcommands, such as kubectl create deployment, which construct a manifest on the fly from command-line flags rather than reading one from a file, but the resulting object still follows the same one-time, no-merge creation semantics once submitted to the API server.

Risks of Relying on Create for Ongoing Management

Loss of Idempotency

Because reapplying the same manifest through create against an already-existing object simply fails, using create as the primary tool for ongoing configuration management, rather than apply, breaks the idempotent reapplication property that declarative, repeatable infrastructure workflows generally depend on, making it a poor fit for continuous deployment pipelines that expect to reapply configuration on every release.