Add --subresource flag to kubectl set resources

[LarssonOliver]

What would you like to be added:

Hi! 👋

I'd like the --subresources flag to be available in the kubectl set resources command.

Why is this needed:

Since 1.32, updating resources of running pods is done using the /resize subresource (see kubernetes/kubernetes#128266).

Pre-1.32, when using the InPlacePodVerticalScaling feature gate, resources of pods could be updated using the kubectl set resources command. Since this is no longer the case, we now have to use the following patch command:

kubectl patch pod nginx --subresource resize --patch '{"spec":{"containers":[{"name":"nginx","resources":{"requests":{"cpu":"2"},"limits":{"cpu":"4"}}}]}}'

If we add the --subresource flag to the set resources command, we would once again be able to use it to update the resources of running pods. Example:

kubectl set resources pod nginx --subresource resize --requests=cpu=2 --limits=cpu=4

---

An alternative solution could be that set resources automatically invokes the /resize subresource should the target resource of type be "pod".

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[mpuckett159]

We will accept this issue, right now we are discussing whether we should deprecate the command for pods and point people to apply or patch, or try and fix it. We will bring it up on the next sig-cli meeting.

[LarssonOliver]

Awesome! Thanks for considering this. I wanted to elaborate a little...

• The set resources command is as far as I understand it just a helper command wrapping patch to make updating resources of various pod templates easier in the terminal. It serves to eliminate having to type out a patch similar to what I showed above every time. It would only make sense that this command should work for every type of resource that specifies a resource field. If this is deprecated for pods, there should probably be a discussion around if set resources should be deprecated in its entirety for consistency reasons.
• Since set resources is a helper wrapping patch, exposing options of patch to set resources (in this case --subresource) is only natural. Alternatively, we can make set resources smart enough to determine these options on its own as part of being a helper command.
• The naming of set resources suggests that it may be used to actually set resources. Since we will be supporting InPlacePodVerticalScaling going forward, it would be strange to have a command named set resources that cannot set resources of the only(?) type of resource consumer there is.

If we decide to deprecate this:

• We should clarify on the CLI --help page that this command is not intended to operate directly on pods, as its name could lead some to believe.
• The documentation on the website should be updated to reflect this. Currently, it says:

"Specify compute resource requirements (CPU, memory) for any resource that defines a pod template."

And yes, a pod itself does not define a template of a pod. But I still believe this can be made more clear.

---

I type this command somewhat often when testing and experimenting on stuff and would love for it to exist in a post-1.32 world. In the meantime, I implemented something similar as a kubectl plugin: https://github.com/LarssonOliver/kubectl-set_pod_resources

Thanks!

[soltysh]

This particular issue was discussed during yesterday's SIG-CLI call.

To provide some context, --subresource flag was meant to help with working with multiple sub-resources as described in that enhancement. So it's already possible to combine it with kubectl patch as you pointed out in the original description of this issue. But in all of the currently supported commands we carefully looked and ensure that the flag has a broader applicability, iow. it should work with most or ideally with all currently available sub-resources. In this particular case, we are limiting the functionality strictly to /resize sub-resource, which in our opinions isn't sufficient to guarantee adding separate flag. Lastly, there exist multiple alternatives (kubectl patch and your plugin approach), and since kubectl 1.33 the introduction of kuberc which can easily fill in the gap.

Base on the above we've decide not to expand the currently existing flags to support this very narrow use-case.

/remove-triage accepted
/close

[k8s-ci-robot]

@soltysh: Closing this issue.

In response to this:

This particular issue was discussed during yesterday's SIG-CLI call.

To provide some context, --subresource flag was meant to help with working with multiple sub-resources as described in that enhancement. So it's already possible to combine it with kubectl patch as you pointed out in the original description of this issue. But in all of the currently supported commands we carefully looked and ensure that the flag has a broader applicability, iow. it should work with most or ideally with all currently available sub-resources. In this particular case, we are limiting the functionality strictly to /resize sub-resource, which in our opinions isn't sufficient to guarantee adding separate flag. Lastly, there exist multiple alternatives (kubectl patch and your plugin approach), and since kubectl 1.33 the introduction of kuberc which can easily fill in the gap.

Base on the above we've decide not to expand the currently existing flags to support this very narrow use-case.

/remove-triage accepted
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.