Support per-request-level shouldBypassCache configuration in the client Reader implementation

[Yesphet]

When getting an Object through the default client, whether to read from the cache has been determined based on client.Options when creating the Client. In our scenario, for a same Object, most of the time we want to read it from the local cache, but in a few scenarios with high consistency requirements, we need to read it from apiserver directly. At present, we create two clients, one with cache and one without bringing implementation. Can we support using the same client to achieve this ability, such as putting a Value in the context or add a GetOption/ListOption to decide whether to bypass cache for this request?

I'm not sure if this is a general requirement. If so, I can implement it

[sbueringer]

There's also the APIReader which never uses the cache.

Not sure about adding an option. The problem is it wouldn't make sense for a lot of implementations of the Client interface

[Yesphet]

There's also the APIReader which never uses the cache.

Not sure about adding an option. The problem is it wouldn't make sense for a lot of implementations of the Client interface

cluster.GetClient() and cluster.GetAPIReader() are essentially two clients, one with cache and one without. This is also our current implementation, but I don't think it's that elegant because we have to build two clients (we only used the controller-runtime client package to replace client-go ), so I want to discuss whether there is a solution that can be solved with only one client

[alvaroaleman]

What is your use-case for wanting this?

[Yesphet]

What is your use-case for wanting this?

@alvaroaleman Sorry for the late reply. We deploy our business workloads through a set of pods, with one pod acting as the leader and the others as followers. Additionally, we have a component responsible for the high availability of the business within this set of pods. This component uses the controller-runtime/pkg/client to access the Kubernetes API server. It labels/annotates the pods to record some information like Role.
Most of the time, this component can get pod informations through the client cache. However, when the leader is not working, the high availability component needs to access the api-server directly to ensure the consistency of the labels and annotations on the pods. Currently, our solution involves creating two clients: one configured with a cache and one without. This approach feels inelegant and results in a lot of redundant client configuration code. Therefore, I would like to discuss whether it is possible to support a per-request-level cache toggle using a single client, like:

cli.Get(WithDisableCache(ctx), ...)