k8s应该监控哪些指标及原因

Posted 运维开发故事

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了k8s应该监控哪些指标及原因相关的知识,希望对你有一定的参考价值。


Kubernetes 每天可以生成数百万个新指标。监控集群健康状况最具挑战性的方面之一是筛选哪些指标是重要的,需要收集和关注。 

在本文中,我将定义应该监控和创建警报的 16 个关键 Kubernetes 指标。公司组织的列表可能略有不同,但在制定组织的 Kubernetes 监控策略时,这 16 个是了解k8s集群监控状态最好的指标。

原文链接:https://www.circonus.com/2020/12/12-critical-kubernetes-health-conditions-you-need-to-monitor-and-why/

1Crash Loops

crash loops是指 pod 启动、崩溃,然后不断尝试重新启动但不能(它在循环中不断崩溃和重新启动)。当发生这种情况时,应用程序将无法运行。

  • 可能是由 pod 中的应用程序崩溃引起的
  • 可能是由 pod 或部署过程中的错误配置引起的
  • 当发生crash loops时,需要查看日志来解决问题。
  • 可以使用开源组件kube-eventer来推送事件。

2CPU Utilization

CPU 使用率就是节点正在使用的 CPU 的使用率。出于两个原因进行监控很重要:

  • 应用程序不能使用完应用程序分配的cpu。如果应用程序受 CPU 限制,则需要增加 CPU 分配或者增加pod数量。最终需要增加服务器来解决。
  • 你不希望你的 CPU 坐在那里闲置。如果服务器 CPU 使用率一直很低,可能过度分配了资源并可能浪费金钱。

3Disk Pressure

根据 Kubernetes 配置中设置的阈值,磁盘压力是指示节点使用过多磁盘空间或使用磁盘空间过快的条件。

  • 如果应用程序合法地需要更多空间,这可能意味着需要添加更多磁盘空间。
  • 应用程序行为异常并以意外的方式过早地填满了磁盘。

4Memory Pressure

Memory Pressure是另一种资源状况,表明节点内存不足。

  • 需要注意这种情况,因为这可能意味应用程序中存在内存泄漏。

5PID Pressure

PID 压力是一种罕见的情况,即 Pod 或容器产生过多进程并使节点缺乏可用进程 ID。

  • 每个节点都有有限数量的进程 ID 来分配给正在运行的进程;
  • 如果 ID 用完,则无法启动其他进程。
  • Kubernetes 允许为 pod 设置 PID 阈值以限制它们执行失控进程生成的能力,而 PID 压力条件意味着一个或多个 pod 正在用完分配的 PID,需要进行检查。

6Network Unavailable

所有节点都需要网络连接,Network Unavailable此状态表明节点的网络连接有问题。

  • 要么设置不正确(由于路由耗尽或配置错误),要么与硬件的网络连接存在物理问题。
  • 可以使用开源组件KubeNurse进行集群网络监控

7Job Failures

作业旨在在有限的时间内运行 Pod,并在完成预期功能后将其释放。

  • 如果作业因节点崩溃或重新启动或资源耗尽而未能成功完成,需要要知道作业失败。
  • 通常并不意味着您的应用程序无法访问,但如果不加以修复,它可能会导致以后会出现问题。
  • 可以使用开源组件kube-eventer来推送事件。

8Persistent Volume Failures

持久卷是在集群上指定的存储资源,可用作任何请求它的 Pod 的持久存储。在它们的生命周期中,它们被绑定到一个 Pod,然后在该 Pod 不再需要时回收。

  • 如果该回收因任何原因失败,需要知道的持久存储有问题。

9Pod Pending Delays

在 pod 的生命周期中,如果它正在等待在节点上进行调度,则其状态为“pending”。如果它停留在“pending”状态,通常意味着没有足够的资源来安排和部署 pod。

  • 将需要更新 CPU 和内存分配、删除 Pod 或向集群添加更多节点。
  • 可以使用开源组件kube-eventer来推送事件。

10Deployment Glitches

Deployment Glitches部署用于管理无状态应用程序——其中 Pod 是可互换的,不需要能够访问任何特定的单个 Pod,而只需访问特定类型的 Pod。

  • 需要密切关注部署以确保它们正确完成。最好的方法是确保观察到的部署数量与所需的部署数量相匹配。如果不匹配,则一个或多个部署失败。

11StatefulSets Not Ready

StatefulSets 用于管理有状态的应用程序,其中 Pod 具有特定的角色,需要访问其他特定的 Pod;而不是像部署那样只需要特定类型的 pod。

  • 确保观察到的 StatefulSet 的数量与所需的 StatefulSet 的数量相匹配。如果不匹配,则一个或多个 StatefulSet 失败。
  • 可以使用开源组件kube-eventer来推送事件。

12DaemonSets Not Ready

DaemonSets 用于管理需要在集群中的所有节点上运行的服务或应用程序。每个节点上运行日志收集守护进程(filebeat)或监控服务,需要使用 DaemonSet。

  • 确保观察到的 DaemonSet 数量与所需的 DaemonSet 数量相匹配。如果不匹配,则一个或多个 DaemonSet 失败。
  • 可以使用开源组件kube-eventer来推送事件。

13etcd Leaders

etcd 集群应该总是有一个领导者(除了在改变领导者的过程中,这应该很少发生)。

  • etcd_server_has_leader,etcd中是否有leader。
  • leader的改变次数etcd_server_leader_changes_seen_total,则可能表明 etcd 集群中存在连接或资源问题。

14Scheduler Problems

调度器有两个方面值得关注。

  • 应该进行监控,scheduler_schedule_attempts_total{result:unschedulable}因为不可调度 Pod 的增加可能意味着您的集群存在资源问题。
  • 其次,应该使用上述延迟指标之一密切关注调度程序延迟。Pod 调度延迟的增加可能会导致其他问题,也可能表明集群中存在资源问题。

15Events

除了从 Kubernetes 集群收集数字指标之外,从集群收集和跟踪事件也很有用。集群事件能监控 pod 生命周期并观察重大的 pod 故障,并且观察从集群流出的事件速率可以是一个很好的早期预警指标。如果事件发生率突然或显着变化,则可能表明出现问题。

  • 可以使用开源组件kube-eventer来推送事件。

16Application Metrics

与我们上面检查的其他指标和事件不同,应用程序指标不是从 Kubernetes 本身发出的,而是从集群运行的工作负载发出的。从应用程序的角度来看,这种遥测可以是重要的任何内容:错误响应、请求延迟、处理时间等。关于如何收集应用程序指标有两种哲学。

  • 第一个(直到最近才被广泛采用)是指标应该从应用程序“推送”到收集端点。
  • 第二个指标收集理念(越来越广泛采用)是指标应该由收集代理从应用程序中“拉取”。这使得应用程序更容易编写,因为他们所要做的就是适当地发布他们的指标,但应用程序不必担心如何提取或抓取这些指标。这就是 OpenMetrics 的工作方式,也是收集 Kubernetes 集群指标的方式。当此技术与收集代理的服务发现相结合时,它创建了一种强大的方法,可以从集群应用程序中收集您需要的任何类型的指标。

总结:

与 Kubernetes 的大多数方面一样,监控 Kubernetes 运行状况可能是一个复杂且具有挑战性的过程。很容易不知所措。通过了解最需要关注的高价值的指标,至少可以开始制定一项策略,能够过滤掉集群产生的大量数据噪音,并更有信心解决最重要的问题,以确保良好的体验。


以上是关于k8s应该监控哪些指标及原因的主要内容,如果未能解决你的问题,请参考以下文章

zabbix ipmi监控硬件哪些指标

Prometheus 监控K8S Node监控

Prometheus监控K8S各项指标

使用 Always On 监控的主要指标

Kubernetes集群中要监控哪些组件?采集哪些指标?

K8S监控指标萌贝树母婴公司無坑骗