Managing Kubernetes subresources like status and scale has traditionally been clunky for CLI users. Until recently, interacting with these required raw HTTP calls or complex curl invocations, making operations difficult to script and error-prone. With the graduation of to stable in Kubernetes v1.33, users now have native support for subresource manipulation directly within .
The Kubernetes API defines subresources such as status, scale, and resize to isolate specific update operations. These endpoints are commonly used by controllers, but until now, human users had no clean way to interact with them using kubectl. For example:
Fetching the current status of a deployment required querying the full object or making raw HTTP requests.
Updating replica counts through the scale subresource was either not possible via kubectl or required complex scripting.
CustomResourceDefinitions (CRDs) with subresources were even more tedious to handle.
This KEP introduces a --subresource flag across key kubectl commands, streamlining these workflows.
The enhancement builds on the resource builder and visitor pattern already in use within kubectl, adding a .WithSubresource() chain to target the correct API path. Table printer support was extended to pretty-print responses from status and scale subresources, ensuring consistency in output formatting.
For CRDs:
status output reuses additionalPrinterColumns defined in the CRD spec.
scale output mimics native resources by adding desired/available replicas.
This enhancement significantly improves the developer experience when managing Kubernetes objects via kubectl. By exposing subresources as first-class citizens, it simplifies scripting, debugging, and day-to-day cluster operations. Whether you're scaling CRDs, inspecting status updates, or editing a subset of object fields, --subresource brings much-needed ergonomics to Kubernetes CLI workflows.
If you're using custom controllers or automation pipelines that rely on subresources, it's time to update your toolchains and start leveraging this feature natively through kubectl.
FAQs
What is the --subresource flag in kubectl?
The --subresource flag allows users to interact directly with subresources such as status, scale, and resize using standard kubectl commands like get, patch, edit, apply, and replace.
Why was this feature introduced?
Previously, managing subresources required raw API calls or curl, making it inconvenient. This enhancement integrates subresource access into kubectl, making it more intuitive and script-friendly.
Which subresources are currently supported?
Only status and scale are supported as of now. Attempting to use other subresources (e.g., logs) will return an error.
Can I use this with Custom Resource Definitions (CRDs)?
Yes, provided the CRD defines a status or scale subresource. The same --subresource flag will work for CRDs that support these subresources.
Is this feature available in all Kubernetes versions?
No. It requires Kubernetes v1.24+ due to API changes introduced in that version. Full GA support is available starting with v1.33.
Like what you read? Support my work so I can keep writing more for you.
A small act of support goes a long way. You're helping me stay consistent and keep the content flowing.
Learn. Build. Ship. Together
40+
Technical blog posts
8+ years
Industry experience in DevOps & Infra
100+
YouTube subscribers
1500+
Developers on the newsletter
# View status subresource (same output as full object)kubectl get deployment nginx-deployment --subresource=status# View current replica counts via scale subresourcekubectl get deployment nginx-deployment --subresource=scale
kubectl get pod nginx --subresource=logs# error: --subresource must be one of [status scale], not "logs"kubectl get pod nginx --subresource=scale# Error from server (NotFound): the server could not find the requested resource
GitHub cut hosted runner prices but planned fees for self-hosted Actions, triggering backlash. The change was paused. Here’s what happened and what to expect.
