Searching for custom resources using SQL failed

[Jamel-jun]

What happened?

When I tried to search for an Ingress resource, I got no results.

However, it exists when searching for a Service resource.

What did you expect to happen?

The search for CR resources such as Ingress succeeds

How can we reproduce it (as minimally and precisely as possible)?

Use helm to deploy normally

Anything else we need to know?

Karpor version

$ karpor -V
0.5.9

OS version

# On Linux:
$ cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.17.3
PRETTY_NAME="Alpine Linux v3.17"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
$ uname -a
Linux karpor-server-6597fd5f66-j8fgb 5.10.134-17.2.al8.x86_64 #1 SMP Fri Aug 9 15:49:42 CST 2024 x86_64 Linux

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

[wujunwei]

If no one's working on it yet, I'm happy to do it :)

[elliotxx]

@wujunwei Bro, awesome! The task is yours— and let us know if you need anything! 🚀

[wujunwei]

@elliotxx I found that the searchable objects are generated by 'default-sync-strategy.yaml`. This doesn't prevent the endless addition of objects to this file. Instead, I suggest using the resource version interface of the cluster to get all the CRD in the cluster so it's easier to scale.
code like below:

	conf := ctrl.GetConfigOrDie()
	dc := discovery.NewDiscoveryClientForConfigOrDie(conf)
	resources, _ := dc.ServerPreferredResources()
	for _, resource := range resources {
		fmt.Println(resource.GroupVersion)
		for _, apiResource := range resource.APIResources {
			fmt.Println(" "+apiResource.Name)
		}
	}
//apps/v1
//	deployments
//	statefulsets
//	daemonsets
//	controllerrevisions
//	replicasets
//events.k8s.io/v1
//	events
// ...

It is also possible for the user to control which objects Karpor can access by giving specific kubeconfigs

[wujunwei]

If I do this, Syncregistry won't help much. Can I modify the logic: Will all GVRs not be read from SyncRegistry, but from the k8s cluster?

BTW, The effect of TransformRule, as I understand, is to strip down the object to just the metadata and the 'GVK' fields, the key kubectl.kubernetes.io/last-applied-configuration in the annotation should be remove too.

[elliotxx]

@wujunwei Sorry, there are many things during the Spring Festival that I didn’t have time to reply. Let’s take a look at this question cc @fanfan-yu

[fanfan-yu]

Hi. Karpor will build cache in memory for k8s resources should be synced (like informer). If watching all k8s resources from kube-apiserver, it will take up too much hardware resources may even cause restart.

[wujunwei]

Hi. Karpor will build cache in memory for k8s resources should be synced (like informer). If watching all k8s resources from kube-apiserver, it will take up too much hardware resources may even cause restart.

I got it , but there are still some problems：

1. Different k8s versions have different APIVersions (for example, ingress, only networking.k8s.io/v1 in the higher version, while lower versions will have other beta versions). Writing APIVersions in yaml files is not robustness.
2. In most k8s clusters, pods are often the most numerous , followed by configmap secret service etc. which already watched by Karpor.(BTW why don't watch STS)
3. In the code below, Karpor use NewTransformingInformer to build a informer which can use Transform function to strip down the object just remain the metadata,This can greatly save resources. (Should this work in existing designs?But TrimRule is not set now.)

h := &internal.EventHandler{EventHandler: handler, Queue: queue, Predicates: predicates}
	cache, informer := clientgocache.NewTransformingInformer(lw, &unstructured.Unstructured{}, resyncPeriod, h, trim)

4. We can also set up a synchronized blacklist to exclude resources that are rarely used and can not be list and watch.

This is indeed a major change not in a hurry to solve it now,just my personal suggestion. And I hope Karpor will become more and more perfect and easy to use.

[elliotxx]

@wujunwei Thank you for your attention and feedback! syncer will be upgraded in v0.7.0, mainly to improve the high availability level in large-scale cluster deployment. @fanfan-yu is following up on this evolution, and we can discuss more here, cc @fanfan-yu can answer the above questions when you have free time
Yes, let's go step by step.

[fanfan-yu]

Hi. Thank you for your attention and feedback! There are my solutions or suggestions for your problem.

1. For problem 1, I think it is a good problem. syncregistry is an effective way to describe the configuration for syncer, but there is no vaildation for syncregistry. I think we can use webhook or other methods to verify syncregistry in later version.
2. For problem 2, pod resources are often the most numerous and take up most memory of syncer, so we consider to separate components into user clusters for reducing stress and ensuring robustness. Besides, syncerwill sync special cr by setting syncregistry. If you would like to sync sts or others, you can config the syncregistry arbitrarily. By the way, we consider the white screen configuration sync rules in the long-term planning.
3. For problem 3, there is only the default configuration in our repository which can facilitates current insight. It is flexible to config sync rule for users.
4. For problem 4, I think. that user should understand the resources to be synced. If synchronized blacklist function is implemented, user should understand all-resources. It is difficult for most user.