Kubernetes monitoring architecture

原文: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/monitoring_architecture.md

执行摘要

监控被分为两条流水线:

  • 一个 核心指标流水线(core metrics pipeline), 由 kubelet, 一个资源估计器(resource estimator), 一个精简过的 Heapster 叫做 metrics-server, 和提供核心 metrics API 服务的 API server 构成. 这些指标(metrics)会被核心组件所用到, 比如调度逻辑(例如: 调度器和水平扩展器(horizontal pod autoscaling/HPA)会基于系统指标), 和一些开箱即用的简单 UI 组件(例如: kubectl top). 这个流水线不适用于与第三方监视系统集成
  • 一个 监控流水线被用于采集各种指标, 并展示给终端用户, 同时也会通过适配器给水平扩展器(为自定义的指标)和基础设施. 用户可以从很多中监控系统中选择, 也可以完全不使用. 在开源中, kubernetes 不会附带任何监控流水线, 但是第三方的选择是便于安装的. 我们希望这类流水线通常由每个节点上的 Agent 和一个集群级别的聚合器(aggregator)组成.

该体系结构在本文档附录的图表中进行了说明.

介绍和目标

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

术语

指标有两种, 系统指标和服务指标. 系统指标是通用指标, 通常可以从每个被监控的实体中获取(例如: Node 和容器 CPU 和内存用量). 服务指标是在应用代码中明确定义和暴露的(例如: API 500 错误的数量). 系统指标和服务指标都可以从用户的的容器或系统的基础设施组件(像 API server 这样的核心组件, master 节点上的附加 pods, user 节点上的附加组件)中产生.

我们把系统指标分为:

  • core metrics, 核心指标, 这些是 Kubernetes 理解并用于内部组件和核心实用程序操作的指标, 例如, 指标会用于调度(包括资源预估算法的输入, 初始化资源/垂直自动伸缩, 集群自动伸缩, 和不包含自定义指标的水平 Pod 自动伸缩), kube dashboard, 和kubectl top.

  • non-core metrics, 非核心指标, Kubernetes 不会解释;我们通常理解为他们包括核心指标(尽管不一定是 Kubernetes 理解的格式)加上附加的指标.

服务指标(service metrics)被分为由 Kubernetes 基础组件产生的(对于 Kubernetes 集群的运维是有用的)和由用户应用产生的. 用作水平 Pod 自动缩放的输入的服务指标有时称为自定义指标. 当然, 水平 Pod 自动伸缩也使用核心指标.

我们认为日志记录与监视是分开的, 因此日志记录不在本文档的讨论范围之内.

要求

监控架构应该(should):

  • 包含 Kubernetes 一部分核心的解决方案, 而且
    • 使关于节点, pods 和容器的核心系统指标能够被标准的 master API (现在被称为 metrics API)获取到, 这样一些核心的 Kubernetes 特性就不会依赖于非核心组件
    • 要求 kubelet 仅导出一组有限的指标, 即核心 Kubernetes 组件正确运行所需要的指标(和#18770有关)
    • 能够扩展到至少 5000 个节点
    • 足够小, 我们可以要求其所有组件都能够在所有部署配置中运行
  • 包含一个开箱即用的方案, 能够提供历史数据, 例如: 支持初始资源和垂直 Pod 自动伸缩, 也支持集群分析查, 这只依赖于核心 kubernetes.
  • 允许 kubernetes 外的第三方监控方案, 能够和需要 service metrics 的组件例如自动伸缩器 HPA 做集成

架构

我们将我们描述的长期架构计划分成 核心指标流水线 和 监控流水线. 二者都需要考虑如何处理来自于 master 和 minions 的各种数据(core metrics, non-core metrics, service metrics).

核心指标流水线

核心指标流水线采集了一些列的核心系统指标. 这些指标有两个来源:

  • Kubelet, 提供了 per-node/pod/container 的用量信息(当前作为 Kubelet 的一部分, cAdvisor 将会被精简, 只提供核心系统指标)
  • 资源估计器(resource estimator), 以 DaemonSet 运行, 将从 kubelet 采集到的原始用量数据转换为资源估计(来用于 scheduler 进行基于用量的高级调度的值).

这些资源会被一个称谓 metrics-server 的组件采集, 它像是一个当下 Heapster 的精简版本. metrics-server 会本地存储最新的值, 而且它没有下游. metrics-server 暴露了 master metrics API.(这里说到的配置很像运行在”standalone”模式下的 Heapster).Discovery summarizer使 master metrics API 能被外部客户端访问到, 从客户端的角度来看, 这和直接与 API server 是一样的.

Core(system) metrics 在所有部署环境中都会以上述的方式处理. 唯一容易替换的部分是 resource estimator, 可能会被高级用户替换. 从理论上说, metric-server 也是可被替换的, 但是这和替换 api-server 或者 controller-manager 一样, 不推荐也不会提供支持.

事实上, 核心指标流水线也可能会从 kubelet 和 dockerd 采集数据(例如: kubelet 的 CPU 用量), 即使他们没有运行在容器中.

核心指标流水线是有意设计成小巧, 而且没有为三方采集做设计. “成熟”的监控交由第三方系统负责, 它会提供监控流水线(看下个章节), 而且能够运行在 kubernetes 上并且不需要更改任何上游组件. 因此我们可以消除由维护 Heapster(作为一些可能的 metircs 来源, sink, 特性的集成点) 带来的负担.

Infrastore

我们将构建一个开源的 Infrastore 组件(基本上是复用现有技术)用来提供从 master API 获取到的 core system metrics 和 事件 的历史查询服务. Infrastore 将会暴露一个或多个 API(可能是一个类 SQL 查询 – 还未确定)来处理一下的用例:

  • 初始资源
  • 垂直自动缩放
  • oldtimer API(没有找到太多资料, 看上去是历史数据)
  • 用于调试,容量计划等的决策支持查询
  • Kubernetes Dashboard中的用量图

总之, 它 kennel 会采集监控指标和服务指标(至少从 kubernetes 基础设施的容器采集), 正如接下来的章节中所描述的那样.

监控流水线

如上个章节所描述的, 为 core metrics 构建一个单独的监控流水线的目标之一是分出一个非常灵活的 监控流水线, 因为核心 kubernetes 组件不需要依赖它. 默认我们不会提供一个, 但是我们会提供一个简单的方式能够让你装一个(使用一条命令, 就像用 helm 一样). 我们将会在这个章节描述这个 监控流水线.

由 监控流水线 采集的数据可能包括以下几组指标的超集或者子集:

  • core system metrics
  • non-core system metrics
  • 用户应用容器的 service metrics
  • kubernetes 基础容器的 service metrics; 这些 metrics 是由 prometheus 暴露的

由监控方案来决定哪些是会被采集的.

为了启用依赖于 custom metrics 的 horizontal pod autoscaling, monitoring pipeline 的提供者也应该创建一个无状态 API 适配器, 从 monitoring pipeline 中拉 custom metrics, 并且暴漏给 Horizontal Pod AutoScaler. 这些 API 需要是被良好定义的, 版本化的, 就像常用的 API 那样. 它如何被暴露或者被发现需要在这个组件的详细设计中覆盖到.

同样的方法适用于,如果期望 monitoring pipeline 的数据也能在 Infrastore 中获取. 这个适配器可以是一个单独的组件, 库, 或者是监控方法的一部分.

有很多可能的节点/集群级别的 agent 的组合, 都能够组成一个 monitoring pipeline, 包括 cAdvisor + Heapster + InfluxDB(或者使用其他下游)

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

作为示例, 我们将描述与 cAdvisor + Prometheus 的潜在集成.

Prometheus 在 node 上有以下的几个指标来源:

  • 来自于 cAdvisor 的 core and non-core system metrics
  • 容器以 Prometheus 格式暴露的 service metrics
  • [可选] 组件自己上运行的 node_exporter

所有这些都会被 prometheus cluster-level agent 所获取. 我们可以使用一个独立的 API 适配器, 将 HPA 定义的 API 转为 PromQL, 来使用这个 prometheus cluster-level agent 作为 HPA custom metric 的来源. 同样 Infrastore 从 monitoring pipeline 中获取数据也是做一样的事情. 如果用户不需要这些特性, 则适配器是不需要的.

安装 cAdvisor + Prometheus 的命令还应该自动设置来自基础结构容器的指标集合. 之所以可能这样做, 是因为基础架构容器的名称和感兴趣的指标是 Kubernetes Control Plane 配置本身的一部, 并且因为基础架构容器以 Prometheus 格式暴露了其指标.

附录: 架构图

开源的监控流水线

Architecture Diagram