What is Kubectl Kubernetes Io Last Applied Configuration

what is kubectl kubernetes io last applied configuration is the Kubernetes annotation that stores the last manifest you applied with kubectl apply. Kubectl uses it as a saved copy of the previous configuration so it can compare what changed and update the live resource correctly.

What the last-applied configuration actually is

In Kubernetes, the last-applied-configuration is not a separate object or feature you manage directly. It is an annotation stored on a resource under metadata.annotations. When you run kubectl apply, kubectl writes a JSON representation of your manifest into that annotation.

This saved copy helps kubectl understand three things during an update:

• What the resource looked like the last time you applied it
• What the live object looks like right now
• What changes are present in your new manifest

That comparison is what allows kubectl to perform a three-way merge instead of blindly replacing the object.

Where Kubernetes stores it

The annotation lives inside the resource metadata, usually on objects such as Deployments, ConfigMaps, Services, and Secrets. You will typically see it in YAML like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"name":"web-app"},"spec":{...}}

The key name is kubectl.kubernetes.io/last-applied-configuration. The value is usually a JSON string containing the last applied manifest content.

Why kubectl apply uses it

kubectl apply is designed for declarative management. Instead of saying exactly how to patch the live object, you give kubectl the desired end state in YAML or JSON. Kubectl then compares the current version with the stored last applied configuration and the new manifest to decide what should change.

This matters because Kubernetes resources can be changed by multiple sources:

• Your manifest files
• Manual edits with kubectl edit
• Other controllers or operators
• Automated deployment systems

The annotation gives kubectl a baseline for detecting which fields came from your last apply, which fields were changed elsewhere, and which fields should be updated or preserved.

How it works in practice

When you apply a manifest for the first time, kubectl creates the resource and stores the full applied configuration in the annotation. On the next kubectl apply, it compares:

1. The last-applied configuration from the annotation
2. The live resource currently stored in the cluster
3. The new manifest you are applying now

That comparison helps kubectl decide whether a field was added, removed, or changed by you, or whether the cluster changed it independently. This is the reason kubectl apply behaves differently from kubectl create or a simple patch.

Example of the annotation in a manifest

Here is a simplified example of how the annotation may appear on an existing object:

metadata:
  name: example-config
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ConfigMap","metadata":{"name":"example-config"},"data":{"LOG_LEVEL":"info"}}

If you edit the resource manually, this annotation may no longer match the live object exactly. That mismatch is one reason why configuration drift can produce confusing results during later applies.

How to view the last-applied configuration

You can inspect the annotation with kubectl in a few different ways.

View the full resource YAML

kubectl get deployment web-app -o yaml

Look under metadata.annotations for the key kubectl.kubernetes.io/last-applied-configuration.

View only the annotation

kubectl get deployment web-app -o jsonpath='{.metadata.annotations.kubectl\.kubernetes\.io/last-applied-configuration}'

This is useful when you want to check the stored configuration without reading the entire object.

Inspect with describe

kubectl describe deployment web-app

describe can help you see metadata and current state, although the full annotation is easier to inspect with get -o yaml or JSONPath.

How to remove or reset it safely

There are situations where the annotation becomes stale or needs to be recreated. For example, a resource may have been imported from an older workflow, or a manual edit may have made the stored last-applied data unreliable.

To remove the annotation, you can use:

kubectl annotate deployment web-app kubectl.kubernetes.io/last-applied-configuration-

If you remove it, the next kubectl apply may treat the resource as if it does not have a prior apply history. In that case, kubectl may not have enough information for a clean three-way merge.

If you want to rebuild the annotation, the safest path is usually to reapply the source manifest so kubectl can store a fresh copy:

kubectl apply -f deployment.yaml

Be careful with this step if the live resource has changes you want to preserve. Review the differences first.

Last-applied configuration vs server-side apply

Many Kubernetes users confuse the legacy client-side apply annotation with server-side apply. They solve a similar problem, but they are not the same.

If you are using server-side apply, the annotation is usually less important because the API server tracks field ownership directly. If you are using standard client-side kubectl apply, the annotation still matters.

Common problems and fixes

The annotation is missing

If the annotation is missing, kubectl may not be able to compare the new manifest against an older applied version. This can happen when a resource was created with kubectl create, imported from another system, or edited outside the normal apply workflow.

Fix: apply the manifest again with kubectl apply -f so kubectl can store a fresh last-applied configuration.

The annotation is stale

If the stored configuration no longer matches the real object, later applies can produce unexpected diffs or overwrite fields you did not mean to touch.

Fix: compare the current live object with your desired manifest, then reapply the correct source of truth. If needed, remove the annotation first and apply again carefully.

Manual edits cause drift

If someone uses kubectl edit or another tool changes the object, the annotation may still reflect an older manifest. Kubectl will then compare against an outdated baseline.

Fix: standardize the workflow so one manifest source owns the resource, or use server-side apply where appropriate.

You see conflicts during apply

Conflicts usually mean the live object changed in a way that does not line up with the stored configuration. This can happen when different actors manage the same fields.

Fix: review the diff, check who owns the field, and decide whether your manifest should override the live value or leave it alone.

When not to rely on it

The last-applied configuration is useful, but it is not a perfect source of truth in every environment. You should be cautious when:

• Multiple controllers manage the same fields
• People manually edit resources outside Git or manifests
• Objects were created by tools that do not preserve apply history
• You are migrating to server-side apply and field ownership rules are changing

In those cases, the annotation may be incomplete, outdated, or misleading. The live object and your desired manifest should still be reviewed together before making changes.

Which kubectl commands are most relevant

Several kubectl commands affect whether the last-applied configuration exists or remains useful:

• kubectl apply, stores and updates the annotation
• kubectl create, creates objects but does not establish an apply history in the same way
• kubectl edit, can change live state without updating your source manifest
• kubectl annotate, can add or remove the annotation directly
• kubectl get, helps you inspect the current value

If your workflow depends on predictable declarative updates, kubectl apply is the command most closely tied to this annotation.

Practical takeaway

what is kubectl kubernetes io last applied configuration? It is kubectl’s stored copy of the last manifest you applied, saved as an annotation on the resource. Kubectl uses it to compare old, live, and new configuration values so it can update Kubernetes objects with a three-way merge. If the annotation is missing or stale, apply behavior may be less predictable, so it is worth checking whenever deployments, ConfigMaps, or other manifests do not update the way you expect.

Frequently Asked Questions About what is kubectl kubernetes io last applied configuration

What does kubectl last applied configuration mean?

It means the previously applied manifest that kubectl saved on the resource as an annotation. Kubectl uses it as the baseline for future apply operations.

Where is the last-applied configuration stored in Kubernetes?

It is stored in the object metadata under metadata.annotations, using the key kubectl.kubernetes.io/last-applied-configuration.

How do I see the last-applied-configuration annotation?

Use kubectl get -o yaml to inspect the full object, or use JSONPath if you only want the annotation value.

How do I remove last-applied-configuration from a resource?

Use kubectl annotate kubectl.kubernetes.io/last-applied-configuration-. After that, reapply the manifest if you want kubectl to recreate it.

Why does kubectl apply need the last applied configuration?

It needs the saved baseline to compare previous, current, and desired state. That comparison helps kubectl make safer updates and avoid overwriting unrelated fields.

Is last-applied configuration the same as managedFields?

No. Last-applied configuration is a client-side annotation used by traditional kubectl apply. managedFields is used by server-side apply to track field ownership on the API server.

Can I use kubectl apply without the annotation?

Sometimes yes, but the behavior may be less predictable for complex updates. Kubectl may not have a clean baseline for three-way merge, especially on resources that were not originally applied declaratively.