用例/问题
我负责维护一个有40个节点(分为2个区域)的kubernetes集群。在这个集群中,我们大约有100种微服务和平台之类的东西,例如Kafka经纪人。所有微服务都定义了资源请求和限制。但是,它们大多数都是易爆的,并且没有保证的RAM。在我们的集群中部署其服务的开发人员定义的限制远大于请求(请参见下面的示例),最终导致在各个节点上驱逐了很多Pod。但是,我们仍然希望在服务中使用易爆资源,因为我们可以使用易爆资源节省资金。因此,我需要更好地监视每个节点上运行的所有Pod的可能性,其中包含以下信息:
这样,我可以轻松地识别出两种有问题的服务:
案例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中可视化这些东西真的很难。
为此,我最终编写了自己的普罗米修斯出口商。虽然节点导出器提供了使用情况统计信息,并且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
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句