监控 Kubernetes 节点上的 Pod 资源使用情况

Question

用例/问题

我负责维护一个有 40 个节点（跨 2 个区域）的 Kubernetes 集群。我们在这个集群中运行了大约 100 个微服务和平台，比如 Kafka 代理。所有微服务都定义了资源请求和限制。然而，它们中的大多数都是可爆裂的，并且没有保证 RAM。在我们的集群中部署他们的服务的开发人员定义的限制远远大于请求（见下面的示例），这最终导致在各个节点上被驱逐了很多 pod。尽管如此，我们仍然希望在我们的服务中使用可爆资源，因为我们可以使用可爆资源来节省资金。因此，我需要更好地监控每个节点上运行的所有 pod，包含以下信息：

• 节点名称和 CPU / RAM 容量
• 所有 pod 名称加上
  • pod 的资源请求和限制
  • pod 的当前 cpu 和 ram 使用率

这样我可以很容易地识别出两种有问题的服务：

案例 A： 只是设置了巨大资源限制的微服务，因为开发人员只是在测试东西或者懒得去测试/监控他的服务

resources:
  requests:
    cpu: 100m
    ram: 500Mi
  limits:
    cpu: 6
    ram: 20Gi

案例 B： 同一节点上的服务过多，设置的资源限制不准确（例如 500Mi，但服务始终使用 1.5Gi RAM）。这种情况发生在我们身上，因为 Java 开发人员没有注意到 Java 垃圾收集器只会在 75% 的可用 RAM 被使用时才开始清理。

我的问题：

我怎样才能正确监控这一点，从而识别错误配置的微服务，以防止此类驱逐问题？在较小的规模上，我可以简单地运行 kubectl describe nodes 和 kubectl top pods 来手动计算，但在这个规模上，它不再起作用了。

注意：我找不到任何现有的解决方案（包括使用 kube 指标和类似指标的 prometheus + grafana 板）。我认为这是可能的，但在 Grafana 中可视化这些东西真的很难。

Answer 1

这是一个已知问题，因为仍有一个开放的 github issue 并且社区正在请求开发人员创建一个新命令，该命令将显示 pod/container 总 CPU 和内存使用情况。请检查此链接，因为社区提供了一些想法和解决方法，它们看起来可能对您的案例有用。

您是否使用了正确的指标，却无法看到所需的信息？ Here 是 pod 指标列表，我认为其中一些指标对您的用例很有用。

尽管由于社区和其他一些资源，这个问题没有功能齐全的解决方案，但有几种方法可以实现您的目标： 正如article 中所建议的那样：

kubectl get nodes --no-headers | awk '{print $1}' | xargs -I {} sh -c 'echo {}; kubectl describe node {} | grep Allocated -A 5 | grep -ve Event -ve Allocated -ve percent -ve -- ; echo'

另外本文作者推荐CoScale我没用过，但是如果其他解决方案都失败了似乎值得一试。

我认为另一点是，如果您的开发人员一直分配的资源远远超过所需资源，您可能永远无法控制。 Nicola Ben 推荐的解决方案将帮助您缓解此类问题。

Answer 2

为此，我最终编写了一个自己的 prometheus 导出器。虽然节点导出器提供使用情况统计信息，而 kube 状态指标公开有关您的 kubernetes 资源对象的指标，但将这些指标组合和聚合以提供有价值的信息来解决所描述的用例并不容易。

使用 Kube Eagle (https://github.com/google-cloud-tools/kube-eagle/)，您可以轻松创建这样的仪表板 (https://grafana.com/dashboards/9871)：

我还写了一篇关于这如何帮助我节省大量硬件资源的中型文章：https://medium.com/@martin.schneppenheim/utilizing-and-monitoring-kubernetes-cluster-resources-more-effectively-using-this-tool-df4c68ec2053

Answer 3

如果可以的话，我建议你使用LimitRange和ResourceQuota资源，例如：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: happy-developer-quota
spec:
  hard:
    requests.cpu: 400m
    requests.memory: 200Mi
    limits.cpu: 600m
    limits.memory: 500Mi

对于极限范围：

 apiVersion: v1
 kind: LimitRange
 metadata:
   name: happy-developer-limit
 spec:
   limits:
   - default:
       cpu: 600m
       memory: 100Mib
     defaultRequest
       cpu: 100m
       memory: 200Mib
     max:
       cpu: 1000m
       memory: 500Mib
     type: Container

这可以防止人们在默认命名空间内创建超小或超大的容器。