[FG:InPlacePodVerticalScaling] Add additional E2E Burstable Pod QoS test cases for pods without resource limits

[jkyros]

What would you like to be added?

It would be really great if InPlacePodVerticalScaling could in-place resize cpu on containers that have requests only (no limits).

Currently, InPlacePodVerticalScaling cannot successfully resize cpu against containers without limits. e.g. given this pod:

apiVersion: v1
kind: Pod
metadata:
  name: sleeper
  namespace: default
spec:
  containers:
  - args:
    - -c
    - sleep infinity
    command:
    - /bin/sh
    image: registry.k8s.io/ubuntu-slim:0.1
    imagePullPolicy: IfNotPresent
    name: sleeper
    resources:
      requests:
        cpu: 25m
        memory: 100Mi

If you change cpu: 25m to cpu: 50m, it will get stuck in resize: InProgress forever:

  containerStatuses:
  - allocatedResources:
      cpu: 50m
      memory: 100Mi
    ...
    resources:
      requests:
        cpu: 25m
        memory: 100Mi
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-05-04T00:11:16Z"
  ...
  qosClass: Burstable
  resize: InProgress

Why doesn't in-place work now without limits:

• This looks like a result of this kubelet code here not calculating the update if there are no limits (as in, if you do something naive like this it works, but probably has other consequences and I don't have enough background here to propose that as a proper fix )
• Memory looks like it "works" without limits, but it's special and...doesn't really

What additional tests do we need:

• The current test suite includes some Burstable cases, but does not cover all corners, specifically:
  • in-place increasing/reducing CPU requests on containers without limits
  • in-place removing limits from a container that previously had them
• Minimally could look something like this: 7295341

Additional background:

• This was discussed in the sig-node meeting on Apr 9, 2024, where I was encouraged to inquire via Slack
• Per that slack discussion with @vinaykul I was encouraged to open an issue to add additional test coverage so the "containers without limits" cases could be covered.
• This isn't just "please do this for me", I'm willing to do work here to get these corners covered if need be, but I don't want to be "in the way" 😄

/sig node

Why is this needed?

• Trying to use InPlacePodVerticalScaling in the Vertical Pod Autoscaler (VPA) here (which will probably also make [FR] Vertical Pod Autoscaling leveraging InPlacePodVerticalScaling #122836 happy). A bunch of the usage (and test suite) of the VPA is on containers without limits.

[vinaykul]

/triage accepted