为什么说prometheus是为云原生监控而生的，prometheus为k8s监控做的四大适配工作

头像
ning1875
    阅读 7 分钟
    English
    头图

    视频教程

    k8s教程说明

    prometheus全组件的教程

    go语言课程

    前言

    为什么prometheus是为云原生监控而生的

    • 想必你不止一次的地听说了prometheus是为云原生监控而生的，那你有没有想过这句话意味着什么呢？
    • 我们知道在云原生中使用容器和k8s环境作为基础运行环境

    • 一体化架构被拆分成众多分散的微服务，而微服务的变更和扩缩容是特别频繁的，也就导致采集的目标信息变化频繁。这就给时序监控系统提出了两个要求：

      • 需要采集运行在跨多个宿主机上的海量pod容器
      • 同时要及时感知到他们的变化
      • 同时要构建完整的k8s监控生态，能有
    • 其实说白了就是在云原生环境中监控变得更难了，更复杂了。所以需要一个在设计之初就适合云原生监控场景的系统，而prometheus就是这么设计的。

    prometheus到底做了哪些改进，能配得上k8 ?

    k8s中应该关注哪些指标

    我在下面的表格中简单列举了下我们在k8s需要关注的四大块指标：

    指标类型采集源应用举例发现类型grafana截图
    容器基础资源指标kubelet 内置cadvisor metrics接口查看容器cpu、mem利用率等k8s_sd node级别直接访问node_ipimage
    k8s资源指标kube-stats-metrics (简称ksm)具体可以看从容器监控kube-stats-metrics看k8s众多组件
    看pod状态如pod waiting状态的原因
    数个数如：查看node pod按namespace分布情况    		通过coredns访问域名image
    k8s服务组件指标服务组件 metrics接口查看apiserver 、scheduler、etc、coredns请求延迟等k8s_sd endpoint级别image
    部署在pod中业务埋点指标pod 的metrics接口依据业务指标场景k8s_sd pod级别，访问pod ip的metricspath

    适配1. sdk+指标自暴露+pull模型：构建k8s监控的整个生态

    • 在上面的列举的表格中我们看到在k8s需要关注的四大块指标
    • 其实我们可以简单地把k8s的使用者分为两种角色： k8s集群管理员和普通用户。每种角色关注的指标不相同

    自己采集岂不累死了？

    • 既然需求这么多，如果只是由监控系统自己采集，第一很累，第二构建不出这么完整的生态

    奥妙

    • prometheus是pull模型采集的，各个被监控的源只需要将自身指标暴露在本地http端口中，prometheus就可以访问接口来采集指标
    • prometheus在k8s中也是这样的，组件需要暴露自身指标，如我们在容器基础资源指标中提到的kubelet 内置cadvisor指标就是暴露在10250端口下的/metrics/cadvisor下。
    • prometheus通过 k8s服务发现这些指标源完成采集

    适配2. k8s服务发现

    举例

    • 一、endpoint级别的服务发现 ：举例 在采集apiserver、kube-controller-manager等
    kubernetes_sd_configs:
   role: endpoints

    • 二、node级别的服务发现 ：举例 在采集cadvisor和kubelet自身指标时
      kubernetes_sd_configs:
  - role: node

    • 三、node级别的服务发现 ：举例 在采集pod自打点指标时
      kubernetes_sd_configs:
  - role: pod
    follow_redirects: true

    解读：watch即时更新

    • 通过watch即时发现资源变化，就满足了我们一开始提出的云原生情况下监控的挑战之一，要及时感知到采集源的变化。
    • 同时在k8s大二层环境中，prometheus可以访问到发现出来的的 endpoint 、node、pod

    适配3. 采集鉴权：token & 证书

    k8s中很多接口都要鉴权，甚至还需要tls双向认证

    • 同时我们知道在k8s中很多接口都是带有访问鉴权的，比如我们直接访问k8s node上的kubelet的/metrics/cadvisor接口会返回未授权。如下面所示
    [root@Kubernetes-node01 logs]# curl -k https://localhost:10250/metrics/cadvisor
Unauthorized
    • prometheus在采集cadvisor指标时同样面临鉴权问题

    解决方法

    • 聪明的prometheus开发人员通过在采集中支持配置中相关token和证书来解决这个问题，如下面的配置代表有一个token文件，同时还有一个证书文件。
    bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecure_skip_verify: true
    • 我们在使用k8s时知道，k8s通过 service account,clusterrolebinding来解决token、证书挂载问题
    • prometheus也是利用了这一点，在创建prometheus容器是相关的service account,clusterrolebinding配置的示例如下：
    apiVersion: rbac.authorization.k8s.io/v1 # api的version
kind: ClusterRole # 类型
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources: # 资源
  - nodes
  - nodes/proxy
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"] 
- apiGroups:
  - extensions
  resources:
  - ingresses
  verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus # 自定义名字
  namespace: kube-system # 命名空间
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus
roleRef: # 选择需要绑定的Role
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects: # 对象
- kind: ServiceAccount
  name: prometheus
  namespace: kube-system
    • 我们在创建相关prometheus 的statsfulset时需要在prometheus yaml中需要配置对应的serviceAccountNameserviceAccountName: prometheus
    • 配置好之后Kubernetes会将对应的token和证书文件挂载到pod中。
    • 我们exec进入prometheus的pod中就可以查看到相关文件在/var/run/secrets/kubernetes.io/serviceaccount/，如下图所示：
    / # ls /var/run/secrets/kubernetes.io/serviceaccount/ -l
total 0
lrwxrwxrwx 1 root root 13 Jan 7 20:54 ca.crt -> ..data/ca.crt
lrwxrwxrwx 1 root root 16 Jan 7 20:54 namespace -> ..data/namespace
lrwxrwxrwx 1 root root 12 Jan 7 20:54 token -> ..data/token
/ # df -h |grep service
tmpfs 7.8G 12.0K 7.8G 0% /var/run/secrets/kubernetes.io/serviceaccount
/ # 

    • 在采集etcd时需要配置相关证书的secret

      kubectl create secret generic etcd-certs --from-file=/etc/kubernetes/pki/etcd/healthcheck-client.crt --from-file=/etc/kubernetes/pki/etcd/healthcheck-client.key --from-file=/etc/kubernetes/pki/etcd/ca.crt -n kube-system

    适配4. 强大的relabel能力 做标签截取、变换、静态分片

    prometheus relabel说明

    应用1： labelmap 在采集cadvisor指标时 对服务发现标签key名字截取

    • 在采集cadvisor时可以看到服务发现源给添加了很多__meta_kubernetes_node_label_开头的标签

    • 但是这些标签名字太长了，需要精简。我们使用如下的relabel配置
    relabel_configs:
- separator: ;
regex: __meta_kubernetes_node_label_(.+)
replacement: $1
action: labelmap
    • 以这个标签为例，__meta_kubernetes_node_label_kubernetes_io_os="linux"，上面的配置代表匹配_meta_kubernetes_node_label_开头的key，只保留后面的部分，所以在最终的标签看到的就是beta_kubernetes_io_os="linux"。
    • labelmap代表匹配到的标签赋值给目标标签

    应用2： replace 在采集pod自定义指标 对标签进行赋值

    • 我们在使用pod自定义指标时在pod yaml 的spec.template.metadata.annotations中需要定义三个以prometheus.io开头的配置，分布代表是否需要prometheus采集、metrics暴露的端口、metrics的http path信息，详细配置如下：

      spec:
selector:
  matchLabels:
    name: fluentd-elasticsearch
template:
  metadata:
    labels:
      name: fluentd-elasticsearch
    annotations:
      prometheus.io/scrape: 'true'
      prometheus.io/port: '9102'
      prometheus.io/path: 'metrics'

    • 在采集pod自定义指标时采用如下

      relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
  separator: ;
  regex: "true"
  replacement: $1
  action: keep
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
  separator: ;
  regex: (.+)
  target_label: __metrics_path__
  replacement: $1
  action: replace
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
  separator: ;
  regex: ([^:]+)(?::\d+)?;(\d+)
  target_label: __address__
  replacement: $1:$2
  action: replace
    • 意思是将__meta_kubernetes_pod_annotation_prometheus_io_path赋值给 __metrics_path__
    • 意思是将相关 __meta_kubernetes_pod_annotation_prometheus_io_port赋值给 __address__后面的端口

    应用2： keep 做过滤，在采集服务组件endpoint时

    • endpoint资源是暴露一个服务的ip地址和port的列表
    • 代表采用k8s服务发现 endpoint，endpoint会非常多，所以需要过滤apiserver的
    kubernetes_sd_configs:
- role: endpoints
    • 过滤手段为 标签 __meta_kubernetes_namespace匹配default并且 __meta_kubernetes_service_name 匹配kubernetes 并且 __meta_kubernetes_endpoint_port_name 匹配https，咋样呢 ： keep
    relabel_configs:
- source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
separator: ;
regex: default;kubernetes;https
replacement: $1
action: keep

    • k8s 会在default namespace中创建apiserver的 service

      $ kubectl get svc -A |grep  443
default         kubernetes                                     ClusterIP   10.96.0.1       <none>        443/TCP                  9d
    • 最后获取到的endpoint转换为采集路径为： https://masterip:6443/metrics

    prometheus为k8s监控做的适配工作

    适配名字说明举例
    各个组件metrics自暴露所有组件将自身指标暴露在各自的服务端口上，prometheus通过pull过来拉取指标apiserver:6443/metrics
    k8s服务发现通过watch即时发现资源变化 kubernetes_sd_configs:- role: node
    鉴权k8s的组件接口都是要鉴权的，所以k8s的采集器要支持配置鉴权支持配置token和tls证书
    标签relabel能力过滤服务发现标的labelmap去掉服务发现标签的长前缀
    replace做替换
    hashmod做静态分片
    kubernetesprometheus云原生
    ning1875
    167 声望67 粉丝

    k8s/prometheus/cicd运维开发专家，想进阶的dy搜 小乙运维杂货铺

    « 上一篇
    prometheus指南：采集k8s的原理和高可用存储实践
    下一篇 »
    thanos教程之不理解prometheus原理thanos怎样都学不好

    引用和评论

    推荐阅读
    头像
    k8s中的11运维开发方向是哪些 如果快速提升k8s开发能力

    ning1875赞 1阅读 446

    头像
    张晋涛：KubeCon China 2024 回顾

    张晋涛赞 2阅读 573评论 1

    头像
    保证Redis和数据库数据一致性的方法

    蓝易云赞 1阅读 220

    头像
    浅谈时序数据库内核：如何用单机扛住亿级数据写入

    泊浮目阅读 5k

    头像
    docker 使用--storage-opt参数约束容器文件系统大小

    李朝阳赞 2阅读 4.6k

    头像
    Kubenetes里pod和service绑定的实现方式

    注销阅读 4k

    头像
    通过一个实际例子理解Kubernetes里pod的自动scale - 水平自动伸缩

    注销阅读 3.6k

    0 条评论
    得票最新