Kubernetes Manifest Apply Flow

Kubernetes Manifest Apply Flow is the concrete sequence of steps that occurs from the moment a client runs an apply-style command against a manifest to the moment the resulting change is fully reflected in the cluster, tracing the path from local file, through client-side processing, through the API server's admission pipeline, to the eventual reconciliation carried out by whatever controller is responsible for the affected object. Understanding this flow end to end is what lets an operator predict exactly what a given apply invocation will do before running it, and diagnose precisely which stage failed when it does not behave as expected.

Client-Side Preparation

Reading and Parsing the Manifest

The apply flow begins with the client reading the manifest file (or files, or directory) from disk, parsing its YAML or JSON content into an internal representation, and splitting multi-document files at their --- separators into individual objects to be processed independently.

Resolving Identity and Target Endpoint

For each parsed object, the client resolves its GroupVersionKind through discovery information to determine the correct API endpoint, and combines this with the object's name and namespace (from the manifest or the client's active context) to construct the exact URL the request will be sent to.

Determining Create Versus Update

Checking for an Existing Object

The client (or, in Server-Side Apply's case, the API server itself) checks whether an object matching the manifest's resolved identity already exists; this determination is what decides whether the flow proceeds as a creation or as a patch against existing content, and it happens fresh on every apply invocation rather than being cached from a prior run.

Computing the Patch

For an existing object, client-side apply computes a three-way merge using a locally stored last-applied-configuration annotation, the manifest's new content, and the object's current live state, while Server-Side Apply instead submits the manifest directly to the server, which performs the merge itself using field-ownership tracking rather than a client-computed diff.

Submission Through the Admission Pipeline

The Request Enters the Standard Pipeline

Once constructed, the create or patch request proceeds through the exact same authentication, authorization, admission (mutating and validating), and schema validation pipeline described under the API request model, entirely independent of the fact that the request originated from an apply-style command rather than a raw API call.

Conflict Handling in Server-Side Apply

If Server-Side Apply is in use and the request would overwrite a field currently owned by a different field manager, the API server returns a conflict at this stage rather than proceeding, requiring the client to resolve the conflict (or force the change) before the flow can continue.

Persistence and Propagation

Writing to etcd

A request that clears admission and validation is persisted to etcd, receiving an updated resourceVersion, and the resulting object state is what the apply command's response reflects back to the client — this is the point at which the desired state officially becomes part of the cluster's recorded configuration.

Watch Propagation to Controllers

Persisting the change generates a watch event delivered to every component with an active watch on that resource type, including whichever controller is responsible for reconciling the affected Kind; it is only at this point, after the manifest's content has already been durably stored, that any actual reconciliation work — creating Pods, updating a load balancer, provisioning storage — begins.

Completion of the Flow

The apply Command Returns Before Reconciliation Finishes

An apply command typically returns success once the API server has accepted and persisted the object, not once the desired state has been fully realized in the cluster; a Deployment's apply flow, for instance, completes at the point the Deployment object is updated, well before the corresponding Pods have necessarily finished rolling out, which is why operators commonly follow an apply with a separate wait or watch step when they need confirmation of full convergence rather than just acceptance of the declared change.