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 :)

[rexagod]

Since generic types only support interfaces with no methods, we might want to rely on some old school type casting here?

[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?

[rexagod]

The former as that seems to be the underlying invocation, so we should be good to drop this.

[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.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[rexagod]

/remove-lifecycle rotten