-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add wildcard option to metric-labels-allowlist #1403
Conversation
1bc76dc
to
bbe7443
Compare
@Mikulas Do you mind rebasing the PR, and we can have a look, thanks! |
bbe7443
to
4b660fc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! Thank you! I am wondering if a single * would cause any problems, otherwise, this looks good apart from adding a few more test cases.
cc @tariq1890 @brancz please have a look as well as this changes our flags.
@@ -1495,8 +1498,8 @@ func TestPodStore(t *testing.T) { | |||
} | |||
|
|||
for i, c := range cases { | |||
c.Func = generator.ComposeMetricGenFuncs(podMetricFamilies(nil)) | |||
c.Headers = generator.ExtractMetricFamilyHeaders(podMetricFamilies(nil)) | |||
c.Func = generator.ComposeMetricGenFuncs(podMetricFamilies(c.AllowLabelsList)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great but ideally, we want a separate test case for this. Keep testing what we did before and add this as a new test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, updated
docs/cli-arguments.md
Outdated
@@ -32,7 +32,7 @@ Usage of ./kube-state-metrics: | |||
-h, --help Print Help text | |||
--host string Host to expose metrics on. (default "::") | |||
--kubeconfig string Absolute path to the kubeconfig file | |||
--labels-metric-allow-list string Allows to pass a list of additional Kubernetes label keys that will be used in the resource' labels metric. By default the metric contains only name and namespace labels. To include additional labels provide a list of resource names in their plural form and Kubernetes label keys you would like to allow for them (Example: '=namespaces=[k8s-label-1,k8s-label-n,...],pods=[app],...)' | |||
--labels-metric-allow-list string Allows to pass a list of additional Kubernetes label keys that will be used in the resource' labels metric. By default the metric contains only name and namespace labels. To include additional labels provide a list of resource names in their plural form and Kubernetes label keys you would like to allow for them (Example: '=namespaces=[k8s-label-1,k8s-label-n,...],pods=[app],...)'. A single '*' can be provided per resource instead to allow any labels, but that has severe performance implications (Example: '=pods=[*]'). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a thought: Wonder if there are scenarios where this might not work. 🤔 the argument having *
. Like manifests in yaml or cli.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, a single star is not an allowed symbol in labels (labels with length of one must match [a-z0-9A-Z]
) and even if such a label key would be allowed eg kubernetes.io/*/value
would not collide the ksm wildcard.
Configuration wise it should not clash with yaml features either as the argument value can/should be quoted.
I can't think of any issues. That being said an alternative syntax could be an ellipses eg pods=[...]
. That has worse readability in my opinion but might be safer.
4b660fc
to
f5f66cb
Compare
f5f66cb
to
71e0681
Compare
26e7cc5
to
30518dc
Compare
30518dc
to
70d039b
Compare
Thanks for the review :) I rebased the PR and updated tests as recommended. I'd be happy to add more tests if deemed necessary but it seems like |
@lilic Please take a look when you get a chance :) /assign lilic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
I am sorry for the delay, I already reviewed but forgot to press the button 🤦♀️
Thank you so much for this!! 🎉
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lilic, Mikulas 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:
Approvers can indicate their approval by writing |
Awesome, thank you :) |
What this PR does / why we need it:
#1301 introduced backwards compatibility issue by dropping all labels not defined in
--metric-labels-allowlist
. That feature is great and should arguably be enabled for all new deployments. However, constructing such a list may prove quite hard for users migrating from previous versions, especially if kube-state-metrics is managed by a different team than the ones consuming eg pod label metrics.This patch adds a new wildcard option that allows all labels on given resources. The assumption is that using this is a last resort when migrating to 2.0 (well, 2.1) from previous version. The suggested feature is as simple as possible to allow users to migrate. Generic pattern matching (regex) are explicitly a non-goal for this PR.
Prior art:
#1289 allow metric labels by default
#1247 PR with regex support
Fixes #1309
Relates to #1246