Do you see need and natural point for cache invalidation? Now we are caching pod resources based on namespace + pod name, if I'm reading this correctly. Should we clear the cache on removing pod sandbox, or perhaps in some other events that could make us suspicious that pod has changed....

In the current version we tried to implement (and use) this so that both caching and invalidation would be transparent/implicit, with the trigger for invalidation being if we fail to find a pod in the cached last list result. To be honest, I am not sure if this is enough, we'll need to dig in more to understand better.

If we use the pod resource API at all, we use it to generate extra topology hints for device/memory+CPU alignment. My bigger fear than inaccuracy was the extra cost, especially in increased latency for decision making. That is why if enabled, we now trigger an asynchronous pod resource API lookup during pod creation and use the result during container creation, if it is available by that time.

It might be that we'd need also explicit invalidation, which we could then trigger, for instance, whenever a container is stopped. But we'll need to dig in more to understand it better.

It might be that we'd need also explicit invalidation, which we could then trigger, for instance, whenever a container is stopped. But we'll need to dig in more to understand it better.

As this feature is behind an off-by-default option, I suppose we could start with it, experiment, and consider explicit invalidation in a separate PR.