feat: Add timezone to kube_cronjob_info / Make kube_cronjob_next_schedule_time timezone-aware

[mrueg]

What this PR does / why we need it:
Cronjob is not timezone aware.
How does this change affect the cardinality of KSM: (increases, decreases or does not change cardinality)
Adds one label to the kube_cronjob_info metric.

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 #2206

[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

[dgrisonnet]

wouldn't it be better in its own metric rather than in the info metric?

[mrueg]

There's a 1:1 relationship, why would you prefer a dedicated metric for it?

[mrueg]

@dgrisonnet any feedback here?

[dgrisonnet]

_info is not a very intuitive suffix which is why I don't really like these metrics where we just end up dumping a bunch of labels that aren't really related between one another.

I don't know what was the historical reasoning for putting labels into these metrics, but I can also see some dedicated metrics for values part of objects spec:

kube-state-metrics/internal/store/pod.go

Lines 1212 to 1231 in 569e820

	func createPodRestartPolicyFamilyGenerator() generator.FamilyGenerator {
	return *generator.NewFamilyGeneratorWithStability(
	"kube_pod_restart_policy",
	"Describes the restart policy in use by this pod.",
	metric.Gauge,
	basemetrics.STABLE,
	"",
	wrapPodFunc(func(p *v1.Pod) *metric.Family {
	return &metric.Family{
	Metrics: []*metric.Metric{
	{
	LabelKeys: []string{"type"},
	LabelValues: []string{string(p.Spec.RestartPolicy)},
	Value: float64(1),
	},
	},
	}
	}),
	)
	}

To me, info should be limited to the default labels. Any other information that we want to expose should be in its own dedicated metric. What is your opinion on that?

[mrueg]

I agree on having a separate metric for anything that does not have a 1:n relationship within the object. For 1:1 relationships, additional time series make it difficult to correlate between multiple labels vs. simply extracting the ones you need:
max(resource_info) by (label1, label2, label3).
Trying to do the same with multiple metrics can get very annoying and more error-prone.

To me, the _info metric should describe all single-value keys of the object that are static over its lifetime and non-numeric.

[rexagod]

Hmm, there seems to be a naming discrepancy between per-property gauges and per-object info metrics, so there's no clear pattern we can adhere to.

That being said, accumulating all cardinally-bound fields as label-sets into a per-object _info metric opens the room for metrics with a large number of labels. The metric itself can grow to become unintentionally cardinal and dropping unwanted labels will entail relabelling efforts. Splitting this into per-field metrics will limit the cardinality and allow for a more granular control.

Users should be able to add the timezone label to any exported metric using a foo_metric * on(job) group_left(timezone) kube_cronjob_timezone.

[mrueg]

I tried to define it here:
the _info metric should describe all single-value keys of the object that are static over its lifetime and non-numeric

[logicalhan]

/triage accepted
/assign @dgrisonnet