我创建了 Kube Eagle - 一个 Prometheus 导出器。 事实证明这是一件很酷的事情，有助于更好地了解中小型集群的资源。 最终，我节省了数百美元，因为我选择了正确的机器类型并为工作负载配置了应用程序资源限制。
我会告诉你好处 ，但首先我将解释是什么引起了大惊小怪以及为什么需要高质量的监控。
我管理了多个 4-50 个节点的集群。 每个集群最多包含 200 个微服务和应用程序。 为了更好地利用现有硬件，大多数部署都配置了可突发的 RAM 和 CPU 资源。 这样，Pod 可以在必要时获取可用资源，同时不会干扰该节点上的其他应用程序。 嗯，不是很好吗？
尽管集群消耗的 CPU (8%) 和 RAM (40%) 相对较少，但当 Pod 尝试分配比节点上可用的内存更多的内存时，我们经常会遇到被抢占的问题。 当时我们只有一个仪表板来监控 Kubernetes 资源。 像这样：
仅包含 cAdvisor 指标的 Grafana 仪表板
有了这样的面板，看到消耗大量内存和CPU的节点都不是问题。 问题是要弄清楚原因是什么。 为了保持 Pod 就位，当然可以在所有 Pod 上设置有保证的资源（请求的资源等于限制）。 但这并不是硬件最明智的使用方式。 该集群拥有数百 GB 的内存，而一些节点的内存不足，而其他节点则有 4-10 GB 的预留空间。
事实证明，Kubernetes 调度程序在可用资源上不均匀地分配工作负载。 Kubernetes 调度程序考虑了不同的配置：关联性、污点和容忍规则、可以限制可用节点的节点选择器。 但就我而言，没有这样的情况，并且 Pod 是根据每个节点上请求的资源来规划的。
为 Pod 选择空闲资源最多且满足请求条件的节点。 我们发现节点上请求的资源与实际使用情况不符，这就是 Kube Eagle 及其资源监控功能可以解决的问题。
我仅使用以下命令监控几乎所有 Kubernetes 集群 и 。 Node Exporter 提供 I/O 和磁盘、CPU 和 RAM 使用情况的统计信息，而 Kube State Metrics 显示 Kubernetes 对象指标，例如请求以及 CPU 和内存资源限制。
我们需要将使用指标与 Grafana 中的请求和限制指标结合起来，然后我们将获得有关问题的所有信息。 这听起来很简单，但是这两个工具实际上对标签的命名不同，并且某些指标根本没有任何元数据标签。 Kube Eagle 会自行完成所有操作，面板如下所示：
我们设法利用资源并节省设备解决了许多问题：
- 一些开发人员不知道微服务需要多少资源（或者根本不关心）。 我们无法找到错误的资源请求 - 为此我们需要了解消耗情况以及请求和限制。 现在，他们可以查看 Prometheus 指标、监控实际使用情况并调整请求和限制。
- JVM 应用程序占用它们能够处理的尽可能多的 RAM。 垃圾收集器仅在使用超过 75% 时释放内存。 而且由于大多数服务都有可突发的内存，因此它总是被 JVM 占用。 因此，所有这些 Java 服务消耗的 RAM 比预期多得多。
- 一些应用程序请求了太多内存，并且 Kubernetes 调度程序没有将这些节点提供给其他应用程序，尽管实际上它们比其他节点更空闲。 一位开发人员不小心在请求中添加了一个额外的数字，并占用了一大块 RAM：20 GB，而不是 2。没有人注意到。 该应用程序有 3 个副本，因此多达 3 个节点受到影响。
- 我们引入了资源限制，根据正确的请求重新安排 Pod，并在所有节点之间实现了硬件使用的理想平衡。 几个节点可能已经完全关闭。 然后我们发现我们使用了错误的机器（面向 CPU，而不是面向内存）。 我们更改了类型并删除了更多节点。
结果
通过集群中的可突发资源，您可以更有效地使用可用硬件，但 Kubernetes 调度程序根据资源请求来调度 Pod，这令人担忧。 一石二鸟：为了避免问题并充分利用资源，需要良好的监控。 这就是为什么它会很有用 （Prometheus 导出器和 Grafana 仪表板）。
来源： habr.com