Kubernetes monitoring architecture

参考文献：Kubernetes monitoring architecture

概要

监控分为两个管道（pipelines）:

Core metrics pipeline 包括 Kubelet, 一个资源评估器，精简化的Heapster（也称作metric-server）和服务于master metrics API的API服务器。这些指标用于核心系统组件，例如调度逻辑(例如调度程序和基于系统指标的水平pod自动伸缩)和简单的开箱即用UI组件(例如kubectl top)。此管道不打算与第三方监控系统集成。

 monitoring pipeline，用于从系统收集各种指标并将其公开给最终用户，以及通过适配器将其公开给水平Pod自动伸缩器(用于自定义指标)和次存储。用户可以从许多监视系统供应商中进行选择，或者根本不运行它们。在开源环境下，Kubernetes不会附带监控管道，但第三方选项很容易安装。我们期望这样的管道通常由每个节点代理和集群级聚合器组成。

介绍和目标

本文档为Kubernetes提出了一个高级监控架构。它涵盖了“Kubernetes监视体系结构”文档中提到的问题的一个子集，特别关注希望满足众多需求的体系结构(组件及其交互)。我们没有为实现该体系结构指定任何特定的时间框架，也没有为实现该体系结构指定任何特定的路线图。

术语

有两种度量，系统度量和服务度量（system metrics and service metrics）。系统度量是一般的度量，通常可从被监视的每个实体获得(例如，容器和节点对CPU和内存的使用)。服务指标在应用程序代码中明确定义并导出(例如，API服务器提供的服务数量为500)。系统指标和服务指标都可以来自用户的容器或系统基础设施组件(主组件，如API服务器、在主服务器上运行的附加pod，以及在用户节点上运行的附加pod)。

我们将系统度量分成两种情况：

核心指标（core metrics），这些指标Kubernetes理解和使用操作的内部组件和核心工具——例如,指标用于调度(包括输入资源估计的算法,初始资源/垂直自动定量、集群自动定量,和自动伸缩不包括自定义指标),kube dashboard,kubectl top。到目前为止，这包括cpu的累积使用、内存的瞬时使用、pod的磁盘使用、容器的磁盘使用。

非核心度量（non-core metrics），不是由Kubernetes解释的;我们通常假设它们包括核心指标(尽管不一定以Kubernetes能够理解的格式)和其他指标。

服务度量可以分为Kubernetes基础设施组件生成的度量(因此对Kubernetes集群的操作非常有用)和用户应用程序生成的度量。用于水平pod自动伸缩的服务度量有时称为自定义度量。当然，水平pod自动伸缩也使用核心指标。

我们认为日志记录与监视是分开的，因此日志记录超出了这个文档的范围。

要求

体系结构

Core metrics pipeline

核心度量标准管道收集一组核心系统度量标准。这些指标有两个来源:

Kubelet，提供每个节点/pod/容器的使用信息(目前属于Kubelet的cAdvisor将被精简，只提供核心系统指标)

一个以DaemonSet的形式运行的资源估计器，它将从Kubelet中提取的原始使用值转换为资源估计(调度程序用于更高级的基于使用的调度程序的值)

这些资源是由我们称为metrics-server的组件收集的，它就像当今Heapster的精简版。metrics-server只在本地存储最新的值，没有接收器。metrics-server公开master metrics API。(这里描述的配置类似于独立模式下的当前Heapster。)Discovery summary使master metrics API对外部客户端可用，因此从客户端角度看，它看起来与与API服务器对话一样。

核心(系统)指标在所有部署环境中都按照上面的描述进行处理。唯一容易替换的部分是资源估计器，它可以被高级用户替换。理论上，metric-server本身也可以被替换，但这类似于替换apiserver本身或controller-manager——可以，但不推荐也不支持。

最终，核心度量管道也可能从Kubelet和Docker守护进程本身收集度量(例如，Kubelet的CPU使用情况)，即使它们不在容器中运行。

核心度量标准管道故意设计得很小，并且不是为第三方集成而设计的。“全面的”监视由第三方系统负责，第三方系统提供监视管道(请参阅下一节)，可以在Kubernetes上运行，而无需对上游组件进行更改。通过这种方式，我们可以消除目前的负担，即维护Heapster作为每个可能的度量源、接收器和特性的集成点。

 Monitoring pipeline

如前一节所述，为核心度量标准构建专用的度量管道的目标之一是允许单独的监控管道，该管道可以非常灵活，因为核心Kubernetes组件不需要依赖它。默认情况下，我们不会提供一个，但我们将提供一种简单的方式来安装一个(使用一个命令，很可能使用Helm)。我们在本节中描述了监视管道。

监控管道收集的数据可能包含以下指标组的任何子或超集:

• core system metrics
• non-core system metrics
• service metrics from user application containers
• service metrics from Kubernetes infrastructure containers; these metrics are exposed using Prometheus instrumentation

由监视解决方案决定收集其中的哪一个.

为了启用基于自定义度量的水平pod自动伸缩，监视管道的提供者还必须创建无状态API适配器，该适配器从监视管道提取自定义度量并将其公开给水平pod自动伸缩器。这样的API将是一个定义良好的、版本化的API，类似于常规API。该组件的详细设计文档将介绍如何公开或发现该组件的详细信息。

如果希望在Infrastore中提供管道监控指标，也可以采用相同的方法。这些适配器可以是独立的组件、库或监视解决方案本身的一部分。

有许多可能的节点级和集群级代理的组合，它们可以组成监视管道，包括cAdvisor + Heapster +InfluxDB(或任何其他接收器)

• cAdvisor + collectd + Heapster
• cAdvisor + Prometheus
• snapd + Heapster
• snapd + SNAP cluster-level agent
• Sysdig

作为一个例子，我们将描述与cAdvisor +Prometheus的一个潜在集成。

Prometheus在节点上有以下度量源:

所有这些都是由Prometheus集群级别的代理进行投票的。我们可以使用Prometheus集群级代理作为水平pod自定义度量的源，方法是使用一个独立的API适配器，该适配器在Prometheus集群级代理上的Prometheus查询语言端点和特定于hpa的API之间进行代理/转换。同样，可以使用适配器使来自监视管道的指标在Infrastore中可用。如果用户不需要相应的特性，则这两个适配器都不是必需的。 

安装cAdvisor+Prometheus的命令还应该自动设置来自基础设施容器的指标集合。这是可能的，因为基础设施容器的名称和度量是Kubernetes控制平面配置本身的一部分，而且基础设施容器以普罗米修斯格式导出它们的度量。

• core and non-core system metrics from cAdvisor
• service metrics exposed by containers via HTTP handler in Prometheus format
• [optional] metrics about node itself from Node Exporter (a Prometheus component)

 Architecture diagram