KEP-5620: Node resizing via balloons.

[bwsalmon]

• One-line PR description: Node resizing via balloons

• Issue link: Node resizing via balloons #5620

• Other comments:

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: bwsalmon / name: Brandon Salmon (5746db2)
• ✅ login: bwsalmon / name: bwsalmon (5e887da, 9b06685, be366b2, e1ca310)

[k8s-ci-robot]

Hi @bwsalmon. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[ffromani]

This usecase seems to be better served by #5319

[bwsalmon]

Let me take a look. Obviously there are a few ways to address the use case.

[ffromani]

/ok-to-test

please make sure to fill keps/prod-readiness/sig-node/NNNN.yaml. It's probably too late for the 1.35 cycle.

[toVersus]

• Does this mean that the Balloon Pods are DaemonSets that specify the new PriorityClass introduced in this KEP? In other words, this doesn’t involve adding a new core resource like BalloonPod, right?
• Since they are expected to run in the kube-system namespace, is that achieved by restricting the new PriorityClass so that it can only be used within the kube-system namespace?
• Since they’re treated like regular pods, that means Balloon Pods are actually launched as containers (e.g. containers that just keep sleeping indefinitely), right?

[bwsalmon]

Excellent questions:

1. Yes, I don't believe we need to add a custom resource, although if we find a need I'm open to be convinced otherwise. The hope is for this to be very light weight.
2. I think that is reasonable, yes. I don't have enough clarity on the expectations of ACLs to feel confident about that yet, though.
3. Yes, that is correct; they should be normal containers that do nothing.

[toVersus]

Thanks! It's much clearer now.

Yes, I don't believe we need to add a custom resource

It might be better to specify in the Non-Goals section that new core and custom resources should not be added. Also, you could include a sample manifest of how to use Balloon Pods in the Proposal section or somewhere, such as a DaemonSet with a new priority class.

[bwsalmon]

/ok-to-test

please make sure to fill keps/prod-readiness/sig-node/NNNN.yaml. It's probably too late for the 1.35 cycle.

Sg, thanks! I'll fill in the PRR yaml. This should be fine for 1.36, unless @dchen1107 has a different opinion than our last conversation...

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: bwsalmon
Once this PR has been reviewed and has the lgtm label, please assign jpbetz, mrunalp for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• keps/prod-readiness/OWNERS
• keps/sig-node/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment