### What happened?

We can't make sure app Container always reuses init Container cpuset, which may lead to the waste of CPU(init container has already exited but the cpuset can not be reused by other containers) and `not enough cpus available to satis
fy request` error.

<img width="1421" alt="image" src="https://github.com/kubernetes/kubernetes/assets/14137033/1135377d-dde3-48d5-84aa-c940f9bf4992">


### What did you expect to happen?

app Container always reuses init Container cpuset after init Container exits.

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

This is one of the spefic condition that might cause the issue:
- Pod A ready to allocate cpuset with `init container` and `app container` both request 92 cpu.
- Pod B already running on the node and ready to be deleted.

1. Pod A's init container starts to allocate cpuset（4-24,48-60,73-84,100-120,144-156,169-180）：
```
I0510 16:40:21.232949   20266 state_mem.go:80] "Updated desired CPUSet" podUID="2f9922ce-df66-4b58-abd8-01187b813318" containerName="init-container" cpuSet="4-24,48-60,73-84,100-120,144-156,169-180"
```
2. Pod A's init container exits.
3. Before Pod A's app container starts to allocate cpuset, Pod B gets deleted and release it's cpuset（cpuSet="0-3,25-47,61-72,85-99,121-143,157-168,181-191）：
```
I0510 16:40:27.759335   20266 state_mem.go:107] "Deleted CPUSet assignment" podUID="74510e24-48ba-4fd7-ab85-80dd99c6df5d" containerName="deleted-container"
I0510 16:40:27.759714   20266 state_mem.go:88] "Updated default CPUSet" cpuSet="0-3,25-47,61-72,85-99,121-143,157-168,181-191"
```
4. Pod A's app container starts to allocate cpuset. 
What we expect is that Pod A's app container reuses its init container's cpuset.
But due to Pod B's deletion, it won't allocate the same cpuset as its init container.（4-49,100-145）：
```
 I0510 16:40:27.989453   20266 state_mem.go:80] "Updated desired CPUSet" podUID="2f9922ce-df66-4b58-abd8-01187b813318" containerName="app-container" cpuSet="4-49,100-145"
```

Now we have Pod A's init container taking cpuset: 4-24,48-60,73-84,100-120,144-156,169-180
And  Pod A's app container  taking cpuset: 4-49,100-145
The init container cpuset won't be reused as expected.

A new Pod C starts to allocate cpuset, it may get `not enough cpus available to satis
fy request` error

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
# paste output here
1.30
```

</details>


### Cloud provider

<details>
NONE
</details>


### OS version

<details>

```console
# 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
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


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

<details>

</details>

app Container can't reuse its init Container cpuset in a specific condition
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : app Container can't reuse its init Container cpuset in a specific condition
Issue date:

--- start body ---
### What happened?

We can't make sure app Container always reuses init Container cpuset, which may lead to the waste of CPU(init container has already exited but the cpuset can not be reused by other containers) and `not enough cpus available to satis
fy request` error.

<img width="1421" alt="image" src="https://github.com/kubernetes/kubernetes/assets/14137033/1135377d-dde3-48d5-84aa-c940f9bf4992">


### What did you expect to happen?

app Container always reuses init Container cpuset after init Container exits.

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

This is one of the spefic condition that might cause the issue:
- Pod A ready to allocate cpuset with `init container` and `app container` both request 92 cpu.
- Pod B already running on the node and ready to be deleted.

1. Pod A's init container starts to allocate cpuset（4-24,48-60,73-84,100-120,144-156,169-180）：
```
I0510 16:40:21.232949   20266 state_mem.go:80] "Updated desired CPUSet" podUID="2f9922ce-df66-4b58-abd8-01187b813318" containerName="init-container" cpuSet="4-24,48-60,73-84,100-120,144-156,169-180"
```
2. Pod A's init container exits.
3. Before Pod A's app container starts to allocate cpuset, Pod B gets deleted and release it's cpuset（cpuSet="0-3,25-47,61-72,85-99,121-143,157-168,181-191）：
```
I0510 16:40:27.759335   20266 state_mem.go:107] "Deleted CPUSet assignment" podUID="74510e24-48ba-4fd7-ab85-80dd99c6df5d" containerName="deleted-container"
I0510 16:40:27.759714   20266 state_mem.go:88] "Updated default CPUSet" cpuSet="0-3,25-47,61-72,85-99,121-143,157-168,181-191"
```
4. Pod A's app container starts to allocate cpuset. 
What we expect is that Pod A's app container reuses its init container's cpuset.
But due to Pod B's deletion, it won't allocate the same cpuset as its init container.（4-49,100-145）：
```
 I0510 16:40:27.989453   20266 state_mem.go:80] "Updated desired CPUSet" podUID="2f9922ce-df66-4b58-abd8-01187b813318" containerName="app-container" cpuSet="4-49,100-145"
```

Now we have Pod A's init container taking cpuset: 4-24,48-60,73-84,100-120,144-156,169-180
And  Pod A's app container  taking cpuset: 4-49,100-145
The init container cpuset won't be reused as expected.

A new Pod C starts to allocate cpuset, it may get `not enough cpus available to satis
fy request` error

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

```console
$ kubectl version
# paste output here
1.30
```

</details>


### Cloud provider

<details>
NONE
</details>


### OS version

<details>

```console
# 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
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


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

<details>

</details>

--- end body ---
