Custom resources produce message `Info metric %s does not have _info suffix` for metrics similar to core APIs

[chrischdi]

What would you like to be added:

When using custom resource configuration and defining metrics similar to core apis: a metric which outputs the owner of a CR (capi_machine_owner), kube-state-metrics outputs the following message for each CR which exists:

I0818 16:54:32.105070   71540 generator.go:79] "Info metric %s does not have _info suffix" capi_machine_owner="(MISSING)"

This comes from the following code:

https://github.com/kubernetes/kube-state-metrics/blob/64c05aebc8d9cad9a4988fbd4fb4e7e39fe340f0/pkg/metric_generator/generator.go#L79

In my particular case, I want to output the .metadata.ownerReferences as metrics:

kind: CustomResourceStateMetrics
spec:
  resources:
  - groupVersionKind:
      group: cluster.x-k8s.io
      kind: Machine
      version: v1beta1
    - name: owner
      help: Owner references.
      each:
        info:
          labelsFromPath:
            owner_is_controller:
            - controller
            owner_kind:
            - kind
            owner_name:
            - name
            owner_uid:
            - uid
          path:
          - metadata
          - ownerReferences
        type: Info

To comply to the OpenMetrics standard the type should get outputted as

# TYPE capi_machine_owner gauge

But currently it is

# TYPE capi_machine_owner info

Why is this needed:

To be able to accomplish the same metrics for CRs as we have for core APIs

Describe the solution you'd like

I don't have a good idea how to proceed here but I can see different ways to accomplish that:

1. Set the type to gauge if a custom resource metric of configuration type Info does not have the _info suffix in its name
2. Adjusting the configuration spec to allow to accomplish the same as above with the Gauge metric type
3. Enforce requiring the _info suffix at the metric name

• Note: I'm not a fan of this. It would feel weird if we have a _owners metric for core APIs but for CRs it would be called _owners_info.

I lean towards the first solution. The second one IMHO would allow to do the same via two different configuration types and makes things more complicated.

Additional context

[dashpole]

/assign @rexagod /triage accepted