Using Prometheus for Multi-cluster Monitoring

Application Scenarios

Generally, a user has different clusters for different purposes, such as production, testing, and development. To monitor, collect, and view metrics of these clusters, you can deploy a set of Prometheus.

Solution Architecture

Multiple clusters are connected to the same Prometheus monitoring system, as shown in the following figure. This reduces maintenance and resource costs and facilitates monitoring information aggregation.

Prerequisites

The target cluster has been created.
Prometheus has been properly connected to the target cluster.
Prometheus has been installed on a Linux host using a binary file. For details, see Installation.

Procedure

Obtain the bearer_token information of the target cluster.
1. Create the RBAC permission in the target cluster.
  Log in to the background node of the target cluster and create the prometheus_rbac.yaml file.
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus-test
  namespace: kube-system

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-test
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - services
  - endpoints
  - pods
  - nodes/proxy
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - "extensions"
  resources:
    - ingresses
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - configmaps
  - nodes/metrics
  verbs:
  - get
- nonResourceURLs:
  - /metrics
  verbs:
  - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-test
subjects:
- kind: ServiceAccount
  name: prometheus-test
  namespace: kube-system
```
  Run the following command to create the RBAC permission:
  
  kubectl apply -f prometheus_rbac.yaml
2. Obtain the bearer_token information of the target cluster.
  - In clusters earlier than v1.21, a token is obtained by mounting the secret of the service account to a pod. Tokens obtained this way are permanent. This approach is no longer recommended starting from version 1.21. Service accounts will stop auto creating secrets in clusters from version 1.25.
    In clusters of version 1.21 or later, you can use the TokenRequest API to obtain the token and use the projected volume to mount the token to the pod. Such tokens are valid for a fixed period. When the mounting pod is deleted, the token automatically becomes invalid.
  - If you need a token that never expires, you can also manually manage secrets for service accounts. Although a permanent service account token can be manually created, you are advised to use a short-lived token by calling the TokenRequest API for higher security.
  Obtain the serviceaccount information.
  
  kubectl describe sa prometheus-test -n kube-system
  
  kubectl describe secret prometheus-test-token-hdhkg -n kube-system
  
  Record the token value, which is the bearer_token information to be collected.
Configure bearer_token information.

Log in to the host where Prometheus is located, go to the Prometheus installation directory, and save the token information of the target cluster in a file.

Configure a Prometheus monitoring job.

The example job monitors container metrics. To monitor other metrics, you can add jobs and compile capture rules.

  - job_name: k8s_cAdvisor
    scheme: https
    bearer_token_file: k8s_token # Token file in the previous step.
    tls_config:
      insecure_skip_verify: true
    kubernetes_sd_configs:  # kubernetes automatic discovery configuration
    - role: node    # Automatic discovery of the node type
      bearer_token_file: k8s_token # Token file in the previous step
      api_server: https://192.168.0.153:5443  # API server address of the Kubernetes cluster
      tls_config:
        insecure_skip_verify: true   # Skip the authentication on the server.
    relabel_configs:  ## Modify the existing label of the target cluster before capturing metrics.
    - target_label: __address__
      replacement: 192.168.0.153:5443
      action: replace
      ## Convert metrics_path to /api/v1/nodes/${1}/proxy/metrics/cadvisor.
      # Obtain data from kubelet using the API server proxy.
    - source_labels: [__meta_kubernetes_node_name]   # Specifies the source label to be processed.
      regex: (.+)    # Matched value of the source label. (.+) indicates that any value of the source label can be matched.
      target_label: __metrics_path__     # Specifies the label to be replaced.
      replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor  # Indicates the new label, that is, the value of __metrics_path__. ${1} indicates the value that matches the regular expression, that is, node name.
    - target_label: cluster
      replacement: xxxxx   ## (Optional) Enter the cluster information.

### The following job monitors another cluster.
  - job_name: k8s02_cAdvisor
    scheme: https
    bearer_token_file: k8s02_token # Token file in the previous step
    tls_config:
      insecure_skip_verify: true
    kubernetes_sd_configs: 
    - role: node    
      bearer_token_file: k8s02_token # Token file in the previous step
      api_server: https://192.168.0.147:5443  # API server address of the Kubernetes cluster
      tls_config:
        insecure_skip_verify: true   # Skip the authentication on the server.
    relabel_configs:  ## Modify the existing label of the target cluster before capturing metrics.
    - target_label: __address__
      replacement: 192.168.0.147:5443
      action: replace

    - source_labels: [__meta_kubernetes_node_name]
      regex: (.+)
      target_label: __metrics_path__
      replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor

    - target_label: cluster
      replacement: xxxx    ## (Optional) Enter the cluster information.

Enable Prometheus.

After the configuration, enable Prometheus.

./prometheus --config.file=prometheus.yml
Log in to Prometheus and view the monitoring information.