### 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](https://github.com/openshift/kubernetes/blob/258f1d5fb6491ba65fd8201c827e179432430627/pkg/kubelet/kuberuntime/kuberuntime_manager.go#L556) not calculating the update if there are no limits (as in, if you do something naive like [this](https://github.com/kubernetes/kubernetes/compare/master...jkyros:kubernetes:minimal-patch-fix-inplacepodverticalscaling-limits) 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](https://github.com/openshift/kubernetes/blob/258f1d5fb6491ba65fd8201c827e179432430627/pkg/kubelet/kuberuntime/kuberuntime_manager.go#L592) and...doesn't really

### What additional tests do we need: 

- The [current test suite](https://github.com/kubernetes/kubernetes/blob/9791f0d1f39f3f1e0796add7833c1059325d5098/test/e2e/node/pod_resize.go#L664) 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: https://github.com/kubernetes/kubernetes/commit/72953418202f7d412072b2259e996efc8e14abbd

### 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](https://kubernetes.slack.com/archives/C06FSK01BGU/p1712688791899199) 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"  :smile: 


/sig node 

### Why is this needed?

- Trying to use `InPlacePodVerticalScaling` in the Vertical Pod Autoscaler (VPA) [here](https://github.com/kubernetes/autoscaler/pull/6652) (which will probably also make #122836  happy). A bunch of the usage (and test suite) of the VPA is on containers without limits. 

[FG:InPlacePodVerticalScaling] Add additional E2E Burstable Pod QoS test cases for pods without resource limits 
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : [FG:InPlacePodVerticalScaling] Add additional E2E Burstable Pod QoS test cases for pods without resource limits 
Issue date:

--- start body ---
### 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](https://github.com/openshift/kubernetes/blob/258f1d5fb6491ba65fd8201c827e179432430627/pkg/kubelet/kuberuntime/kuberuntime_manager.go#L556) not calculating the update if there are no limits (as in, if you do something naive like [this](https://github.com/kubernetes/kubernetes/compare/master...jkyros:kubernetes:minimal-patch-fix-inplacepodverticalscaling-limits) 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](https://github.com/openshift/kubernetes/blob/258f1d5fb6491ba65fd8201c827e179432430627/pkg/kubelet/kuberuntime/kuberuntime_manager.go#L592) and...doesn't really

### What additional tests do we need: 

- The [current test suite](https://github.com/kubernetes/kubernetes/blob/9791f0d1f39f3f1e0796add7833c1059325d5098/test/e2e/node/pod_resize.go#L664) 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: https://github.com/kubernetes/kubernetes/commit/72953418202f7d412072b2259e996efc8e14abbd

### 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](https://kubernetes.slack.com/archives/C06FSK01BGU/p1712688791899199) 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"  :smile: 


/sig node 

### Why is this needed?

- Trying to use `InPlacePodVerticalScaling` in the Vertical Pod Autoscaler (VPA) [here](https://github.com/kubernetes/autoscaler/pull/6652) (which will probably also make #122836  happy). A bunch of the usage (and test suite) of the VPA is on containers without limits. 

--- end body ---
