参考文献: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)