Core Metrics in kubelet

参考文献：Core Metrics in kubelet

简介：

定义

“Kubelet”:运行在每个kubernetes节点上的守护进程，控制pod和容器生命周期，以及许多其他东西。

“cAdvisor”:一个开放源码的容器监控解决方案，它只监控容器，没有像pod或volume这样的kubernetes构造的概念。

“Summary API”: 是一个kubelet API，它目前公开了供系统组件和监视系统使用的节点指标。

CRI:容器运行时接口，设计用于在运行时(docker、rkt等)上提供抽象。

“Core Metrics”:监视体系结构中描述的一组度量标准，其目的是为一流的资源隔离和利用特性(包括资源可行性检查和节点资源管理)提供度量标准。

“Resouces”:节点的可消耗元素(如内存、磁盘空间、CPU时间等)。

“First-class Resources”:对调度至关重要的资源，其请求和限制可以(或即将)通过Pod/容器规范进行设置。

“Metric”:一种资源消耗的度量/指标。

背景

监视体系结构（Monitoring Architecture）提案包含一组称为“核心度量标准”的度量标准的蓝图。此提案的目的是指定这些度量标准是什么，以便通过kubelet支持与度量标准的集合相关的工作。Kubernetes将cAdvisor提供给它的代码库，kubelet使用cAdvisor作为库，使它能够收集容器上的指标。然后，kubelet可以将来自cAdvisor的容器级指标与kubelet对kubernetes构造(例如pods)的知识结合起来，生成kubelet汇总统计信息，该统计信息为kubelet或用户通过Summary API使用提供指标。cAdvisor的工作方式是每隔一段时间(默认情况下是10秒)收集指标，然后kubelet只要需要就可以查询这些缓存的指标。

目前，cAdvisor收集了大量与系统和容器性能相关的指标。然而，kubelet summary API只使用了其中的一些指标，而很多指标都没有使用。kubelet Summary API发布到kubelet summary API端点(stats/ Summary)。summary API提供的一些指标由kubernetes系统组件使用，但其中许多指标的唯一目的是提供用于监视的指标。

动机（Motivations）

监视体系结构提案解释了为什么需要单独的监视管道。

通过发布核心度量标准，kubelet就不必为监视提供度量标准了。第三方监视管道还可以免除向系统组件提供这些指标的任何责任。

cAdvisor的结构是按一定的时间间隔收集指标，这对于独立的指标收集器是合适的。然而，kubelet中的许多函数是延迟敏感的(例如，回收)，并且可以从更“随需应变”的度量集合设计中获益。

提案（Proposal）

此提案使用由kubelet收集的这组核心度量标准，并仅由kubernetes系统组件使用，以支持“First-Class Resource Isolation and Utilization Features”。这个提案不是设计成由kubelet发布的API，而是由kubelet收集的一组度量标准，这些度量标准将被转换，并在将来发布。

这组指标的目标“用户”是kubernetes组件(尽管不一定是直接的)。这组指标本身并不是设计为面向用户的，而是设计为足够通用以支持面向用户的组件。

设计

这种设计只覆盖了核心度量管道中包含的度量。设计的高级需求如下:

kubelet收集尽可能少的指标，以提供“First-Class Resource Isolation and Utilization Features”。

可以“按需”获取指标，为kubelet提供更多最新的统计数据。

此提案有意省略了许多最终可能成为核心度量标准的度量标准。这是故意的。一旦需要度量来支持一流的资源隔离和利用特性，就可以将它们添加到核心度量API中。

指标要求（Metric Requirements）