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

1. 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. For details, see Service Account Token Security Improvement.

      • 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.

2. 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.

   

3. 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.

4. Enable Prometheus.

   After the configuration, enable Prometheus.

   ./prometheus --config.file=prometheus.yml

5. Log in to Prometheus and view the monitoring information.