### What happened?

The logic is as follows:
1. Manually update secret resources.
2. kubelet listens to resources and updates the watch cache.
3. Start the pod and query the volume attached to the secret resource.

but probabilistically, especially at lots of operating pressures. The third step is performed before the second step. As a result, the old secret is mounted when the pod is started.

![image](https://github.com/kubernetes/kubernetes/assets/17514799/e72a9968-6467-4436-803d-002df05b5df7)

----------

![image](https://github.com/kubernetes/kubernetes/assets/17514799/b81c5384-4b47-420a-9995-6ce46ce275c5)

https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/



### What did you expect to happen?

![image](https://github.com/kubernetes/kubernetes/assets/17514799/e8fd8400-b3c4-4072-8399-322548183c3c)

solution: kubelet should alway get lastest secret/configmap resource in pod add event instead of using cache

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

see What happend

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

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

</details>


### Cloud provider

<details>

</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>

kubelet should alway get lastest secret/configmap resource in pod add event
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : kubelet should alway get lastest secret/configmap resource in pod add event
Issue date:

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

The logic is as follows:
1. Manually update secret resources.
2. kubelet listens to resources and updates the watch cache.
3. Start the pod and query the volume attached to the secret resource.

but probabilistically, especially at lots of operating pressures. The third step is performed before the second step. As a result, the old secret is mounted when the pod is started.

![image](https://github.com/kubernetes/kubernetes/assets/17514799/e72a9968-6467-4436-803d-002df05b5df7)

----------

![image](https://github.com/kubernetes/kubernetes/assets/17514799/b81c5384-4b47-420a-9995-6ce46ce275c5)

https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/



### What did you expect to happen?

![image](https://github.com/kubernetes/kubernetes/assets/17514799/e8fd8400-b3c4-4072-8399-322548183c3c)

solution: kubelet should alway get lastest secret/configmap resource in pod add event instead of using cache

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

see What happend

### Anything else we need to know?

_No response_

### Kubernetes version

<details>

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

</details>


### Cloud provider

<details>

</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 ---

None