kube
                                
                                 kube copied to clipboard
                                
                                    kube copied to clipboard
                            
                            
                            
                        Support discovery cache in local ~/.kube/cache/discovery directory like kubectl
Would you like to work on this feature?
No response
What problem are you trying to solve?
Since the API resources are not changing frequently, we do not need to discover the resource which has been found in the previous API query.
Describe the solution you'd like
Cache the discovery in ~/.kube/cache/discovery like what kubectl does.
Describe alternatives you've considered
No alternatives
Documentation, Adoption, Migration Strategy
No response
Target crate for feature
kube-client
Yeah, I think this makes sense. It's probably not something we should have on by default (since we are more a client-go equivalent than a kubectl equivalent), but we can pass in a cache location  like ~/.kube/cache/discovery/{context} to Discovery and re-use from there.
Some questions;
- Should we try to re-use kubectl's format? It seems like A LOT of files that are never garbage collected. We could just do one file per context.
- How do we determine whether a cache is out of date?
It's probably not something we should have on by default (since we are more a client-go equivalent than a kubectl equivalent), but we can pass in a cache location like
~/.kube/cache/discovery/{context}toDiscoveryand re-use from there.
I agree.
Indeed, there are many unclear points, and we need more time to figure out.
I see that kubectl uses discovery_client which is provided by client-go to own ability to cache api resources. And discovery client exposes Invalidate method to enforce no cached data and the next request will refresh the cache. Maybe we can set a timeout for cache refresh, FYI.
more details: discovery package func (d *CachedDiscoveryClient) Invalidate()
Can also see that this is wrapped up in a CachedDiscoveryClient which sets at ttl of 6 hours (other blog posts mentioned invalidation every 10 minutes, but it seems to be updated when going to master).
A long timeout makes sense for this type of cache, but if a controller is mutating apis it can also make sense to expose the invalidate call.
Yeah, it looks like an available solution. But still have many details not reach a consensus, like cache file format. I am going to implement it first and make a pr. By that time, let's explore further.
Should we try to re-use kubectl's format?
Keep the same format for Interoperability would be great.