When kooper operates K8S object resources, can it be retrieved from the cache instead?

[AllenZMC]

When kooper operates K8S object resources, it can be retrieved from the cache instead of directly accessing k8s. This allows quick access to k8s objects.

[slok]

Hi @AllenZMC!

When you say retrieve what do you mean? when do you retrieve objects with kooper?, the object that you receive from kooper on each reconciliation loop iteration, is retrieved from the cache, and these objects are only updated when changes happen (that's the watcher purpose), the lister is used on start to get the initial full list of objects.

[AllenZMC]

Hi @slok . See the following code. Is the operation to get the configmap obtained from the cache or directly access k8s etcd? （I use kooper in my operator）
Because getting resources such as pods or configmap from the cache is faster, which can reduce the pressure of etcd.

configMap, err := p.kubeClient.CoreV1().ConfigMaps(namespace).Get(name, metav1.GetOptions{})

[slok]

Where is that line?

[AllenZMC]

This code is in spotahome/redis-operator

[AllenZMC]

I hope to quickly access the k8s resources such as pod, configmap, etc. in the operator.

[AllenZMC]

Obtaining k8s resources such as pods and configmaps from the cache is faster than directly accessing etcd

[slok]

oh, I understand now what do you mean.

That's business logic of the operator, not the operator framework itself, Kooper has nothing to do with that, Kooper maintains a reconciliation loop on specific resources, these resources are the ones that trigger the iteration handling of that resource changes, and this handling code is logic of the application (in this case the redis operator logic), so... the app should maintain it's own cache on the resources it wants.

Imagine those other resources as regular resources of any kind, a database query, a query to AWS API, a query to K8s API... whatever, Kooper is out of that scope of these resources.

Kooper caches the resources on what the reconciliation loop is based on, in this case, the RedisFailover CRDs, if the iteration logic needs to access to different resources (Redis commands, other Kubernetes resources, database access...) is part of the app, and is out of the scope of Kooper and the responsibility is on the app implementation.

[AllenZMC]

OK, thanks.

[slok]

Apart from that, Kooper only retrieves the resources it is subscribed to, so it will only cache those ones, so if my operator is based on pods, and when handling each pod log it access an ingress, Kooper cache will not have ingresses. So in case you could access the cache, the resources would not be stored there.

[slok]

Can I close the issue? or do you have more questions regarding this (or maybe I didn't explain correctly 😞)