【k8s】【DiscoveryClient】【缓存】

编程入门 行业动态 更新时间:2024-10-10 08:26:25

【k8s】【DiscoveryClient】【<a href=https://www.elefans.com/category/jswz/34/1771061.html style=缓存】"/>

【k8s】【DiscoveryClient】【缓存】

DiscoveryClient 缓存问题

缓存目录: 默认 /root/.kube/cache

k8s 使用DiscoveryClient 会对api-gvk信息进行缓存 因为这些信息不太需要变动
首先维护的缓存包括两份数据 http和discovery cache。
http cache 比 discovery cache大一些,多出来的部分主要是由于http cache保存的是responce头部和body 而 discovery cache保存body json,http cache会额外保存/openapi/v2的响应 并使用其作为cache。
.diskv-temp 是为了保证原子性写入的文件 每次缓存会先写入临时文件 再将临时文件命名为缓存文件。
缓存的key为:

func cacheKey(req *http.Request) string {if req.Method == http.MethodGet {return req.URL.String()} else {return req.Method + " " + req.URL.String()}
}

value为对应的 resp
当使用此cacheDiscoveryClient 时,即使拿到http响应数据时 对上层是无感知的 但可以通过观察返回响应中X-From-Cache:1的头部有无来观察此响应是否是cache返回
cache 使用包名称"github/gregjones/httpcache"
使用方法

	d := diskv.New(diskv.Options{PathPerm: os.FileMode(0750),FilePerm: os.FileMode(0660),BasePath: cacheDir,TempDir:  filepath.Join(cacheDir, ".diskv-temp"),})t := httpcache.NewTransport(diskcache.NewWithDiskv(d))

当上层获取gvk时 由于gvk不经常变动 采取CachediscoveryClient更加合理 此客户端维护本身的discovery缓存 实际是对resp的硬编码数据 维护方式依据gvk路径对json文件进行缓存
唯一的依据是文件时间 默认超时时间6h 当判断时间超时时 对此req重新发请求 并缓存编码之后结果

func NewCachedDiscoveryClientForConfig(config *restclient.Config, discoveryCacheDir, httpCacheDir string, ttl time.Duration) (*CachedDiscoveryClient, error) {if len(httpCacheDir) > 0 {// update the given restconfig with a custom roundtripper that// understands how to handle cache responses.config = restclient.CopyConfig(config)config.Wrap(func(rt http.RoundTripper) http.RoundTripper {return newCacheRoundTripper(httpCacheDir, rt)})}discoveryClient, err := discovery.NewDiscoveryClientForConfig(config)if err != nil {return nil, err}return newCachedDiscoveryClient(discoveryClient, discoveryCacheDir, ttl), nil
}

注意如果httpCacheDir 为空 由于RoundTripper未被自定义设置 将不会对缓存文件进行读取(个别)并返回请求 而是直接使用真实的请求 。
在请求/openapi/v2时 当http cache中不存在 会使用真实请求 否则 使用http cache中的值(在http cache中能够使用缓存cache的主要是以下情况

go/pkg/mod/github/gregjones/httpcache@v0.0.0-20180305231024-9cad4c3443a7/httpcache.go
1,服务器支持 服务器对此请求返回对应的etag 等值 并允许缓存此响应(get,head请求 非range)
2,当包括重新修剪if-none-match,last-modified头部,将其发送给apiserver,当apiserver认为当前请求的if-none-match,last-modified符合要求 会返回304响应和
空的结构体  判断逻辑如下resp, err = transport.RoundTrip(req)if err == nil && req.Method == "GET" && resp.StatusCode == http.StatusNotModified {// Replace the 304 response with the one from cache, but update with some new headers 这里可以重用cacheendToEndHeaders := getEndToEndHeaders(resp.Header)for _, header := range endToEndHeaders {cachedResp.Header[header] = resp.Header[header]}resp = cachedResp} else if (err != nil || (cachedResp != nil && resp.StatusCode >= 500)) &&req.Method == "GET" && canStaleOnError(cachedResp.Header, req.Header) {// In case of transport failure and stale-if-error activated, returns cached content  这种情况k8s不会发生 因为resp不会额外设置头部 // when availablereturn cachedResp, nil} else {if err != nil || resp.StatusCode != http.StatusOK {t.Cache.Delete(cacheKey)}if err != nil {return nil, err}}

主要由于此部分不经常变动 并且内容较多 因此直接通过客户端缓存获取。
其他部分请求 实际均不会从http cache中拿取数据 而是从discovery cache中拿取明文数据 直到过期后 从 apiserver重新拿取数据 并写入discovery cache 缓存。

更多推荐

【k8s】【DiscoveryClient】【缓存】

本文发布于:2024-02-11 15:09:56,感谢您对本站的认可!
本文链接:https://www.elefans.com/category/jswz/34/1681638.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
本文标签:缓存   k8s   DiscoveryClient

发布评论

评论列表 (有 0 条评论)
草根站长

>www.elefans.com

编程频道|电子爱好者 - 技术资讯及电子产品介绍!