【DevOps实战之k8s】使用Prometheus和Grafana监控K8S集群

2019-09-10T13:11:33+08:00 | 10分钟阅读 | 更新于 2019-09-10T13:11:33+08:00

Macro Zhao

【DevOps实战之k8s】使用Prometheus和Grafana监控K8S集群

@TOC

推荐超级课程：

随着现代应用程序复杂性的增加，建立可靠高效的监控系统对于确保Kubernetes集群的平稳运行至关重要。Prometheus是一款功能强大的开源监控工具，被广泛用于监控Kubernetes集群。

在本博客文章中，我们将探讨如何使用Prometheus监控Kubernetes集群（控制平面和工作节点）。我们将介绍应该监控的关键指标，并提供如何使用这些指标和PromQL查询进行监控的示例。

要全面监控Kubernetes集群，不仅需要收集应用程序级别的指标，还需要收集与Kubernetes基础架构相关的指标。这包括与Kubernetes服务、节点和编排状态相关的指标。为此，我们使用：

Node Exporter用于收集传统的主机相关指标，如CPU、内存和网络使用情况，
使用Kube-state-metrics工具收集编排和集群级别的指标，例如关于部署、Pod指标和资源预留的信息，
收集Kubernetes控制平面指标，包括kubelet、etcd、dns、调度器等，以监控Kubernetes基础设施的健康和性能。

系统架构

以下图示了使用Kube-state-metrics、Node-exporter和Kubernetes控制平面指标收集Kubernetes指标的系统架构。

Kubernetes集群指标

Kube-state-metrics是一个监听Kubernetes API服务器并生成与对象状态（如部署、节点和Pod）相关指标的服务。值得注意的是，Kube-state-metrics仅提供指标端点，需要另一个实体进行抓取并提供长期存储，例如Prometheus服务器。 kube-state-metrics暴露的指标在文档中可查看。Node-exporter是一个用于硬件和操作系统指标的Prometheus导出工具，当我们使用Prometheus操作时会自动部署。它允许测量各种机器资源，如内存、磁盘和CPU利用率。它可以部署为一个DaemonSet，因此在添加或删除集群中的节点时会自动扩展。此外，我们使用Kubernetes控制平面指标来监控控制平面。每个控制平面组件（APIServer、kublet、etcd、kube-dns、kube-proxy）都被仪器化并暴露/metrics端点，可以被Prometheus抓取。

抓取指标

所提出的架构通过利用Kube-state-metrics、Node-exporter和Kubernetes控制平面指标使Prometheus能够收集Kubernetes指标。Prometheus利用HTTP Pull模型，通过在预定间隔内从服务中拉取度量数据而不是服务推送数据到它。在每次抓取中，Prometheus从所有端点检索度量数据并将其存储在本地时间序列数据库中。抓取过程高度可定制，允许用户调整参数，如抓取间隔和超时，以满足系统的要求。

可视化

Prometheus收集Kubernetes指标数据后，可以使用Grafana仪表板对数据进行可视化。Grafana是一款流行的开源数据可视化工具，允许用户为时间序列数据创建自定义仪表板和图表。通过Grafana，我们可以创建和共享显示实时监控数据的复杂可视化仪表板。

要开始使用Grafana，首先需要配置数据源与Prometheus服务器连接。建立连接后，可以开始构建自定义仪表板和面板来展示Kubernetes指标数据。借助Grafana强大的查询语言，可以对收集的指标数据应用各种统计和数学函数，以提取有意义的查询。

Grafana还支持基于指标数据的警报，可以用于触发通知并在阈值突破时采取适当的行动。可以基于Kubernetes指标数据设置各种警报规则，并配置Grafana通过电子邮件、Slack或PagerDuty等渠道发送通知。

警告

基于指标数据的警报是监控任何系统的重要方面。在使用Prometheus监控Kubernetes集群的情况下，可以使用Prometheus Alertmanager创建和管理基于收集的指标数据的警报。Alertmanager允许用户使用PromQL表达式定义警报规则，并配置不同的通知渠道，如电子邮件、Slack、PagerDuty等在触发警报时接收通知。

例如，如果Prometheus指标数据显示某个Pod处于停机状态或某个节点无法访问，可以配置警报并发送通知到指定渠道。Alertmanager还允许用户为某些警报配置静音时间或在维护期间抑制警报。这有助于减少警报疲劳，并确保触发的警报是有意义的，并需要注意。

通过Alertmanager还可以配置警报级联和分组，使用户可以对类似的警报进行分组和统一管理。这样可以更容易地管理和响应同一时间触发的多个警报。

PromQL示例

一旦按照上述架构设置系统，Prometheus将自动抓取Kubernetes指标。然后可以使用PromQL来分析Kubernetes集群的指标。Prometheus提供了一种灵活且强大的查询语言，称为PromQL，可用于查询和分析收集的指标。该语言使得过滤和聚合指标、计算速率和比率以及在数据上执行复杂操作变得简单。以下是一些使用PromQL查询来监控Kubernetes集群的示例。

按命名空间统计集群中的Pod数

kube_pod_info指标提供每个Pod的信息，包括其命名空间、名称、IP地址和状态。查询中的sum by (namespace)部分将Pod按其命名空间分组，并将每个命名空间中的Pod总数相加。生成的输出将显示集群中每个命名空间中运行的Pod数量的细分。

sum by (namespace) (kube_pod_info)

按命名空间重启Pod

此PromQL查询计算了在过去5分钟内Kubernetes Pod准备状态的变化总和，按命名空间分组。它选择显示kube_pod_status_ready指标的“true”条件，该条件表示Pod准备好提供请求服务。 “changes”函数返回了在指定时间范围内此条件已更改的次数（从false更改为true或反之），并sum by（namespace）子句按Pod所在的命名空间对结果进行分组。换句话说，此查询可用于通过计算在过去5分钟内准备状态变化的次数来监控每个命名空间中Pod的稳定性和可用性。

sum by (namespace)(changes(kube_pod_status_ready{condition="true"}[5m]))

未就绪的Pod

此查询将汇总每个命名空间中处于未就绪状态的Pod的数量。此查询特别查找Pod的准备条件，并过滤出任何具有false条件的Pod。sum by子句用于按命名空间对结果进行分组，提供每个命名空间中不就绪Pod的数量细分。此查询有助于识别与Pod就绪性相关的特定于命名空间的问题，比如某个命名空间与其他命名空间相比正在遇到更多失败或不健康的Pod的数量。

sum by (namespace) (kube_pod_status_ready{condition="false"})

CPU过度使用

此PromQL查询计算了在群集中使用的Kubernetes Pod总CPU资源量减去群集中节点的总CPU容量。查询的sum(kube_pod_container_resource_limits{resource="cpu"})部分计算了群集中所有Pod的CPU限制总和，而查询的sum(kube_node_status_capacity_cpu_cores)部分计算了群集中所有节点的CPU容量总和。通过减去这两个值，查询返回了群集中剩余的可用CPU容量。此查询可用于识别群集中是否存在不足的CPU资源，并计划扩展群集或优化Pod资源分配。

sum(kube_pod_container_resource_limits{resource="cpu"}) - sum(kube_node_status_capacity_cpu_cores)

Memory过度使用

此PromQL查询计算了群集中Kubernetes Pod请求的内存总量，减去工作节点上可用内存总量。它通过对群集中所有Pod的内存资源类型的kube_pod_container_resource_limits指标求和，然后减去kube_node_status_capacity_memory_bytes指标的总和来实现此目的，后者报告了每个节点上可用内存的总量。

此查询可用于识别Pod请求的内存超过了它们被调度到的节点上可用内存的情况，这可能导致性能问题甚至Pod失败。如果此查询的结果持续为负值，则可能表明需要额外的节点或节点资源来支持当前的工作负载。

sum(kube_pod_container_resource_limits{resource="memory"}) - sum(kube_node_status_capacity_memory_bytes)

健康的集群节点数量

此PromQL查询用于计算Kubernetes集群中目前准备就绪的节点数量。它通过在kube_node_status_condition指标中设置Ready条件为true的节点总数。使用“status”标签来过滤为true的节点。查询末尾的==1用于确保仅计算具有完全匹配条件的节点。通过运行此查询，您可以轻松确定集群中已准备好且可供使用的节点数量。

sum(kube_node_status_condition{condition="Ready", status="true"}==1)

可能无法正常工作的集群节点数量

此PromQL查询用于检查在指定时间段内是否有任何Kubernetes节点无响应。它使用changes函数计算了在过去15分钟内节点Ready条件变为true的次数，然后使用by（node）子句按节点对结果进行分组。最后，使用> 2比较检查变化的次数是否大于2。如果此查询的结果对于任何节点都大于2，则表示该节点在过去15分钟内无响应，从而触发将警报发送到Alertmanager。

sum(changes(kube_node_status_condition{status="true",condition="Ready"}[15m])) by (node) > 2

按集群监视CPU空闲

此PromQL查询用于监视运行在Kubernetes Pod中的容器的CPU使用情况。查询首先获取除了容器名称为“POD”或为空名称之外的所有容器在过去30分钟内的CPU使用总秒数，使用container_cpu_usage_seconds_total指标。然后按命名空间、Pod和容器对结果进行分组。

接下来，查询使用kube_pod_container_resource_requests指标计算容器的平均CPU资源请求，并对“cpu”资源的请求进行过滤。group_left关键字确保即使在第二个查询中没有匹配数据，查询也会保留来自前一个查询的所有数据。

最后，两个结果被减去并乘以-1以获取CPU使用和CPU请求的差值。查询末尾的>0检查结果是否大于0，这意味着容器超过了其请求的CPU限制。这些值的总和将给出超出其请求的CPU限制的容器的总数。

sum((rate(container_cpu_usage_seconds_total{container!="POD",container!=""}[30m]) - on (namespace,pod,container) group_left avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="cpu"})) * -1 >0)

按集群监视内存空闲

查询从汇总所有Pod的内存使用指标开始。（container_memory_usage_bytes{container!="POD",container!=""}选择所有容器的内存使用，除了名称为“POD”或为空的容器。查询的下一部分使用on将内存使用数据按命名空间、Pod和容器分组。然后，它使用avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="memory"})计算每个组中每个容器请求的平均内存。然后，它将平均内存请求数减去实际内存使用并乘以-1。这将给出使用的内存量，超过容器请求的内存量。如果这个值大于0，这意味着容器使用的内存量超过了其请求的内存量。最后，查询将结果除以(1024*1024*1024)以将其转换为GB。

sum((container_memory_usage_bytes{container!="POD",container!=""} - on (namespace,pod,container) avg by (namespace,pod,container)(kube_pod_container_resource_requests{resource="memory"})) * -1 >0 ) / (1024*1024*1024)

按集群和命名空间计算没有CPU限制的容器数量

此PromQL查询用于计算每个命名空间中没有设置CPU限制的Pod数量。它首先通过按命名空间、Pod和容器标签汇总kube_pod_container_info指标，以获取每个Pod中容器的总数。然后使用unless关键字从该计数中减去设置了CPU限制的容器数量，这通过按命名空间、Pod和容器标签汇总kube_pod_container_resource_limits指标并过滤资源为“cpu”来获得。最后，使用count by（namespace）函数计算每个命名空间中至少有一个容器未设置CPU限制的Pod的数量。

count by (namespace)(sum by (namespace,pod,container)(kube_pod_container_info{container!=""}) unless sum by (namespace,pod,container)(kube_pod_container_resource_limits{resource="cpu"}))

参考

上一页【DevOps实战之k8s】Prometheus Operator的服务发现Monitor：Pod Monitor, Service Monitor，Scrape Config

下一页【OpenStack】OpenStack实战之开篇