11.3. 识别指示最佳节点资源使用情况的指标

在最后一天中带有最多 OOM 终止的头 3 个容器会获取遇到最多 Out-Of-Memory (OOM) 终止的前三个容器的详细信息。

topk(3, sum(increase(container_runtime_crio_containers_oom_count_total[1d])) by (name))

OOM 终止会强制系统因为内存不足而终止某些进程。频繁 OOM 终止可能会妨碍节点的功能，甚至整个 Kubernetes 生态系统。频繁遇到 OOM 终止的容器可能会消耗比预期更多的内存，这会导致系统不稳定。

使用此指标可以发现频繁出现 OOM 终止的容器，并调查这些容器消耗大量内存的原因。如果需要，调整资源分配，并考虑根据容器内存用量重新定义大小。您还可以查看 Outliers、Average durations 下的指标，以及操作类别的数量，以便进一步了解节点的健康状态和稳定性。

在最后一小时中的镜像拉取故障率会将失败镜像的总数除以成功和失败的镜像拉取的总数，以提供失败率。

rate(container_runtime_crio_image_pulls_failure_total[1h]) / (rate(container_runtime_crio_image_pulls_success_total[1h]) + rate(container_runtime_crio_image_pulls_failure_total[1h]))

了解镜像拉取失败率对于维护节点健康状况至关重要。高故障率可能表示网络问题、存储问题、错误配置或其他可能破坏 pod 密度和部署新容器的问题。

如果此查询的结果很高，调查可能的原因，如网络连接、远程存储库、节点存储以及镜像引用的准确性。您还可以查看 Outliers、Average durations 下的指标，以及操作数量，以便进一步了解。

系统保留内存使用率 > 80% 的节点查询计算每个节点的系统保留内存的百分比。计算方法是，总的 resident set size (RSS) 除以从可分配内存中减去的节点的总内存容量。RSS 是由进程占用的系统内存的部分，它位于主内存 (RAM) 中。如果生成的值等于或超过 80% 阈值，则节点会被标记。

sum by (node) (container_memory_rss{id="/system.slice"}) / sum by (node) (kube_node_status_capacity{resource="memory"} - kube_node_status_allocatable{resource="memory"}) * 100 >= 80

系统保留内存对于 Kubernetes 节点至关重要，因为它用于运行系统守护进程和 Kubernetes 系统守护进程。超过 80% 的系统保留内存使用率表示系统和 Kubernetes 守护进程消耗太多内存，可能会导致节点不稳定并可能进一步影响到运行 pod 的性能。过量内存消耗可能会导致内存不足(OOM)终止程序，它可能会终止关键系统进程来释放内存。

如果一个节点被这个指标标记，请找出哪个系统或 Kubernetes 进程消耗了过量内存，并采取适当的操作来缓解这种情况。可能采取的操作包括，减少非关键进程、优化程序配置来减少内存用量，或者将节点系统升级到具有更大内存容量的硬件。您还可以查看 Outliers、Average durations 下的指标，以及操作数量，以便进一步深入了解节点性能。

Kubelet 系统保留内存使用率 > 50% 的节点 查询指示 Kubelet 系统保留内存利用率超过 50% 的节点。查询检查 Kubelet 进程本身在节点上消耗的内存。

sum by (node) (container_memory_rss{id="/system.slice/kubelet.service"}) / sum by (node) (kube_node_status_capacity{resource="memory"} - kube_node_status_allocatable{resource="memory"}) * 100 >= 50

此查询可帮助您识别节点中可能的内存压力，这可能会影响节点操作稳定性和效率。kubelet 内存使用率持续超过系统保留内存的 50%，表示系统保留设置没有正确配置，且节点不稳定的风险较高。

如果此指标被高亮显示，请检查您的配置策略，并考虑调整系统保留的设置，或调整为 Kubelet 设置的资源限值。另外，如果您的 Kubelet 内存使用率持续超过总保留系统内存的一半，请检查 Outliers 下的指标、平均持续时间，以及操作数量，以便进一步了解更精确的诊断。

带有 CRI-O 系统保留内存使用率 > 50% 的节点 查询计算为 CRI-O 系统保留的内存百分比大于或等于 50% 的所有节点。在这种情况下，内存用量由 resident set size (RSS) 定义，这是 RAM 中持有的 CRI-O 系统内存的一部分。

sum by (node) (container_memory_rss{id="/system.slice/crio.service"}) / sum by (node) (kube_node_status_capacity{resource="memory"} - kube_node_status_allocatable{resource="memory"}) * 100 >= 50

此查询可帮助您监控每个节点上的 CRI-O 系统保留的内存状态。高利用率可能表示缺少可用资源和潜在性能问题。如果为 CRI-O 系统保留的内存超过推荐的 50% 限制，这表示节点上的 CRI-O 使用了系统保留内存的一半。

检查内存分配和使用，并评估内存资源是否需要转换或增加，以防止可能的节点不稳定。您还可以检查 Outliers、Average durations 下的指标，以及操作数量，以便进一步了解。

系统保留 CPU 使用率 > 80% 的节点 查询可识别 system-reserved CPU 使用率超过 80% 的节点。查询侧重于 system-reserved 容量，以计算最后 5 分钟内 CPU 用量率，并将其与节点上可用的 CPU 资源进行比较。如果比率超过 80%，节点的结果会显示在指标中。

sum by (node) (rate(container_cpu_usage_seconds_total{id="/system.slice"}[5m]) * 100) / sum by (node) (kube_node_status_capacity{resource="cpu"} - kube_node_status_allocatable{resource="cpu"}) >= 80

此查询表示 system-reserved CPU 用量的关键级别，这可能会导致资源耗尽。高 system-reserved CPU 使用率可能会导致系统进程（包括 Kubelet 和 CRI-O）无法充分管理节点上的资源。此查询可以指示系统进程过高或配置错误的 CPU 分配。

潜在的修正措施包括将工作负载重新平衡到其他节点，或者增加分配给节点的 CPU 资源。调查高系统 CPU 使用率的原因，并查看 Outliers 中对应的指标、平均持续时间，以及操作类别，以便深入了解节点的行为。

带有 Kubelet 系统保留的 CPU 使用率 > 50% 查询的节点 计算 Kubelet 系统当前使用的 CPU 的百分比。

sum by (node) (rate(container_cpu_usage_seconds_total{id="/system.slice/kubelet.service"}[5m]) * 100) / sum by (node) (kube_node_status_capacity{resource="cpu"} - kube_node_status_allocatable{resource="cpu"}) >= 50

Kubelet 使用系统保留 CPU 进行自己的操作，并运行关键系统服务。对于节点的健康状况，务必要确保系统保留 CPU 使用量不超过 50% 阈值。超过这个限制可能会指示 Kubelet 上的大量利用率或负载，这会影响节点稳定性并可能整个 Kubernetes 集群的性能。

如果此指标中显示任何节点，Kubelet 和系统总体负载非常重。您可以通过在集群中的其他节点之间平衡负载来减少特定节点上的过载。检查 Outliers、Average 持续时间和操作类别下的其他查询指标，以便进一步深入了解并采取必要的纠正措施。

CRI-O 系统保留 CPU 使用率 > 50% 的节点 查询在最后 5 分钟内标识 CRI-O 系统保留 CPU 使用率超过 50% 的节点。查询会基于每个节点监控 CRI-O （容器运行时）的 CPU 资源消耗。

sum by (node) (rate(container_cpu_usage_seconds_total{id="/system.slice/crio.service"}[5m]) * 100) / sum by (node) (kube_node_status_capacity{resource="cpu"} - kube_node_status_allocatable{resource="cpu"}) >= 50

此查询可以快速识别可能对 pod 性能造成负面影响的异常启动时间。如果此查询返回高值，您的 pod 启动时间会比通常慢，这意味着 kubelet、pod 配置或资源的潜在问题。

通过检查 pod 配置和分配的资源来进一步调查。确保它们与您的系统功能一致。如果您仍然看到高启动时间，请浏览仪表板中其他类别的指标面板，以确定您的系统组件的状态。