你想添加什么内容?
当apiserver缓存未准备好时,带有resourceVersion=0的List请求会从apiserver缓存中获取数据,而不是直接从etcd获取。
staging/src/k8s.io/apiserver/pkg/storage/cacher/cacher.go
func (c *Cacher) GetList(ctx context.Context, key string, opts storage.ListOptions, listObj runtime.Object) error {
recursive := opts.Recursive
resourceVersion := opts.ResourceVersion
pred := opts.Predicate
if shouldDelegateList(opts) {
return c.storage.GetList(ctx, key, opts, listObj)
}
listRV, err := c.versioner.ParseResourceVersion(resourceVersion)
if err != nil {
return err
}
if listRV == 0 && !c.ready.check() {
// If Cacher is not yet initialized and we don't require any specific
// minimal resource version, simply forward the request to storage.
return c.storage.GetList(ctx, key, opts, listObj)
}
}
为什么需要这个功能?
在我们的生产环境中,某些资源(如pod)的数量非常大(30万+),节点数量超过7万。apiserver缓存有时会出现累积延迟,kubelet的List请求直接从etcd获取pod数据。这消耗了大量的CPU和内存,这是不期望的。我希望List请求能够像ConsistentListFromCache特性门一样从apiserver缓存中获取数据。
7条答案
按热度按时间6qftjkof1#
/sig api-machinery
/cc @wojtek-t@serathius
i7uaboj42#
/triage已接受
可能与#124724存在一些重复的上下文。
xghobddn3#
@olderTaoist,嘿,我能接手这个吗?
只有一个问题,我们需要在这个条件**listRV == 0 && !c.ready.check()**中添加ConsistentListFromCache标志,还是我们需要添加另一个标志,因为这个标志已经添加了,并且在当前提案的后续场景中执行相同的情况。
cxfofazt4#
改进未初始化的监视缓存案例是下一个议程,但这是一个API更改和KEP-2340的更改。这需要更多的考虑。在下一个版本中,我们将默认启用缓存的一致性读取。我建议先等待用户对这个功能提供一些反馈。
pprl5pva5#
+1给Marek - 我们不要一次改变太多
zxlwwiss6#
改进未初始化的watch缓存案例
下一步的议程是改进未初始化的watch缓存,但这是一个API更改和KEP-2340的更改。这需要更多的考虑。在下一个版本中,我们将默认启用从缓存进行一致性读取。我建议先等待用户对这个功能提供一些反馈。顺便问一下,你是否已经在生产环境中启用了这个功能?你遇到了任何问题吗?我们进行了一些研究,最终选择了这个功能。我们目前正在我们的生产集群中灰度测试这个功能。我们的k8s有7k+个节点和100k+个pods。
c3frrgcw7#
这个函数是否可以缓存序列化后的JSON对象,从而实现更快的响应速度?