kubernetes
Add support for --metric-annotations-allowlist and --metric-labels-allowlist arguments to be picked up from configmap instead of directly specifying in the deployment yaml
What would you like to be added: Add support for --metric-annotations-allowlist and --metric-labels-allowlist arguments to be picked up from configmap instead of directly specifying in the deployment yaml.
Why is this needed: This would help to update the annotation and label allowlist with just configmap deployment instead of changing the deployment yaml.
Describe the solution you'd like Add a configmap for kube-state metrics that is included in the deployment yaml and mounted either in a file or loaded in the env variable. This file/env variable will be used in the container args for specifying --metric-annotations-allowlist and --metric-labels-allowlist instead of directly using the values in deployment yaml. The container keeps watch on the configmap and whenever the configmap is updated, the container restarts to pick up the latest values to use as argument
Additional context This feature will help us update multiple clusters that we manage by simply updating configmaps instead of updating the deployment yaml
This feature will help us update multiple clusters that we manage by simply updating configmaps instead of updating the deployment yaml
qq: why will it be simpler to update configmaps? After a configmap is updated, do we still need to restart the pod?
qq: why will it be simpler to update configmaps? After a configmap is updated, do we still need to restart the pod?
Yes, the pods needs to restart to pick up the latest value from the configmap.
We have AKS clusters that get the ksm pods as part of the managed prometheus offering. Since the yaml is not defined by us, we do not want to update them directly as it introduces more challenges in terms of keeping track of any updates that are going to happen in the offerring.
Introducing the configmap will allow us to customize the startup arguments without changing anything else and it will be easier to maintain.
IIRC Isn't this already supported by --config (which is also hot-reloaded)?
