Frederic Branczyk

You can configure the certificate expiry thresholds https://github.com/kubernetes-monitoring/kubernetes-mixin/blob/c0b31ea63564966021f9e6010090acded475b192/config.libsonnet#L42-L43 If you want to ignore it entirely though you can also just remove the alert, or silence it :slightly_smiling_face: .

I'm not aware of tooling to declaratively silence alerts, I agree that would be neat to have. @gianrubio maintains the helm charts, the coreos/red hat team just maintains the jsonnet...

It seems that this issue is about expired client certs after all :slightly_smiling_face: . I'll keep this open for now as prometheus-operator/prometheus-operator#2058 is correct, this alert is about client certs,...

I realize this is drastic but if I recall correctly if you bump logging verbosity to --v=10 then you see the user identity of the certificate printed. That's the best...

@daimoniac I don't think that's a good idea, that would allow clients to produce arbitrary amounts of metrics leading to a denial of service attack against a kubernetes API. I...

Do you feel there is anything additional in our setup that should be added or additionally documented? If you could contribute those, then that would be immensely helpful for the...

If the adapter is installed and you use it to serve the resource metrics API, then you don't need metrics-server in your cluster.

They're not in conflict. If you are running Prometheus and are collecting container level metrics, then it's unnecessary to run metrics-server as well as it would collect the exact same...

Thanks for the feedback, it's highly appreciated! It's not at all taken as a rant, I find it very constructive. If people experience issues with the prometheus adapter then we'd...

metric-server is just _an_ implementation of the API, it doesn't make it any more official that any of the other ones, in fact the only reason why the prometheus adapter...