k9s icon indicating copy to clipboard operation
k9s copied to clipboard

The `s` to scale doesn't work with HPA

Open raags opened this issue 1 month ago • 7 comments




Describe the bug The s key allows to scale a deployment set, but when using the same with an HPA, it shows the error:

no column index for READY

I assume this is because its looking for the READY column seen in deployment set. The help shows s as a valid hot key, so it should work for the hpa as well.

To Reproduce Steps to reproduce the behavior:

  1. Go to the list of HPAs
  2. Check that the help on top shows <s> to Scale
  3. After pressing s see the error on the bottom

Expected behavior s should work by giving an input box to change the min or max pod value (I thin min would make sense)

Versions (please complete the following information):

  • OS: OSx
  • K9s: v0.50.16
  • K8s: v1.33.2

raags avatar Nov 17 '25 20:11 raags

Submitted a PR https://github.com/derailed/k9s/pull/3690

uozalp avatar Nov 24 '25 20:11 uozalp

@raags Actually I think this is wrong and a side effect of (https://github.com/derailed/k9s/commit/6881892433f562acfef470baebb1777bb8cc61b0). The scale option should no be volunteered here. The whole concept of an hpa is that scale up/down is based on metrics and load and should not be via user intervention. Moreover scaling an hpa would result in an a defacto automatic up/down scale if the conditions warrant it. Also what does scaling an hpa actually means? Is the intent to change min/max? If so might as well edit the hpa directly.

Or... am I missing it?

derailed avatar Nov 24 '25 20:11 derailed

@derailed I agree. HPA is metrics-based autoscaling, manual scaling defeats the purpose.

I saw the scale option appeared on HPAs and thought maybe the intent was to provide a way to quickly scale the target resource when metrics-based scaling is reacting too slowly or hovering just below target.

How should we proceed? I can update the PR to simply remove the scale option from HPAs instead of trying to scale the target?

uozalp avatar Nov 24 '25 20:11 uozalp

@uozalp Thank you Umut!! I agree.

I think we should remove it. Looking at the offending PR tho, the problem goes deeper since any resource (excluding CRD) is going to default to scalable. Hence hpa, ingress, storageclass, etc... are going to have the scale option. That's on me as I should have caught this earlier ;( The pb is the fix is not trivial. I think what we need to do here is look for interesting subresources and enhance the meta accordingly as we do for CRDs.

Would this make sense?

derailed avatar Nov 25 '25 01:11 derailed

@derailed Yeah, I agree scale option for HPA wouldn't make sense. Although, having a pause action for an HPA would be really useful, but HPA doesn't support it (KEDA has it, but then thats very specific to it, can could be a custom hotkey instead). Another way for HPA to pause could be by setting min and max replica the same.

raags avatar Nov 25 '25 07:11 raags

@derailed I've closed PR #3690 and submitted a temporary fix in #3696 that removes the faulty logic and uses a hardcoded list of scalable resources.

However, as you mentioned, the proper fix (dynamically detecting /scale subresource availability) is not trivial.

uozalp avatar Nov 25 '25 14:11 uozalp

@uozalp Very kind! Thank you Umut, I'll take a peek and will noodle on this.

derailed avatar Nov 30 '25 15:11 derailed