Metrics Server

参考文献：Metrics Server

Resource Metrics API致力于提供一流的Kubernetes API(稳定的、版本化的、可发现的、通过apiserver和客户端支持可用的)，为pods和节点提供资源使用指标。我们讨论了用例，并在不久前的另一个提案中提出了API。本文描述了此工作的第二部分的体系结构和设计:以与其他Kubernetes API相同的方式提供所提到的API。

可伸缩性限制

我们希望从集群中运行的每个pod和节点收集最多10个指标。从Kubernetes 1.6开始，我们支持5000个节点集群，每个节点有30个pod。假设我们希望收集粒度为1分钟的指标，这意味着:

10 x 5000 x 30 / 60 = 25000 metrics per second by average

Kubernetes apiserver将所有Kubernetes资源保存在其键值存储etcd中。它不能处理这样的负载。另一方面，度量指标往往变化频繁，是暂时的，如果失去了它们，我们可以在下一个内务操作中收集它们。我们将把它们存储在内存中。这意味着我们不能重用主apiserver，而是引入一个新的度量服务器。

当前状况

这个API已经在Heapster中实现，但是用户和Kubernetes组件只能通过主代理机制访问它，并且必须自己解码它。Heapster使用go http库提供API，该库不提供Kubernetes API服务器提供的许多功能，如授权/身份验证或客户端生成。还有一个使用泛型apiserver库的Heapster原型。
API在alpha中，并且有一个将其升级到beta(然后升级到GA)的计划，但是这超出了本文的范围。

依赖

为了让metrics服务器以与常规Kubernetes API完全相同的方式对用户可用，我们需要一种机制，将请求从apiserver重定向到metrics服务器的/apis/metrics 端点。这个问题的解决方案是kube-aggregator。Kubernetes 1.7版本的开发工作正在按部就班地进行。以前metrics服务器在此依赖项上被阻塞。

设计

Metrics server将按照Kubernetes monitoring architecture实现，并受到Heapster的启发。它将是一个集群级组件，定期从Kubelet通过摘要API服务的所有Kubernetes节点中提取指标。然后，度量标准将被聚合、存储在内存中(请参阅可伸缩性限制)，并以metric标准API格式提供服务。Metrics服务器将使用apiserver库实现http服务器功能。该库提供常见的Kubernetes功能，如授权/身份验证、版本控制、支持自动生成的客户机。为了在内存中存储数据，我们将通过引入内存存储来替代默认存储层(etcd)，它将实现存储接口。只有每个度量的最新值才会被记住。如果用户需要访问历史数据，他们应该使用第三方监控解决方案或自己归档度量(在前面提到的远景中有更多的细节)。由于指标存储在内存中，一旦重新启动组件，所有数据都会丢失。这是一种可以接受的行为，因为在重新启动之后不久，将收集最新的指标，不过我们将尽量减少这种行为的优先级(参见部署)。

部署

因为metrics server是许多Kubernetes组件(HPA、scheduler、kubectl top)的先决条件，所以默认情况下，它将在所有Kubernetes集群中运行。Metrics服务器出于安全原因(我们的策略只允许反向连接)发起到节点的连接，因此它必须在用户的节点上运行。每个集群中只运行一个metrics服务器实例。为了处理high metrics volume，metrics服务器将由addon-resizer垂直自动伸缩。我们将测量它的资源使用特性。我们对Heapster的分析经验表明，它可以有效地垂直伸缩。如果我们达到性能限制，我们将考虑水平扩展它，尽管它相当复杂，超出了这个文档的范围。Metrics服务器将是Kubernetes addon，由kube-up脚本创建，由add -manager管理。因为有许多依赖的组件，所以它将被标记为一个关键的附加组件。将来，当优先级/抢占特性被引入时，我们将迁移到使用这种适当的机制将其标记为高优先级的系统组件。