Kubernetes 每天可以生成数百万个新指标。监控集群健康状况最具挑战性的方面之一是筛选哪些指标是重要的，需要收集和关注。
在本文中，我将定义应该监控和创建警报的 16 个关键 Kubernetes 指标。公司组织的列表可能略有不同，但在制定组织的 Kubernetes 监控策略时，这 16 个是了解k8s集群监控状态最好的指标。
1、Crash Loops
crash loops是指 pod 启动、崩溃，然后不断尝试重新启动但不能（它在循环中不断崩溃和重新启动）。当发生这种情况时，应用程序将无法运行。
可能是由 pod 中的应用程序崩溃引起的
可能是由 pod 或部署过程中的错误配置引起的
当发生crash loops时，需要查看日志来解决问题。
可以使用开源组件kube-eventer来推送事件。
2、CPU Utilization
CPU 使用率就是节点正在使用的 CPU 的使用率。出于两个原因进行监控很重要：
应用程序不能使用完应用程序分配的cpu。如果应用程序受 CPU 限制，则需要增加 CPU 分配或者增加pod数量。最终需要增加服务器来解决。
你不希望你的 CPU 坐在那里闲置。如果服务器 CPU 使用率一直很低，可能过度分配了资源并可能浪费金钱。
3、Disk Pressure
根据 Kubernetes 配置中设置的阈值，磁盘压力是指示节点使用过多磁盘空间或使用磁盘空间过快的条件。
如果应用程序合法地需要更多空间，这可能意味着需要添加更多磁盘空间。
应用程序行为异常并以意外的方式过早地填满了磁盘。
4、Memory Pressure
Memory Pressure是另一种资源状况，表明节点内存不足。
需要注意这种情况，因为这可能意味应用程序中存在内存泄漏。
5、PID Pressure
PID 压力是一种罕见的情况，即 Pod 或容器产生过多进程并使节点缺乏可用进程 ID。
每个节点都有有限数量的进程 ID 来分配给正在运行的进程；
如果 ID 用完，则无法启动其他进程。
Kubernetes 允许为 pod 设置 PID 阈值以限制它们执行失控进程生成的能力，而 PID 压力条件意味着一个或多个 pod 正在用完分配的 PID，需要进行检查。
6、Network Unavailable
所有节点都需要网络连接，Network Unavailable此状态表明节点的网络连接有问题。
要么设置不正确（由于路由耗尽或配置错误），要么与硬件的网络连接存在物理问题。
可以使用开源组件KubeNurse进行集群网络监控
7、Job Failures
作业旨在在有限的时间内运行 Pod，并在完成预期功能后将其释放。
如果作业因节点崩溃或重新启动或资源耗尽而未能成功完成，需要要知道作业失败。
通常并不意味着您的应用程序无法访问，但如果不加以修复，它可能会导致以后会出现问题。
可以使用开源组件kube-eventer来推送事件。
8、Persistent Volume Failures
持久卷是在集群上指定的存储资源，可用作任何请求它的 Pod 的持久存储。在它们的生命周期中，它们被绑定到一个 Pod，然后在该 Pod 不再需要时回收。
如果该回收因任何原因失败，需要知道的持久存储有问题。
9、Pod Pending Delays
在 pod 的生命周期中，如果它正在等待在节点上进行调度，则其状态为“pending”。如果它停留在“pending”状态，通常意味着没有足够的资源来安排和部署 pod。
将需要更新 CPU 和内存分配、删除 Pod 或向集群添加更多节点。
可以使用开源组件kube-eventer来推送事件。
10、Deployment Glitches
Deployment Glitches部署用于管理无状态应用程序——其中 Pod 是可互换的，不需要能够访问任何特定的单个 Pod，而只需访问特定类型的 Pod。
需要密切关注部署以确保它们正确完成。最好的方法是确保观察到的部署数量与所需的部署数量相匹配。如果不匹配，则一个或多个部署失败。
11、StatefulSets Not Ready
StatefulSets 用于管理有状态的应用程序，其中 Pod 具有特定的角色，需要访问其他特定的 Pod；而不是像部署那样只需要特定类型的 pod。
确保观察到的 StatefulSet 的数量与所需的 StatefulSet 的数量相匹配。如果不匹配，则一个或多个 StatefulSet 失败。
可以使用开源组件kube-eventer来推送事件。
12、DaemonSets Not Ready
DaemonSets 用于管理需要在集群中的所有节点上运行的服务或应用程序。每个节点上运行日志收集守护进程（filebeat）或监控服务，需要使用 DaemonSet。
确保观察到的 DaemonSet 数量与所需的 DaemonSet 数量相匹配。如果不匹配，则一个或多个 DaemonSet 失败。
可以使用开源组件kube-eventer来推送事件。
13、etcd Leaders
etcd 集群应该总是有一个领导者（除了在改变领导者的过程中，这应该很少发生）。
etcd_server_has_leader，etcd中是否有leader。
leader的改变次数etcd_server_leader_changes_seen_total，则可能表明 etcd 集群中存在连接或资源问题。
14、Scheduler Problems
调度器有两个方面值得关注。
应该进行监控，scheduler_schedule_attempts_total{result:unschedulable}因为不可调度 Pod 的增加可能意味着您的集群存在资源问题。
其次，应该使用上述延迟指标之一密切关注调度程序延迟。Pod 调度延迟的增加可能会导致其他问题，也可能表明集群中存在资源问题。
15、Events
除了从 Kubernetes 集群收集数字指标之外，从集群收集和跟踪事件也很有用。集群事件能监控 pod 生命周期并观察重大的 pod 故障，并且观察从集群流出的事件速率可以是一个很好的早期预警指标。如果事件发生率突然或显着变化，则可能表明出现问题。
可以使用开源组件kube-eventer来推送事件。
16、Application Metrics
与我们上面检查的其他指标和事件不同，应用程序指标不是从 Kubernetes 本身发出的，而是从集群运行的工作负载发出的。从应用程序的角度来看，这种遥测可以是重要的任何内容：错误响应、请求延迟、处理时间等。关于如何收集应用程序指标有两种哲学。
第一个（直到最近才被广泛采用）是指标应该从应用程序“推送”到收集端点。
第二个指标收集理念（越来越广泛采用）是指标应该由收集代理从应用程序中“拉取”。这使得应用程序更容易编写，因为他们所要做的就是适当地发布他们的指标，但应用程序不必担心如何提取或抓取这些指标。这就是 OpenMetrics 的工作方式，也是收集 Kubernetes 集群指标的方式。当此技术与收集代理的服务发现相结合时，它创建了一种强大的方法，可以从集群应用程序中收集您需要的任何类型的指标。
总结：
与 Kubernetes 的大多数方面一样，监控 Kubernetes 运行状况可能是一个复杂且具有挑战性的过程。很容易不知所措。通过了解最需要关注的高价值的指标，至少可以开始制定一项策略，能够过滤掉集群产生的大量数据噪音，并更有信心解决最重要的问题，以确保良好的体验。
