Using kubectl to edit the status of an object
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