Kubernetes 1.15.2监控(2)Monitor集群组件和PODS

在上一篇文章中,我们已经在 k8s 中安装了 Prometheus,并且收集了它自身的监控指标。而在这篇文章,我们将收集 k8s 所有组件和 pod 的监控指标。

在这之前需要先修改下之前监控 Prometheus 自身使用的一个配置,因为它来源于 prometheus-operator,更多的是我对它使用这个配置的理解。而我们自己直接使用的话,没有必要搞这么麻烦,下面是修改后的内容。

- job_name: prometheus
  honor_labels: false
  kubernetes_sd_configs:
    - role: endpoints
      namespaces:
        names:
          - monitoring
  scrape_interval: 30s
  relabel_configs:
    - action: keep
      source_labels:
        - __meta_kubernetes_service_label_prometheus
      regex: k8s
    - source_labels:
        - __meta_kubernetes_namespace
      target_label: namespace
    - source_labels:
        - __meta_kubernetes_service_name
      target_label: service
    - source_labels:
        - __meta_kubernetes_pod_name
      target_label: pod
    - target_label: endpoint
      replacement: web
复制代码

这一看就懂,我也就不多做解释了。下面我们开始进入正题,首先监控 etcd。

监控 etcd

之前我们通过 curl 命令访问到了 etcd 监控指标所在的 URL,知道了它的监控指标有哪些,现在我们要配置 Prometheus,让其收集这些监控数据。

之前也提到过,k8s 中 Prometheus 的监控是通过发现 endpoint 的方式进行,而 endpoint 又是 service 创建的,所以我们需要先创建一个 etcd 的 service。

我们新建一个名为 kube-etcd-service.yml 的文件,内容如下:

说明:

  • 由于 etcd 处于 kube-system 名称空间,所以这里的 namespace 也应该是 kube-system;

  • 因为 etcd pod 本身会存在 component=etcd 这个标签,所以这里的选择器使用的就是这个。

创建成功后,可以通过如下命令查看它创建的 endpoint:

现在通过这个 endpoint 就能够访问到后面三台 etcd,现在只需要在 Prometheus 中添加对应的配置即可,配置内容如下。

因为访问 etcd 需要验证客户端证书,所以这里需要提供证书和私钥文件。这三个文件之前都已挂载到 Prometheus 容器中,直接拿来用就行。

下面的 relabel_configs 就不多提了,和前面监控 Prometheus 自身的配置差不多,最主要的还是 metric_relabel_configs,它是用来删除我们不需要的监控指标的。

这里将以 etcd_debugging|etcd_disk|etcd_request|etcd_server|grpc_server 这些开头的监控指标都删掉了,你们不要学我,最好搞清楚它的作用来决定是不是将其删掉,我纯粹是看不懂所以才删的。

最后将上面的内容粘贴进 prometheus-config.yml。当你 apply 配置文件后,不要急着 reload,因为 Prometheus 中可能没有立即更新,你可以通过 kubectl exec -it 连接到 Prometheus 的 pod 中验证下配置文件是否已经更新。

如果更新了,就直接通过下面命令让其 reload:

然后访问 Prometheus 的 web 页面,就可以在 targets 中看到 etcd 了。

监控 apiserver

apiserver 的监控方式更简单,因为它的 service 已经自动创建了。但你需要注意的是,它的 service 创建在 default 名称空间,名为 kubernetes

没什么好说的,直接放出 Prometheus 监控 apiserver 的配置。

这里因为 insecure_skip_verify 设为了 false,也就是校验服务端证书,所以这里提供了 ca 文件和 server_name。同样,这个证书事先已经挂载到了容器中,所以直接指定就行。

因为我不想关注的指标太多,所以删了一批。先声明,我是瞎删的,并不懂它们的确切意义,只是觉得没啥用,所以就删了,你们别学我!

最后你看着 reload 吧。

监控 pod

pod 的监控指标是 kubelet 提供的,前面也已经使用 curl 命令看到了,因此这里也是直接干。

我不知道是我之前手动创建的还是怎样,我这里已经存在了 kubelet 的 service,并且 service 只暴露了 10250 这一个端口,但是在其对应的 endpoint 上,却有以下三个端口。

如果你们不是这种情况,那就自己创建一个 service。如果也是这种情况,那在 relabel_configs 中,不仅要对 service 标签进行过滤,还得对端口进行过滤,因为我们只需要 10250 端口。

它的配置如下:

上面通过下面这个配置从三个端口中筛选出我们所需要的 10250 端口,因为它的名称为 https-metrics:

后面的 metric_relabel_configs 中,除了删除了一些我认为没用的监控指标外,还删除了所有 container 标签为空的监控指标,就像这些:

实在不知道这些是干啥的,而且数量非常多,干脆直接删掉。同时还删除了一些标签,比如下面这种的:

可以看到 id、name 和 image 这些标签的值非常长,不好看不说,还浪费内存和存储资源,我就都删了。它貌似会造成一个 pod 中如果有多个容器,你可能无法知道这个容器是监控指标中是哪一个,因为 image 这个标签被删了。

反正我删了,你看着办。删除之后就是这样:

当然很多标签是我们自己创建,如果你不需要,可以在上面的 relabel_configs 中删除对应标签的配置。或许你还想删其他的标签,那你往上面的配置中加就行。

最后记得 reload。

安装 kube-state-metrics

k8s 的其他组件我就不继续监控了,包括 kubelet、controller manager、coredns 等,它们监控的手段和之前的几个组件都差不多,相信你们自己弄起来也是轻轻松松。

下面我们会安装 kube-state-metrics,这个东西会连接 apiserver,然后将集群里的各种资源的指标都暴露出来,比如 configMap、ingress、secret、pod、deployment、statefulset 等,这是对 pod 指标的一大补充,非常有用。

RBAC 权限

因为它要访问集群内的所有资源,才能将它们的信息提供出去,因此部署它之前,先为它创建一些权限。这些权限都会绑定到一个 serviceAccount 上,然后我们用这个 sa 运行 kube-state-metrics 就行。

kube-state-metrics-clusterRole.yml:

kube-state-metrics-clusterRoleBinding.yml:

kube-state-metrics-role.yml:

kube-state-metrics-roleBinding.yml:

kube-state-metrics-serviceAccount.yml:

deployment 和 service

kube-state-metrics 会提供两个指标页面,一个是暴露集群内资源的,另一个是它自身的,它自身的可以选择性的关注。

先创建 kube-state-metrics-deployment.yml:

指定了两个启动参数,也就是两个端口,其中 10000 是暴露集群资源指标的端口,10001 就是它自身了。除了 kube-state-metrics 之外,还启动了 addon-resizer 这个容器,我不知道它是干啥的,反正官方怎么搞我们怎么弄就是了。

最后是 service 文件 kube-state-metrics-service.yml:

两个端口都暴露出来,你可以都收集或者只收集 10000 端口。如果只收集 10000,你可以只暴露一个端口,也可以两个都暴露,然后在 Prometheus 配置中过滤掉一个端口即可。

收集监控数据

将上面所有的文件都 apply 之后,就可以直接配置 Prometheus 进行收集了。在此之前,你可以使用 curl 命令访问它的指标页面,看看里面都有啥:

这个 ip 地址不用我说怎么拿吧,然后你就可以看到集群资源的指标非常非常非常的多,我觉得你最好对其进行过滤,将不需要的统统拒绝掉,不然对 Prometheus 造成的压力很大。

然后下面就是 Prometheus 的配置:

配置的内容就无需我多提了,和前面监控的配置都差不多。

主要是这里删除了一大批我不关注的指标,注意我这里做的是白名单,只收集我指定的,因为不需要的实在太多,写不过来。虽然正则表达式这么长,但是由于指标名称短,且 regex 默认锚定了行首和行尾,所以匹配效率还是很高的。

最后记得 reload。

ok,本文到此为止,下一篇会提到如何使用 grafana 和 alertmanager,谢谢!

Last updated

Was this helpful?