Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Update collecting metrics page #62

Merged
merged 2 commits into from
Jan 17, 2024
Merged

Update collecting metrics page #62

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4f1bf66
Update the collecting metrics page about controller-runtime
simonpasquier Jan 9, 2024
592b0c8
Add details about the client certificate used by Prometheus
simonpasquier Jan 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 9 additions & 3 deletions content/Products/OpenshiftMonitoring/collecting_metrics.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,8 @@ As described in the [Client certificate scraping](https://github.com/openshift/e

To this goal, the Cluster monitoring operator provisions a TLS client certificate for the in-cluster Prometheus. The client certificate is issued for the `system:serviceaccount:openshift-monitoring:prometheus-k8s` Common Name (CN) and signed by the `kubernetes.io/kube-apiserver-client` [signer](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers). The certificate can be verified using the certificate authority (CA) bundle located at the `client-ca-file` key of the `kube-system/extension-apiserver-authentication` ConfigMap.

> In practice the Cluster Monitoring Operator creates a CertificateSigningRequest object for the `prometheus-k8s` service account which is automatically approved by the cluster-policy-controller. Once the certificate is issued by the controller, CMO provisions a secret named `metrics-client-certs` which contains the TLS certificate and key (respectively under `tls.crt` and `tls.key` keys in the secret). CMO also rotates the certificate before it gets expired.

There are several options available depending on which framework your component is built.

### library-go
Expand Down Expand Up @@ -113,11 +115,15 @@ type: Opaque

Example: [node-exporter](https://github.com/openshift/cluster-monitoring-operator/blob/e51a06ffdb974003d4024ade3545f5e5e6efe157/assets/node-exporter/daemonset.yaml#L65-L98) from the Cluster Monitoring operator.

### Roll your own HTTPS server
### controller-runtime (>= v0.16.0)

Starting with v0.16.0, the `controller-runtime` framework provides a way to expose and secure a `/metrics` endpoint using TLS with minimal effort.

> You don't use `library-go` or don't want to run a `kube-rbac-proxy` sidecar.
Refer to https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/metrics/server for details about TLS configuration and check the next section to understand how it needs to be configured.

### Roll your own HTTPS server

For instance if your component is built on top of `sigs.k8s.io/controller-runtime`, the library doesn't provide any facility to configure the HTTP authn/authz as of today and it's not even possible to configure TLS (refer to https://github.com/kubernetes-sigs/controller-runtime/issues/2073 for more details). Another case might be that your component isn't an operator.
> You don't use `library-go`, `controller-runtime` >= v0.16.0 or don't want to run a `kube-rbac-proxy` sidecar.

In such situations, you need to implement your own HTTPS server for `/metrics`. As explained before, it needs to require and verify the TLS client certificate using the root CA stored under the `client-ca-file` key of the `kube-system/extension-apiserver-authentication` ConfigMap.

Expand Down
Loading