Kubernetes 每天可以生成数百万个新指标。监控集群健康状况最具挑战性的方面之一是筛选哪些指标是重要的，需要收集和关注。
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
- 如果应用程序合法地需要更多空间，这可能意味着需要添加更多磁盘空间。
- 应用程序行为异常并以意外的方式过早地填满了磁盘。
4.Memory Pressure
Memory Pressure是另一种资源状况，表明节点内存不足。
- 需要注意这种情况，因为这可能意味应用程序中存在内存泄漏。
5.Network Unavailable
所有节点都需要网络连接，Network Unavailable此状态表明节点的网络连接有问题。
- 要么设置不正确（由于路由耗尽或配置错误），要么与硬件的网络连接存在物理问题。
- 可以使用开源组件KubeNurse进行集群网络监控
6.Job Failures
作业旨在在有限的时间内运行 Pod，并在完成预期功能后将其释放。
- 如果作业因节点崩溃或重新启动或资源耗尽而未能成功完成，需要要知道作业失败。
- 通常并不意味着您的应用程序无法访问，但如果不加以修复，它可能会导致以后会出现问题。
- 可以使用开源组件kube-eventer来推送事件。
7.Pod Pending Delays
在 pod 的生命周期中，如果它正在等待在节点上进行调度，则其状态为“pending”。如果它停留在“pending”状态，通常意味着没有足够的资源来安排和部署 pod。
- 将需要更新 CPU 和内存分配、删除 Pod 或向集群添加更多节点。
- 可以使用开源组件kube-eventer来推送事件。
8.StatefulSets Not Ready
StatefulSets 用于管理有状态的应用程序，其中 Pod 具有特定的角色，需要访问其他特定的 Pod；而不是像部署那样只需要特定类型的 pod。
- 确保观察到的 StatefulSet 的数量与所需的 StatefulSet 的数量相匹配。如果不匹配，则一个或多个 StatefulSet 失败。
- 可以使用开源组件kube-eventer来推送事件。
9.DaemonSets Not Ready
DaemonSets 用于管理需要在集群中的所有节点上运行的服务或应用程序。每个节点上运行日志收集守护进程（filebeat）或监控服务，需要使用 DaemonSet。
- 确保观察到的 DaemonSet 数量与所需的 DaemonSet 数量相匹配。如果不匹配，则一个或多个 DaemonSet 失败。
- 可以使用开源组件kube-eventer来推送事件。
10.Scheduler Problems
调度器有两个方面值得关注。
- 应该进行监控，scheduler_schedule_attempts_total{result:unschedulable}因为不可调度 Pod 的增加可能意味着您的集群存在资源问题。
- 其次，应该使用上述延迟指标之一密切关注调度程序延迟。Pod 调度延迟的增加可能会导致其他问题，也可能表明集群中存在资源问题。
11.Events
除了从 Kubernetes 集群收集数字指标之外，从集群收集和跟踪事件也很有用。集群事件能监控 pod 生命周期并观察重大的 pod 故障，并且观察从集群流出的事件速率可以是一个很好的早期预警指标。如果事件发生率突然或显着变化，则可能表明出现问题。
- 可以使用开源组件kube-eventer来推送事件。
总结：
与 Kubernetes 的大多数方面一样，监控 Kubernetes 运行状况可能是一个复杂且具有挑战性的过程。很容易不知所措。通过了解最需要关注的高价值的指标，至少可以开始制定一项策略，能够过滤掉集群产生的大量数据噪音，并更有信心解决最重要的问题，以确保良好的体验。
评论区