- 
                Notifications
    You must be signed in to change notification settings 
- Fork 1.4k
📖 document metrics scraping and enable metrics services via annotations #4247
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.
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | 
|---|---|---|
| @@ -0,0 +1,76 @@ | ||
| ## Metrics | ||
|  | ||
| By default, controller-runtime builds a global Prometheus registry and | ||
| publishes a collection of performance metrics for each controller. | ||
|  | ||
| ### Protecting the Metrics | ||
|  | ||
| These metrics are protected by [kube-auth-proxy](https://github.com/brancz/kube-rbac-proxy) | ||
| by default. | ||
|  | ||
| You will need to grant permissions to your Prometheus server so that it can | ||
| scrape the protected metrics. To achieve that, you can create a `ClusterRole` and a | ||
| `ClusterRoleBinding` to bind to the service account that your Prometheus server uses. | ||
|  | ||
| Create a manifest named `capi-metrics-reader-clusterrole.yaml` with the following content: | ||
|  | ||
| ```yaml | ||
| apiVersion: rbac.authorization.k8s.io/v1 | ||
| kind: ClusterRole | ||
| metadata: | ||
| name: capi-metrics-reader | ||
| rules: | ||
| - nonResourceURLs: ["/metrics"] | ||
| verbs: ["get"] | ||
| 
      Comment on lines
    
      +18
     to 
      +24
    
   There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We may as well add this to the infra components yaml and remove this step for the end user. Probably makes sense to leave out the cluster role binding as we don't know the namespace Prometheus may be deployed into. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's the reason i documented it this way There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @randomvariable so did I get it right that you suggest removing this YAML here and adding it to the infra component YAMLs of all providers? Maybe I'm missing something but in case we really want to add this to our deployments, it looks to me like we need this ClusterRole only once. But I'm really not sure if we should add this to our YAMLs so that it's deployed everywhere. Imho Prometheus and RBAC setups can vary and (as far as I'm aware) there was no recurring demand for this in Slack. I assume nobody is really missing this in our YAMLs at the moment. I have no strong opinion against adding the ClusteRole to our YAMLs, but if we do we should do it right and adding it to all infra providers seems redundant to me. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. | ||
| ``` | ||
|  | ||
| and apply the `ClusterRole` with | ||
|  | ||
| ```bash | ||
| kubectl apply -f capi-metrics-reader-clusterrole.yaml | ||
| ``` | ||
|  | ||
| You can run the following kubectl command to create a `ClusterRoleBinding` and grant access on the `/metrics` endpoint to your Prometheus instance (`<namespace>` must be the namespace where your Prometheus instance is running. `<service-account-name>` must be the service account name which is configured in your Prometheus instance). | ||
|  | ||
| ```bash | ||
| kubectl create clusterrolebinding capi-metrics-reader --clusterrole=capi-metrics-reader --serviceaccount=<namespace>:<service-account-name> | ||
| ``` | ||
|  | ||
| ### Scraping the Metrics with Prometheus | ||
|  | ||
| To scrape metrics, your Prometheus instance needs at least the following [`kubernetes_sd_config`](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config) section. | ||
|  | ||
|  | ||
| ```yaml | ||
| # This job is primarily used for Pods with multiple metrics port. | ||
| # Per port one service is created and scraped. | ||
| - job_name: 'kubernetes-service-endpoints' | ||
| tls_config: | ||
| # if service endpoints use their own CA (e.g. via cert-manager) which aren't | ||
| # signed by the cluster-internal CA we must skip the cert validation | ||
| insecure_skip_verify: true | ||
| bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token | ||
| kubernetes_sd_configs: | ||
| - role: endpoints | ||
| relabel_configs: | ||
| - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape] | ||
| action: keep | ||
| regex: true | ||
| - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme] | ||
| action: replace | ||
| target_label: __scheme__ | ||
| regex: (https?) | ||
| - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path] | ||
| action: replace | ||
| target_label: __metrics_path__ | ||
| regex: (.+) | ||
| - source_labels: [__address__, __meta_kubernetes_service_annotation_prometheus_io_port] | ||
| action: replace | ||
| target_label: __address__ | ||
| regex: ([^:]+)(?::\d+)?;(\d+) | ||
| replacement: $1:$2 | ||
| - action: labelmap | ||
| regex: __meta_kubernetes_service_label_(.+) | ||
| ``` | ||
|  | ||
| You are now able to check for metrics in your Prometheus instance. To verify, you could search with e.g. `{namespace="capi-system"}` to get all metrics from components running in the `capi-system` namespace. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should these changes also be applied in each infra provider?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. In
capothe annotation is already sethttps://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/master/config/rbac/auth_proxy_service.yaml#L4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will go through the other infra provider and add the missing annotation.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @CecileRobertMichon
just created three PRs for providers under
kubernetes-sigs-Org, because CLA already signed. Have to check the legal stuff on the remaining others first. Hope this doesn't block this PR ;-)Summary:
annotationalready exist:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what about Azure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
annotation was already there but was removed last year.
I created Issue #1222 to get in contact with Azure team.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Azure PR #1320 created and merged