前面学了设置资源的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的可用资源数量
要知道如何为pod设置合适的requests和limits，需要一段足够长时间内对pod资源的使用情况进行监控