Prometheus监控多个集群

应用场景

通常情况下，用户的集群数量不止一个，例如生产集群、测试集群、开发集群等。如果在每个集群安装Prometheus监控集群里的业务各项指标的话，很大程度上提高了维护成本和资源成本，同时数据也不方便汇聚到一块查看，这时候可以通过部署一套Prometheus，对接监控多个集群的指标信息。

方案架构

将多个集群对接到同一个Prometheus监控系统，如下所示，节约维护成本和资源成本，且方便汇聚监控信息。

前提条件

目标集群已创建。
Prometheus与目标集群之间网络保持连通。
已在一台Linux主机中使用二进制文件安装Prometheus，详情请参见Installation。

操作步骤

分别获取目标集群的bearer_token 信息。
1. 在目标集群创建rbac权限。
  登录到目标集群后台节点，创建prometheus_rbac.yaml文件。
```
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
```
  执行以下命令创建rbac权限。
  
  kubectl apply -f prometheus_rbac.yaml
2. 获取目标集群bearer_token信息。
  - 1.21以前版本的集群中，Pod中获取Token的形式是通过挂载ServiceAccount的Secret来获取Token，这种方式获得的Token是永久的。该方式在1.21及以上的版本中不再推荐使用，并且根据社区版本迭代策略，在1.25及以上版本的集群中，ServiceAccount将不会自动创建对应的Secret。
    1.21及以上版本的集群中，直接使用TokenRequest API获得Token，并使用投射卷（Projected Volume）挂载到Pod中。使用这种方法获得的Token具有固定的生命周期，并且当挂载的Pod被删除时这些Token将自动失效。
  - 如果您在业务中需要一个永不过期的Token，您也可以选择手动管理ServiceAccount的Secret。尽管存在手动创建永久ServiceAccount Token的机制，但还是推荐使用TokenRequest的方式使用短期的Token，以提高安全性。
  首先获取serviceaccount信息。
  
  kubectl describe sa prometheus-test -n kube-system
  
  kubectl describe secret prometheus-test-token-hdhkg -n kube-system
  
  记录下这个token值，就是要搜集的bearer_token信息。
配置bearer_token 信息。

登录到Prometheus所在机器，进入Prometheus的安装目录，将目标集群的token信息保存在文件中。

配置Prometheus监控job。

示例job监控的是容器指标。如果需要监控其他指标，可自行添加job编写抓取规则。

  - job_name: k8s_cAdvisor
    scheme: https
    bearer_token_file: k8s_token #上一步中的token文件
    tls_config:
      insecure_skip_verify: true
    kubernetes_sd_configs:  #kubernetes 自动发现配置
    - role: node    #node类型的自动发现
      bearer_token_file: k8s_token #上一步中的token文件
      api_server: https://192.168.0.153:5443  #K8s集群 apiserver地址
      tls_config:
        insecure_skip_verify: true   #跳过对服务端的认证
    relabel_configs:  ##用于在抓取metrics之前修改target的已有标签
    - target_label: __address__
      replacement: 192.168.0.153:5443
      action: replace
      ##将metrics_path地址转换为/api/v1/nodes/${1}/proxy/metrics/cadvisor
      #相当于通过APIServer代理到kubelet上获取数据
    - source_labels: [__meta_kubernetes_node_name]   #指定需要处理的源标签
      regex: (.+)    #匹配源标签的值,(.+)表示源标签什么值都可以匹配上
      target_label: __metrics_path__     #指定了需要replace后的标签
      replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor  # 表示替换后的标签即__metrics_path__  对应的值。其中${1}表示正则匹配的值，即nodename
    - target_label: cluster
      replacement: xxxxx   ##根据实际情况填写 集群信息。也可不写

###下面这个job是监控另一个集群
  - job_name: k8s02_cAdvisor
    scheme: https
    bearer_token_file: k8s02_token #上一步中的token文件
    tls_config:
      insecure_skip_verify: true
    kubernetes_sd_configs: 
    - role: node    
      bearer_token_file: k8s02_token #上一步中的token文件
      api_server: https://192.168.0.147:5443  #K8s集群 apiserver地址
      tls_config:
        insecure_skip_verify: true   #跳过对服务端的认证
    relabel_configs:  ##用于在抓取metrics之前修改target的已有标签
    - 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    ##根据实际情况填写 集群信息。也可不写