What happened?

After enabling In-Place Pod Vertical Scaling, if deploy a pod without setting memory (or cpu) request, kubelet will be failed at its second restart

What did you expect to happen?

kubelet restart successfully

How can we reproduce it (as minimally and precisely as possible)?

1. start kubelet with In-Place Pod Vertical Scaling enabled
2. deploy a pod without setting memory request, e.g:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - image: nginx:1.24.0
    imagePullPolicy: IfNotPresent
    name: nginx
    resources:
      requests:
        cpu: 100m

3. restart kubelet for the first time
4. restart kubelet for the second time
5. kubelet will fail with error: panic: could not restore state from checkpoint: checkpoint is corrupted, please drain this node and delete pod allocation checkpoint file "/var/lib/kubelet/pod_status_manager_state" before restarting Kubelet

Anything else we need to know?

After deploying the pod, the following information is saved in the file pod_status_manager_state:

      "nginx": {
        "cpu": "100m"
      }

Then restart kubelet for the first time, the relevant content in the file becomes:

      "nginx": {
        "cpu": "100m",
        "memory": "0"
      }

When deploying the pod, as there are no records in the checkpoint (pod_status_manager_state), kubelet will get resource config from pod.Spec.Container.Resources directly and save it to the checkpoint (without memory request)

Kubernetes version

$ kubectl version
# paste output here

Cloud provider

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)