千分尺暴露执行器指标 vs kube-state-metrics vs metrics-server 以设置 pod 请求/限制答案

【问题标题】：micrometer exposing actuator metrics vs kube-state-metrics vs metrics-server to set pod request/limits千分尺暴露执行器指标 vs kube-state-metrics vs metrics-server 以设置 pod 请求/限制
【发布时间】：2021-01-30 00:59:56
【问题描述】：

微米暴露执行器指标以在 K8svs metrics-server vs kube-state-metrics 中设置请求/限制 Pod ->来自 kube-promethteus-stack Grafana dashboad 的 K8s Mixin 让我理解为什么标题中的 3 的值之间存在如此大的差异以及应该如何利用 K8s Mixin 来设置适当的请求/限制以及是否可以预期，这让我感到非常模糊和沮丧。我希望我能看到与在 Grafana 中打开 K8s -> ComputeResources -> Pods 仪表板时输入 kubectl top podname --containers 时看到的相同的数据。但不仅这些值相差一倍以上，而且来自执行器的报告值也与两者不同。当使用千分尺公开 spring 数据时，jvm_memory_used_bytes 的总和更多地对应于我从 metrics-server (0.37.0) 获得的数据，而不是我从 mixin 仪表板在 Grafana 上看到的数据，但仍然相去甚远。我在由 kubespray 管理的 Ubuntu 18.04 LTS 上使用 K8s: 1.14.3。 kube-prometheus-stack 9.4.4 与 helm 2.14.3 一起安装。带千分尺的 Spring Boot 2.0。我在 metrics-server git 上看到了解释，这是 kubelet 用于 OOMKill 的值，但同样这根本没有帮助，因为我应该如何处理仪表板？有什么办法处理呢？

【问题讨论】：

我发现双值是 Grafana 中提供的查询中某些内容的结果：当我运行以下即时向量 container_memory_working_set_bytes{cluster="", namespace="qa2", pod="service- x-684f5565b7-wbgm6", container!="POD", container!="", image!=""} 为什么我会得到 4 个结果而不是 2 个（服务和 istio-proxy），这背后的逻辑解释是什么，我得到 2 次服务和 2 次具有相同值的代理，但指标端点中的不同 id 是 kube-prometheus-stack helm 图表中的错误还是操作员级别的错误？

标签： java kubernetes prometheus grafana spring-micrometer

【解决方案1】：

根据我目前看到的情况，我找到了根本原因，将 kubelet 服务从旧图表重命名为新图表，可以被 serviceMonitors 定位。所以对我来说最好的解决方案是 grafana kube-state-metrics + 比较我在 jvm 仪表板中看到的内容

【讨论】：