前面学了设置资源的requests和limits,这节课学习如何监控资源,根据监控资源使用情况,对requests和limits进行合理配置。
收集、获取实际资源使用情况
kubelet包含一个agent,名为cAdvisor,它会收集整个节点上运行的所有单独容器的资源消耗情况,这些信息可以通过一个附加组件Heapster来集中统计整个集群的监控信息
Heapster以pod的方式运行在某个节点上,他通过普通的kubernetes Service暴露服务,使外部可以通过一个稳定的ip地址访问。它从集群中所有的cAdvisor收集信息,然后通过一个单独的地址暴露。
启动Heapster
Google Container Engine上,Heapster默认已经启动
Minikuber上,作为一个插件使用,需要命令开启:$minikube addons enable heapster
其他类型的kubernetes集群运行heapster,参考:https://github.com/kubernetes/heapers
说明:启动heapster需要等几分钟
显示集群节点的cpu和内存使用量
kubectl top node
显示单独pod的cpu和内存使用量
kubectl top pod --all -namespaces
保存并分析历史资源的使用统计信息
top命令仅仅展示了当前的资源使用量,他不会显示从一小时、一天、一周前到现在的pod和cpu使用多少。cAdvisor和Heapster都只保存了一个很短时间窗的资源使用量数据。需要分许一段时间的pod和资源使用情况,必须使用额外的工具。Google container engine,可以通过google cloud monitoring来队进行进行监控,但对本地kubernetes集群,可以使用InfluxDB来存储统计数据,然后使用Grafana对数据进行可视化分析。
InfluxDB和Grafana
InfluxDB是一个用于存储应用指标,以及其他监控数据的开源的时序数据库。
Grafana是一个拥有华丽的web控制台的数据分析和可视化套件,也是开源的
它运行用户对InfluxDB中存储的数据进行可视化,同时发现应用程序的资源使用随着时间如何发生变化。
计算资源章节总结:
本章节讲了为了确保一切顺利运行,需要考虑pod的资源使用情况,同时为pod配置资源requests和limits
指定资源requests,帮助kubernetes在集群内对pod进行调度
指定资源limits,防止一个pod抢占其他pod的资源
空闲的cpu时间根据容器的cpu requests来分配
如果容器使用过量cpu,系统不会杀死这个容器,但是如果使用过量内存会被杀死
在一个overcommited的系统,容器同样可以被杀死释放内存给更重要的pod,这基于pod的QoS等级和实际内存用量
可以通过LimitRange对象为单个pod的资源requests和limits定义最小值、最大值和默认值
可以通过ResourcesQuota对象限制一个命名空间中所有pod的可用资源数量文章来源:https://www.toymoban.com/news/detail-449265.html
要知道如何为pod设置合适的requests和limits,需要一段足够长时间内对pod资源的使用情况进行监控文章来源地址https://www.toymoban.com/news/detail-449265.html
到了这里,关于Kubernetes学习笔记-计算资源管理(4)监控pod的资源使用量20230219的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!