k8s应该监控哪些指标及原因
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 或向集添加更多节点。
pending可以使⽤开源组件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 运⾏状况可能是⼀个复杂且具有挑战性的过程。很容易不知所措。通过了解最需要关注的⾼价值的指标，⾄少可以开始制定⼀项策略，能够过滤掉集产⽣的⼤量数据噪⾳，并更有信⼼解决最重要的问题，以确保良好的体验。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。