康指标。你所在的企业可能会略有不同，但是这12个是制定企业的Kubernetes监控策略的良好起点。
崩溃循环
崩溃循环是指Pod启动，崩溃然后继续尝试重新启动但无法恢复的时间(它不断崩溃并以循环方式重新启动)。发生这种情况时，应用程序无法运行。这可能是由于Pod中的应用程序崩溃导致
的，也可能是由于Pod中的配置错误或部署过程导致的，这使得调试崩溃循环变得非常棘手。当发生崩溃循环时，需要立即知道，弄清正在发生的事情以及是否需要采取紧急措施，保持应用程
序可用。
CPU利用率
CPU利用率只是节点使用的CPU周期数。进行监控非常重要，其原因有两个。首先，你不希望耗尽应用程序的处理资源。如果应用程序受到CPU的限制，则需要增加CPU分配或向集群添加更多节
点。其次，你不希望CPU闲置。如果CPU使用率一直很低，则可能是资源过度分配，有可能浪费支出。
磁盘压力
根据在Kubernetes配置中设置的阈值，磁盘压力是表明节点使用过多磁盘空间或使用磁盘空间的速度过快的情况。这对于监控非常重要，因为如果应用程序合法需要更多空间，则可能意味着
需要添加更多磁盘空间。否则可能意味着应用程序行为异常。无论哪种方式，这种情况都需要引起注意。
内存压力
内存压力是另一种资源状况，表明节点内存不足。类似于CPU资源配置，不想完全消耗内存资源，但也不想过度分配内存资源并浪费成本。那么需要注意这种情况，因为这可能意味着一个应用
程序中存在内存泄漏。
PID压力
PID压力是一种罕见的情况，在这种情况下，pod或容器会产生过多的进程，并使节点无法获得可用的进程ID。每个节点具有有限数量的进程ID，从而在运行中的进程之间分配;如果ID用完了
，则无法启动其他进程。Kubernetes允许为Pod设置PID阈值来限制其执行失控的流程生成的能力，并且PID压力条件意味着一个或多个Pod耗尽了其分配的PID，需要进行检查。
网络不可用
所有的节点都需要网络连接，并且其状态表示节点的网络连接有问题与否。要么没有正确设置(由于路由耗尽或配置错误)，要么是与硬件的网络连接存在物理问题。
Job失败
Job的目的是在有限的时间内运行pod，并在完成预期的功能时将其拆解。如果Job由于节点崩溃或重新引导或资源耗尽而未能成功完成，则需要知道该Job已失败。这就是为什么需要监控Job失
败的原因。它们通常并不意味着应用程序不可访问，但是如果未解决，则可能会导致问题。
持久卷故障
持久卷是在集群上指定的存储资源，可用作任何请求它的Pod的持久存储。在它们的生命周期中，它们绑定到一个容器，然后在该容器不再需要时回收。如果回收由于某种原因而失败，那么需
要知道持久性存储存在问题。
暂挂Pod的延迟时间
在pod的生命周期中，如果它正在等待在节点上进行调度，则其状态为“待处理”。如果卡在“挂起”状态，通常意味着没有足够的资源来安排和部署Pod。将需要更新CPU和内存分配，删除
pod或向集群添加更多节点。
Deployment故障
Deployment用于管理无状态应用程序-Pod是可互换的，不需要能够到达任何特定的单个Pod，而只需到达特定类型的Pod即可。需要密切注意部署以确保它们正确完成。最好的方法是确保观察
到的Deployment数量与所需的Deployment数量匹配。如果不匹配，则一个或多个Deployment失败。
StatefulSets尚未就绪
StatefulSets用于管理有状态的应用程序，其中的Pod具有特定的角色，需要到达其他特定的Pod。而不是像Deployment那样只需要特定类型的Pod。但是，监控是相同的，需要确保观察到的
StatefulSet的数量与所需的StatefulSet的数量匹配。如果存在不匹配，则一个或多个StatefulSet已失败。
DaemonSets未准备好
DaemonSets用于管理需要在集群中所有节点上运行的服务或应用程序。如果你有要在每个节点上运行的日志收集daemon或监控服务，则需要使用DaemonSet。监控与Deployment相同：需要确保
观察到的DaemonSet数量与所需的DaemonSet数量匹配。如果不匹配，则一个或多个DaemonSet失败。
结语
像Kubernetes的大多数方面一样，监控Kubernetes的运行状况可能是一个复杂而具有挑战性的过程，不容易下手。通过了解最需要关注的高价值健康状况，至少可以开始制定策略，能够过滤
掉集群所产生的大量数据“噪音”，并更加自信解决对确保良好体验最重要的问题。
