Kubernetes 集群和应用监控方案的设计与实践

Kubernetes 监控

当你的应用部署到 Kubenetes 后,你很难看到容器内部发生了什么,一旦容器死掉,里面的数据可能就永远无法恢复,甚至无法查看日志以定位问题所在,何况一个应用可能存在很多个实例,用户的一个请求不指定被哪个容器处理了,这使得在 Kubernetes 中对应用进行故障排除较为复杂。在应用之外,由于 Kubernetes 作为基础设施,掌管这整个集群的生死,Kubernetes 的任何故障,必定影响到应用服务的运行,因此监控 Kubernetes 运行状况也至关重要。

当你的应用上了云原生,那你就不得不关注各个服务器的运行状态,基础设施和中间件的运行状态,Kubernetes 中每个组件和资源对象的运行状态,每个应用的运行状态。当然,这个运行状态是一个模糊的概念,取决于我们的关注点,每个被监控的对象要表达的 "运行状态" 是不一样的。为了可以监控我们关注的对象,对象需要做出一些配合,提供合适的运行状态的表达信息,以供我们收集和分析,这可以称为可观测性。

在云原生中,一般对可观测性分为三大作用域:

你可以在 Kubernetes 文档中了解如何监控、调试,以及了解如何对日志进行处理。

在本文中,所提到的监控,只包括 Metrics 。

Metrics、Tracing、Logging 不是完全独立的,在上图中,Metrics 也会可能包含 Logging 和 Tracing 的信息。

要采集的监控数据,来源于被监控对象,而在 Kubernetes 集群中,我们可以将要监控的对象分为三大部分:

在基础环境中,一个完整的监控应包括采集数据、存储数据、分析存储数据、展示数据、告警等多个部分,而每个部分都有相关的工具或技术解决云原生中环境的多样需求和复杂性问题。

既然要做监控,那么就需要监控工具。监控工具可以获取所有重要的指标和日志(Metrics也可以包含一些日志),并将它们存储在一个安全、集中的位置,以便可以随时访问它们来制定方案解决问题。由于在云原生中,应用在 Kubernetes 集群中部署,因此,监控 Kubernetes 可以让你深入了解集群的运行状况和性能指标、资源计数以及集群内部情况的顶级概览。发生错误时,监控工具会提醒你(告警功能),以便你快速推出修复程序。

Prometheus 是一个 CNCF 项目,可以原生监控 Kubernetes、节点和 Prometheus 本身,目前 Kubernetes 官方文档主要推荐使用 Prometheus 本身,它为 Kubernetes 容器编排平台提供开箱即用的监控能力。因此在本文中,对监控方案的设计是围绕 Prometheus 展开的。

下面是 Prometheus 的一些组件介绍:

Prometheus 在 Kubernetes 中的监控方案结构如下:

【图源:https://devopscube.com/setup-prometheus-monitoring-on-kubernetes/】

要监控的对象种类很多,我们把相同类型的对象称为一个实体,而每个实体运行时的对象产生的数据有各种各样的,为了归纳收集这些数据, Prometheus 将实体中的各种属性值分为 Counter (计数器)、Gauge (仪表盘)、Histogram(累积直方图)、Summary(摘要)四种类型,实体中的每个属性,称为指标,例如 容器已累计使用 CPU 量,使用指标名称 container_cpu_usage_seconds_total 记录。

每个指标一般格式为:

每个对象都在无时无刻产生数据,为了区分当前指标值属于哪个对象,可以给指标除了指

对象生成类似这种结构的文本后,可以暴露 metrics 端点,让 Prometheus 自动采集,或通过 Pushgateway 推送到 Prometheus 中。

接下来,我们将在 Kubernetes 中搭建一个完整的 Prometheus 监控体系。

实 践

▌节点监控

node exporter 是用 Golang 编写的,用于在 Linux 系统上,收集内核公开的所有硬件和操作系统级别的指标,包括 CPU 、信息、网卡流量、系统负载、socket 、机器配置等。

读者可参考中列举出的 https://github.com/prometheus/node_exporter 中列举出的所有默认开启或默认关闭的指标。

既然要监控集群中的每个节点,那么就要做到每个节点都运行这一个 node exporter 实例,并且在集群新增节点的时候自动调度一个 node exporter 到这个节点中运行,因此需要采用 node exporter 的部署需要 DaemontSet 模式。

查看集群中的所有节点:

root@master:~# kubectl get nodes
NAME     STATUS                     ROLES                  AGE     VERSION
master   Ready,SchedulingDisabled   control-plane,master   98d     v1.22.2
salve2   Ready                      <none>                 3h50m   v1.23.3
slave1   Ready                      <none>                 98d     v1.22.2

Bibin Wilson 大佬已经封装好了用于 Kubernetes 的 node exporter 的 YAML 文件,我们直接下载即可:

git clone https://github.com/bibinwilson/kubernetes-node-exporter

打开仓库中的 daemonset.yaml 文件,大概了解其中的信息。

在 YAML 文件中,可以看到 node exporter 会被部署到命名空间 monitoring 中运行,它有两个 label:

   labels:
     app.kubernetes.io/component: exporter
     app.kubernetes.io/name: node-exporter

为了 node exporter 能够被调度到 master 节点中运行,我们需要为 Pod 添加容忍度属性:

  template:
    metadata:
      labels:
        app.kubernetes.io/component: exporter
        app.kubernetes.io/name: node-exporter
    spec:
    # 复制下面这部分到对应的位置
      tolerations:
      - key: "node-role.kubernetes.io/master"
        operator: "Exists"
        effect: "NoSchedule"
      - key: "node.kubernetes.io/unschedulable"
        operator: "Exists"
        effect: "NoSchedule"

为了部署 node exporter ,我们先创建命名

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值