Skip to content
This repository has been archived by the owner on Nov 21, 2023. It is now read-only.

ServiceMonitor: wrong caFile path #66

Open
Obirah opened this issue Feb 2, 2022 · 4 comments
Open

ServiceMonitor: wrong caFile path #66

Obirah opened this issue Feb 2, 2022 · 4 comments

Comments

@Obirah
Copy link

Obirah commented Feb 2, 2022

The caFile in the ServiceMonitor for Prometheus needs to be updated.

Old value: /etc/prometheus/configmaps/serving-certs-ca-bundle/service-ca.crt

New value: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

With the old value, Prometheus will throw the following error error creating HTTP client: unable to load specified CA cert /etc/prometheus/configmaps/serving-certs-ca-bundle/service-ca.crt: open /etc/prometheus/configmaps/serving-certs-ca-bundle/service-ca.crt: no such file or directory

@raffaelespazzoli
Copy link
Contributor

thanks, which cluster are you running on (distribution and version)?

@Obirah
Copy link
Author

Obirah commented Feb 2, 2022

Amazon EKS (Kubernetes v1.21) and Prometheus v2.28.1.

@raffaelespazzoli
Copy link
Contributor

I see now. So you are deploying via helm on EKS. That service-ca.crt exists only in OpenShift. We don't test your scenario very well.
Does it work if you set it to /var/run/secrets/kubernetes.io/serviceaccount/ca.crt?
I would expect other things to be broken.
Also if you are starring to use this operator for the patch feature, I recommend using the new patch-operator (https://github.com/redhat-cop/patch-operator) . You would probably have the same issue there, but the new operator has more features.

@Obirah
Copy link
Author

Obirah commented Feb 3, 2022

Yes, it works with /var/run/secrets/kubernetes.io/serviceaccount/ca.crt. To be honest, so far I haven't experienced any big problems with the operator on EKS as we're doing pretty simple patching with it.

The only thing I had to workaround is that OpenShift has the Service annotation for its SSL certificate and I needed to create my own little piece of automation to compensate for that.

I'll take a look at the patch operator, thank you. However, it will take a bit to migrate our GitOps tooling to it.

Back to the original problem: wouldn't it make sense to leave your OpenShift value for the cert as sane default but simply make it overridable?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants