Kubernetes学习笔记-计算资源管理（4）监控pod的资源使用量20230219

前面学了设置资源的requests和limits，这节课学习如何监控资源，根据监控资源使用情况，对requests和limits进行合理配置。

1. 收集、获取实际资源使用情况

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

2. 保存并分析历史资源的使用统计信息

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的可用资源数量

• 要知道如何为pod设置合适的requests和limits，需要一段足够长时间内对pod资源的使用情况进行监控