您需要监控的 12 个关键 Kubernetes 健康状况

您需要监控的 12 个关键 Kubernetes 健康状况

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

应对这一挑战的最佳方法是首先了解几乎每个 Kubernetes 运营商都应该关注哪些高价值信号。 这也是我们的客户之一，美国职业棒球大联盟，采取的方法。 通过关注他们关心的核心、可操作的问题，最终过滤掉了大约 90% 的 Kubernetes 数据。

在本文中，我将定义您应该监控和创建警报的 12 个关键 Kubernetes 健康状况。 您组织的列表可能略有不同，但在制定组织的 Kubernetes 监控策略时，这 12 个是一个很好的起点。

Crash Loops（崩溃循环）

崩溃循环是指 pod 启动、崩溃，然后不断尝试重新启动但不能正常启动（它在循环中不断崩溃和重新启动）。 这显然很糟糕，因为当发生这种情况时，您的应用程序将无法运行。 这可能是由 pod 中的应用程序崩溃引起的，也可能是由 pod 或部署过程中的错误配置引起的，这使得调试崩溃循环相当棘手。 当崩溃循环发生时，您需要立即知道。这样您才能弄清楚发生了什么以及是否需要采取紧急措施来保持应用程序可用。

CPU Utilization（CPU 使用率）

CPU 利用率就是您的节点正在使用的 CPU 周期数。
进行监控的两个重要原因：
首先，您不想耗尽应用程序的处理资源。 如果您的应用程序受 CPU 限制，则需要增加 CPU 分配或向集群添加更多节点。
其次，你不希望你的 CPU 坐在那里闲置。 如果您的 CPU 使用率一直很低，则您可能过度分配了资源并可能浪费金钱。

Disk Pressure（磁盘压力）

根据您在 Kubernetes 配置中设置的阈值，磁盘压力是指示节点使用过多磁盘空间或使用磁盘空间过快的条件。 这对监控很重要，因为如果您的应用程序合法地需要更多空间，这可能意味着您需要添加更多磁盘空间。 或者这可能意味着应用程序行为异常并以意外的方式过早地填满了磁盘。 无论哪种方式，这是一个需要您注意的情况。

Memory Pressure（内存压力）

内存压力是另一种资源状况，表明您的节点内存不足。 与 CPU 资源分配类似，您不想耗尽内存——但也不想过度分配内存资源并浪费金钱。 您尤其需要注意这种情况，因为这可能意味着您的一个应用程序中存在内存泄漏。

赞助商须知
Circonus 提供了一个 Kubernetes 监控解决方案，让客户能够更好地了解其集群的运行状况和性能。 该解决方案专为 Kubernetes 打造，提供总控制仪表板和警报，使组织能够立即呈现清晰、可操作的见解，从而节省时间、降低成本并最大限度地提高 Kubernetes 部署的价值。 

PID Pressure（PID压力）

PID 压力是一种罕见的情况，即 Pod 或容器产生过多进程并使节点缺乏可用进程 ID。 每个节点都有有限数量的进程 ID 来分配给正在运行的进程； 如果 ID 用完，则无法启动其他进程。 Kubernetes 允许您为 pod 设置 PID 阈值以限制它们执行失控进程生成的能力，而 PID 压力条件意味着一个或多个 pod 正在用完分配的 PID，需要进行检查。

Network Unavailable（网络不可用）

你所有的节点都需要网络连接，这个状态表明节点的网络连接有问题。要么设置不正确（由于路由耗尽或配置错误），要么与硬件的网络连接存在物理问题。

Job Failures（作业失败）

作业旨在在有限的时间内运行 pod，并在它们完成预期功能后将其拆除。如果由于节点崩溃或重新启动，或者由于资源耗尽而导致作业未成功完成，您需要知道该作业失败了。这就是为什么您需要监控作业失败的原因——它们通常并不意味着您的应用程序无法访问，但如果不加以修复，可能会导致未来出现问题。

Persistent Volume Failures（持久卷故障）

持久卷是在集群上指定的存储资源，可用作任何请求它的 Pod 的持久存储。在它们的生命周期中，它们被绑定到一个 Pod，然后在该 Pod 不再需要时回收。如果该回收因任何原因失败，您需要知道您的持久存储有问题。

Pod Pending Delays（Pod 等待延迟）

在 pod 的生命周期中，如果它正在等待在节点上进行调度，则其状态为“pending”。如果它停留在“pending”状态，通常意味着没有足够的资源来安排和部署 pod。您将需要更新 CPU 和内存分配、删除 Pod 或向集群添加更多节点。

Deployment Glitches（部署故障）

部署用于管理无状态应用程序——其中 Pod 是可互换的，不需要能够访问任何特定的单个 Pod，而只需访问特定类型的 Pod。您需要密切关注您的部署以确保它们正确完成。最好的方法是确保观察到的部署数量与所需的部署数量相匹配。如果不匹配，则一个或多个部署失败。

StatefulSets Not Ready（StatefulSet 未就绪）

StatefulSets 用于管理有状态的应用程序，其中 Pod 具有特定的角色，需要访问其他特定的 Pod；而不是像部署那样只需要特定类型的 pod。但是，监控是相同的——您需要确保观察到的 StatefulSet 的数量与所需的 StatefulSet 的数量相匹配。如果不匹配，则一个或多个 StatefulSet 失败。

DaemonSets Not Ready（守护进程未准备好）

DaemonSets 用于管理需要在集群中的所有节点上运行的服务或应用程序。如果您想在每个节点上运行日志收集守护进程或监控服务，您将需要使用 DaemonSet。监控与部署相同：您需要确保观察到的 DaemonSet 数量与所需的 DaemonSet 数量相匹配。如果不匹配，则一个或多个 DaemonSet 失败。

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

参考文档：
[1]: https://thenewstack.io/12-critical-kubernetes-health-conditions-you-need-to-monitor/