监视Kubernetes节点上的pod资源使用情况

时间:2018-09-27 15:40:48

标签: kubernetes monitoring

用例/问题

我负责维护具有40个节点(分为2个区域)的kubernetes集群。在这个集群中,我们大约有100种微服务和平台之类的东西,例如Kafka经纪人。所有微服务都定义了资源请求和限制。但是,它们大多数都是可爆发的,并且没有保证的RAM。在我们的集群中部署其服务的开发人员定义的限制远大于请求(请参见下面的示例),最终导致在各个节点上驱逐了很多Pod。但是,我们仍然希望在服务中使用易爆资源,因为我们可以使用易爆资源节省资金。因此,我需要更好地监视每个节点上运行的所有Pod的可能性,其中包含以下信息:

  • 节点名称和CPU / RAM容量
  • 所有广告连播名称加上
    • 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 nodeskubectl top pods来手动解决问题,但是在这种规模下,它不再起作用。

注意:我找不到针对此问题的任何现有解决方案(包括使用kube指标和类似指标的prometheus + grafana板)。我以为有可能,但是在Grafana中可视化这些东西真的很难。

3 个答案:

答案 0 :(得分:3)

这是一个已知问题,因为github issue仍然开放,社区要求开发人员创建一个新命令,该命令将显示pod /容器的总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建议的解决方案将帮助您缓解此类问题。

答案 1 :(得分:3)

我最终为此目的编写了自己的普罗米修斯出口商。尽管节点导出器提供了使用情况统计信息,并且kube状态指标公开了有关您的kubernetes资源对象的指标,但要合并和聚合这些指标并不容易,以便它们提供有价值的信息来解决所描述的用例。

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

Grafana dashboard for Kubernetes resource monitoring

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

答案 2 :(得分:1)

如果可以,我建议您使用LimitRangeResourceQuota资源,例如:

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

对于LimitRange:

 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

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