Open Obirah opened 2 years ago
thanks, which cluster are you running on (distribution and version)?
Amazon EKS (Kubernetes v1.21) and Prometheus v2.28.1.
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.
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?
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