监控pod的资源使用量

设置合适的 资源 requests 和 limits 对充分利用 Kubernetes 集群资源来说十分重要。如果 requests 设置得太高，集群节点利用率就会比较低，这样就白白浪费了金钱。如果设置得太低，应用就会处于 CPU 饥饿状态，甚至很容易被 OOM Killer 杀死。 所以如何才能找到 requests 和 limits 的最佳配置呢？
可以通过对容器在期望负载下的资源实际使用率进行监控来找到这个最佳配置。当然一旦应用暴露于公网，都应该保持监控并且在需要时对其资源的 reques limits 进行调节。

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

Kubelet 自身就包含了一个名为 cAdvisor agent ，它会收集整个节点和节点上运行的所有单独容器的资源消耗情况。 集中统计整个集群的监控信息需要运行 个叫作 Heapster 的附加组件。
Heapste pod 的方式运行在某个节点上，它通过普通的 Kubrnetes Service 暴露服务，使外部可以通过一个稳定的 IP 地址访问。它从集群中所有的 cAdvisor 收集数据，然后通过一个单独的地址暴露。

图中的箭头表示监控数据流动的方向， 它并不代表组件之间用来获取数据的连接关系。
pod （或者 pod 中运行的容器）感知不到 cAdvisor 存在，cAdvisor也感知不到 Heapster 存在。
Heapster 主动请求所有的 cAdvisor ，同时 cAdvisor 无须通过与 pod 容器内进程通信就可以收集到容器和节点的资源使用数据。

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

cAdvisor 和 Heapster都只保存一个很短时间窗的资源使用量数据。 如果需要分析一段时间的 pod 的资源使用情况， 必须使用额外的工具。

lnfluxDB 和 Grafana 介绍
lnfluxDB 是一个用于存储应用指标， 以及其他监控数据的开源的时序数据库。
Grafana 是一个拥有着华丽的 web 控制台的数据分析和可视化套件，同样也是开源的，它允许用户对 InfluxDB 中存储的数据进行可视化， 同时发现应用程序的资源使用行为是如何随时间变化的。