kube-prometheus
https://github.com/prometheus-operator/kube-prometheus
云原生监控挑战
Prometheus 是用 Go 语言编写，从一开始就是开源的，到 2016 年 Prometheus 成为继 Kubernetes 之后，成为 CNCF 的第二个成员。近几年Prometheus的火热，和云原生日趋流行是密不可分的，并且现在已成为云原生生态中监控的事实标准。
传统的监控霸主Zabbix在面对云原生监控时，主要面临如下几个挑战：
- 监控对象数量增大：传统监控以单体应用为粒度，结合计算、存储、网络等基础设施监控进行运维保障。但在容器化微服务架构下，监控粒度细致到容器POD或微服务API级别，使得监控对象的数量相比单体应用呈指数级增长。
- 监控指标海量：
- 资源对象类型多，如：Container、Pod、Service、Deployment、ReplicaSet、Endpoint、Ingress、PV、PVC等等；
- 一个云原生集群可能有几万甚至几十万Pod；
- 一个云原生集群可能有几千上万级别的Service、Endpoint、Deployment、Ingress等；
- 海量的监控指标对数据写入、查询性能要求较高，以及存储空间占用优化等，才能承载海量的监控资源
- 对象动态变更较为频繁，资源对象的扩缩容、资源对象生命周期大大缩短，甚至有些对象朝生夕死等等，这就会带来两个问题：
- 采集目标不能使用传统的静态配置方式，而是要基于服务发现机制能及时的感知到变化，并进行快速调整；
- 资源对象扩缩容等导致的资源对象生命周期大大缩短是很容易导致指标数量的快速膨胀，久而久之会影响整个监控系统性能；
Zabbix出现得比较早，当时容器还没有诞生，自然对容器的支持比较差，而Prometheus的TSDB时序数据存储机制、丰富的服务发现机制等，基本就是为云原生量身定做的，Prometheus开始成为容器监控方面的标配，并且在未来可见的时间内会被广泛应用。
云原生监控方案
kubernetes云原生集群非常复杂，概况总结下我们主要关注的无外乎下面五大块指标：
- 容器基础资源指标：组件运行的外部环境相关性能指标，传统场景下组件运行的外部环境是主机，而云原生环境下组件的外部环境是容器，主机我们需要关注CPU、内存、存储、磁盘IO、网络IO等相关指标，同理容器基础资源指标也存在类似相关指标，如：Container的CPU使用率、内存使用率、存储空间、磁盘读写IO和网络IO等。
- k8s资源对象指标：容器是最底层的运行时组件，k8s作为强大的调度协调这些容器的平台，抽象定义出了很多资源对象，如Pod、Service、Deployment、ReplicaSet、DaemonSet、Ingress、StatefulSet、ConfigMap、ServiceAccount等等，资源对象指标就是对这些k8s定义的元数据信息进行监控。
- k8s服务组件指标：k8s作为一个复杂的集群，自身存在很多组件，如master节点上运行着：api-server组件、etcd组件、kube-scheduler组件、kube-controller-manager组件、coredns组件等，node节点上有kubelet组件、kube-proxy组件等，作为云原生集群的运维人员，肯定要关注这些核心组件的运行状况，避免某些组件性能瓶颈、异常奔溃导致整个云原生集群性能低下甚至不可用。
- k8s集群Node指标：云原生集群的各种组件、业务容器等最终都是运行在Node节点上，因此，Node节点的性能、异常情况等对整个云原生集群的影响也是非常大的，所以，我们也需要特别关注Node节点性能指标。
- 云原生上层业务指标：上面说的主要是云原生集群底层相关基础指标，云原生作为平台上面自然部署很多业务组件，比如PaaS中间件、业务应用服务等，这些组件运行在云原生上层本身也存在相关指标监控。
环境准备
为了监控上述云原生指标，首先，我们需要准备Prometheus、Grafana环境。
Prometheus部署