feat: Use PartialObjectMetadata for Configmaps

[mrueg]

What this PR does / why we need it:
This PR introduces a metadataonly client, which can be used to fetch sparse data for large objects like configmaps.

How does this change affect the cardinality of KSM: (increases, decreases or does not change cardinality)
None

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #2463

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mrueg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mrueg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mrueg]

We can't use partialobjectmetadata for secrets unfortunately, since we have metrics for the secrets type that we expose.

[sftim]

We can't use partialobjectmetadata for secrets unfortunately, since we have metrics for the secrets type that we expose.

Secret supports type as a field selector.

I wonder if we could make a sort of informer that does a metadata-only watch per known Secret type, plus one that watches for unknown types and doesn't use partial object metadata. Should be quite a bit more efficient overall, at the cost of turning one watch into n.

[dgrisonnet]

/assign
/assign @richabanker
/triage accepted

[mrueg]

I still lack seeing the hoped memory improvements with this PR.
My test looks like the following (creates 100x 1MB sized configmaps):

for i in $(seq 1 100); do
        base64 /dev/urandom | head -c 1000000 > file.txt
        kubectl create configmap morecm$i --from-file="file.txt"
done

[dgrisonnet]

Few comments, but I am a fan of this change! :)

[dgrisonnet]

I might be missing something, but it seems you could call buildStores right away since this is an exact copy of its code.

Going even further, maybe we don't even need buildMetadataOnlyStores and could just call buildStores directly when building resource specific stores like:

-	return b.buildStoresFunc(configMapMetricFamilies(b.allowAnnotationsList["configmaps"], b.allowLabelsList["configmaps"]), &v1.ConfigMap{}, createConfigMapListWatch, b.useAPIServerCache)
+	return b.buildStoresFunc(configMapMetricFamilies(b.allowAnnotationsList["configmaps"], b.allowLabelsList["configmaps"]), &metav1.PartialObjectMetadata{}, createConfigMapListWatch, b.useAPIServerCache)

[mrueg]

The reason I created that is the different signature of the listWatchFunc (using metadata.Interface not clientset.Interface). Is there's a different way to do that, I'm all ears :)

[dgrisonnet]

Do we really need to do that ourselves? The client seems to already set the Accept header accordingly: https://github.com/kubernetes/kubernetes/blob/0b3b733c8437a946b7300a346ac948fec2e0b3ff/staging/src/k8s.io/client-go/metadata/metadata.go#L222

[mrueg]

This was mainly copying from the CreateKubeClient() func, I'm not sure if we need it here additionally.

Will metadata.List()/Watch() be called eventually or is that overwritten by ListWatchFunc?

[mrueg]

Few comments, but I am a fan of this change! :)

Great to hear! I'm still looking for better ideas to verify that it saves network traffic and reduces memory consumption on ksm.