k8s监控体系

k8s运维体系中，监控、部署架构、日志收集是重点研究课题，随着k8s的不断迭代发展，监控架构体系随着产生变化：（需要结合promethues）

1. 基于k8s1.11版本以前，监控架构基本是cAdvisor+Heapster+influxdb+grafana

 

 

背景知识：

docker容器实现基于namespace、cgroups 和联合文件系统；（数据来源于cgroup，namespace实现资源的隔离）
cAdisor是谷歌开源的一款产品，主要收集docker的以及宿主机的CPU 使用情况、内存使用情况、网络吞吐量及文件系统使用情况，在 K8S 中集成在 Kubelet 里作为默认启动项，无需额外安装；
Heapster是聚合数据、分析数据的工具，数据暂存内存，收集 Node 节点上的 cAdvisor 数据，默认的聚合时间周期为1分钟，需要结合类似influxdb时间序列数据库，容器集群监控和性能分析工具，天然的支持 Kubernetes;

2. k8s1.11以后，官方废除Heapster以后，cAdvisor+metrics-server(kube-state-metric) + custom metrics-server API+Influxdb+grafana

 

 

区别：

 metric-server  并不是 kube-apiserver 的一部分，而是通过 Aggregator 这种插件机制，在独立部署的情况下同 kube-apiserver 一起统一对外服务的,metrics-server 主要针对 node、pod 等的 cpu、网络、内存等系统指标的监控；如果需要基础监控,k8s集群就要安装这个组件；

kube-state-metric主要关注 deployment,、node 、 pod 等内部对象的状态，比方是副本数是可用，哪些pod是已经处于运行状态，重启次数等等，所以kube-state-metrics 关注于获取 k8s 各种资源的最新状态，如 deployment 或者 daemonset，之所以没有把 kube-state-metrics 纳入到 metric-server 的能力中，是因为他们的关注点本质上是不一样的。metric-server 仅仅是获取、格式化现有数据，写入特定的存储，实质上是一个监控系统。而 kube-state-metrics 是将 k8s 的运行状况在内存中做了个快照，并且获取新的指标，但它没有能力导出这些指标；

由此可见，metric-server与kube-state-metric存在本质上的不同，两者关注方向不一样，所以在k8s监控体系中，promethues+metric-server(kubectl top必须,HPA必须)+kube-state-metric+kubelet(cAdivsor)算是比较比较全面的监控方案。

注意点：

1.部署metric-server的deployment.yaml时，如果是自建k8s集群或者EKS，需要在command字段下添加- /metric-server - --kubelet-inseure-tls - --kubelet-preferred-address-types=InternalIP,Hostname.InternalDNS,ExternalIP；

2.在k8s集群部署完kube-state-metric时，需要在service.yaml中加上对应的注解字段prometheus.io/scrape: 'true'，否则promethues自动抓取不到指标；

3.部署promethues的时候，选择kube-prometheus，而不是prometheus-operator，因为前者包含了后者，还包括promethues的相关组件：Highly available Alertmanager，Highly available Prometheus，Prometheus node-exporter、Prometheus Adapter for Kubernetes Metrics APIs、kube-state-metrics、Grafana、serviceMonitor等等；