Kubernetes社区之活跃，不断地迭代演化更新一些技术方案，容器监控亦是如此。本文结合官方给出的监控架构及自己的一些实践经验，细说容器监控。在之前的文章(Kubernetes系列(六) 监控及prometheus实践)中有关于Kubernetes容器监控方案的详细介绍，如果感兴趣欢迎阅读
官方监控架构
核心监控管道 由kubelet、资源评估器、metrics-server(精简Heapster)和API server的master metrics API组成。这些监控项被核心系统组件使用，例如调度逻辑(调度器和基于HPA的系统指标)和kubectl top。此管道不适用于第三方监控系统集成
根据核心监控指标的用途，拆解监控数据链路
(1).kubelet(cAdvisor)[ -> 资源评估器 ] -> metrics-server -> API server -> scheduler
(2).kubelet(cAdvisor)[ -> 资源评估器 ] -> metrics-server -> API server -> HPA controller
(3).kubelet(cAdvisor)[ -> 资源评估器 ] -> metrics-server -> API server -> kubectl top
(4).kubelet(cAdvisor)[ -> 资源评估器 ] -> metrics-server -> API server -> OOS Infrastore
监控管道 从系统收集大量监控指标并且将它们导出到用户端、HPA(自定义监控项)以及通过适配器导出到Infrastore。这样的管道通常由每个节点的代理和一个集群级聚合器组成
链路拆解
(5).kubelet(cAdvisor)[ -> node-exporter ] -> prometheus -> HPA API adapter -> HPA controller
(6).kubelet(cAdvisor)[ -> node-exporter ] -> prometheus -> API adapter -> OSS Infrastore
基本链路 kubelet运行于集群中的所有worker node，集成于kubelet中的cAdvisor模块负责采集运行于当前节点上所有Pod、Container的资源(cpu,memory,network,filesystem,etc.)使用情况，按Node、Pod、Container三种级别计算汇总后，通过 /stats/summary 和 /metrics/cadvisor 两个接口分别向API Server提供核心监控指标、向Prometheus提供业务监控指标
官方metrics项目实现
Resource Metrics API
- Heapster 收集监控项并将它们写入指标存储接收器，从内存存储中Expose Resource Metrics API
-
Metrics Server 专门针对Resource Metrics API的轻量级内存服务
Custom Metrics API - Prometheus Adapter Custom Metrics API的一种实现，尝试支持遵循标签和命名规则的任意监控项
- Microsoft Azure Adapter 支持从Azure监控系统检索任意指标
- Google Stackdriver (即将推出)
- Datadog Cluster Agent 使用Datadog作为后端，实现external metrics provider。即将推出: 实现custom metrics provider，以支持Datadog代理收集集群内指标
- Kube Metrics Adapter kubernetes通用监控指标标准适配器，可以收集和提供HPA的自定义和外部度量标准
术语
系统监控项 是通用指标，通常可以从被监控的每个实体获得(e.g. 容器和节点的CPU、Memory使用率)
系统监控项分为
非核心监控指标 不会被Kubernetes解读；我们通常假设它们包括核心监控项和其他监控项
核心监控指标 Kubernetes理解并用于运行其内部组件和核心实用程序的指标。例如，用于调度的指标(包括用于资源估算的算法输入，初始资源/垂直自动扩展，集群自动扩展和HPA，不包括自定义指标)、kube dashboard和kubectl top。截止目前，这将包括cpu累计使用量、内存瞬时使用率、Pod磁盘使用量、容器的磁盘使用量
自定义指标 由Prometheus Adapter提供API custom.metrics.k8s.io，由此可支持任意Prometheus采集到的指标
服务监控项 在应用程序代码中明确定义(e.g. API server请求数量)。服务指标可以分为由Kubernetes基础架构组件生成的(因此对Kubernetes集群的操作有用)和用户应用程序生成的指标。用作HPA输入的服务指标有时称为自定义指标。HPA也使用核心指标
系统监控项和服务监控项都可以来自用户的容器或系统基础架构组件(API server、运行在Master中的插件以及用户节点上运行的插件)
扩展--自定义监控指标
场景 核心指标只包括Node、Pod的cpu、内存等，一般来说用作HPA已经足够了，如果想根据自定义的指标(例如QPS/5xx)来实现HPA，就需要使用自定义指标了。目前Kubernetes中自定义指标一般由prometheus来提供，再利用k8s-prometheus-adapter聚合到API Server，实现和核心(metrics-server)同样的效果
基于原生核心资源指标的HPA
Metrics Server 集群级别的核心资源使用聚合器，通过各个节点的/stats/summary接口提供的数据来收集节点和Pod的CPU和内存使用情况。Summary API是一种内存高效的API，用于将数据从kubelet/cAdvisor传递到Metrics Server
API Server 聚合 Metrics Server 提供的核心资源指标，通过metrics.k8s.io/v1beta1 API提供给HPA做自动扩缩
基于自定义指标的HPA
prometheus采集Pods(通常是/metricsAPI)监控指标存储到TSDB，使用k8s-prometheus-adapter提供的扩展kubernetes custom metrics API
# example 新建一个HPA 以http_requests为度量指标，阈值设置为10
# 当qps超过阈值触发自动扩缩(pod副本数2个～10个)
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: qps-hpa
spec:
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: qps-hpa
minReplicas: 2
maxReplicas: 10
metrics:
- type: Pods
pods:
metricName: http_requests
targetAverageValue: 10
小结
有些场景下不仅需要依赖CPU/内存使用指标来满足SLA，大多数Web需要基于每秒请求进行自动扩展以处理任何流量突发; 对于批处理应用程序，可以通过队列长度超过某个阈值等来触发HPA; 通过使用Prometheus检测应用程序并Expose自动扩缩指标，可以动态调整应用程序，以更好地处理流量兔子确保高可用性
