1. Proposed title of this feature request
Predictable mounting of Immutable Secrets and ConfigMaps

2. What is the nature and description of the request?

When immutable objects (such as secrets or configmaps) are deleted but still referenced by other resources, and new objects with the same names are created, the old, deleted objects will be mounted into newly created pods, while the new objects are ignored. This behavior is by design for immutable objects, which are cached by the kubelet according to upstream discussions[1].  However, it is unpredictable  and can lead some pods mounting the old objects and the other pods mounting the new ones depending on nodes. 

[1]https://github.com/kubernetes/website/issues/42359

known workaround is to use different names when creating the new immutable resources. 

3. Why does the customer need this? (List the business requirements here)

It is unpredictable. 

When resources are deleted, they should become invalid. When a new object is created, the object should have uniq ID which should be used to identify the object. Many applications have been developed expecting this behavior, which also aligns with Kubernetes' guaranteed declarative object management. 

Thus, the existing behavior continues to be misleading and non-intuitive for developers, leading to a high likelihood of recurring issues due to human error. Furthermore, this can cause operational malfunctions in already deployed applications, posing significant potential problems. This issue could also lead to considerable financial costs due to the need to redeploy commercial applications, along with the additional administrative work involved, which is expected to have a significant business impact and is difficult to accept.

4. List any affected packages or components.

kebelet