Using kubectl to edit the status of an object

kubernetes kubectl subresource status

3 min read | by Jordi Prats

As of kubectl v1.24, it is possible to patch subresources using the --subresource flag. This is useful for updating the status of an object, for example.

The --subresource flag is used to specify the subresource to be patched, so if we want to update the status of an object, we can use --subresource=status as follows:

kubectl edit pods demo --subresource=status

We can test it out by trying to delete the .status.conditions field of a pod. If we try to edit the status with kubectl edit pod test-pod:

(...)
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2024-02-12T08:52:15Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2024-03-15T14:30:14Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2024-03-15T14:30:14Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2024-02-12T08:52:15Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
(...)

And try to retrieve the pod's status we'll see that we haven't actually deleted the .status.conditions field:

$ kubectl get pod test-pod -o jsonpath='{.status.conditions}'
[{"lastProbeTime":null,"lastTransitionTime":"2024-02-12T08:52:15Z","status":"True","type":"Initialized"},{"lastProbeTime":null,"lastTransitionTime":"2024-03-15T14:30:14Z","status":"True","type":"Ready"},{"lastProbeTime":null,"lastTransitionTime":"2024-03-15T14:30:14Z","status":"True","type":"ContainersReady"},{"lastProbeTime":null,"lastTransitionTime":"2024-02-12T08:52:15Z","status":"True","type":"PodScheduled"}]

We can use the subresource flag to tell kubectl that we are updating the status:

k edit pod test-pod --subresource=status

If we delete the .status.conditions field and then retrieve the pod's status we'll see that we have actually deleted the .status.conditions field:

$ kubectl get pod test-pod -o yaml
(...)
status:
  containerStatuses:
  - containerID: containerd://43d42bd367d09698ba189a171da61f6c7e0f36fdfe1a35c312f65d9dfc4ad89f
    image: docker.io/library/alpine:latest
    imageID: docker.io/library/alpine@sha256:c5b1261d6d3e43071626931fc004f70149baeba2c8ec672bd4f27761f8e1ad6b
    lastState:
      terminated:
        containerID: containerd://61fcc725f6b2b7f93effffa0e0b9fc58b5b5e2f41b0e707fa32b002bb8208f55
        exitCode: 255
        finishedAt: "2024-03-15T14:28:46Z"
        reason: Unknown
        startedAt: "2024-03-15T12:04:00Z"
    name: test-pod
    ready: true
    restartCount: 33
    started: true
    state:
      running:
        startedAt: "2024-03-15T14:30:21Z"
  hostIP: 172.18.0.3
  phase: Running
  podIP: 10.244.0.24
  podIPs:
  - ip: 10.244.0.24
  qosClass: BestEffort
  startTime: "2024-01-30T15:50:17Z"

We'll need to be quick, as the status will be updated by the controller manager. If we wait even just a few seconds and then retrieve the pod's status we'll see that the .status.conditions field has been added back.

Some controllers might use the .status for keeping track of the state of the object, so be careful when updating it as it might cause unexpected behavior.

Posted on 18/03/2024

Categories