令人惊讶的是，Kubernetes发送了这么多数据。默认情况下，带有Prometheus的简单三节点Kubernetes集群将提供约40000个活动系列！我们真的需要所有这些数据吗？

现在是时候谈谈监控Kubernetes的潜在挑战了。困难不仅包括度量数据的膨胀和可用性，还包括pod度量的高搅动率、运行多个部署时的配置复杂性等。

让我们深入看看Kubernetes监控。

开箱即用的默认度量

Prometheus如此受欢迎的原因之一是易于开始收集度量。大多数工具和项目都以OpenMetrics格式公开度量，所以你只需要打开它，然后安装Prometheus服务器即可开始抓取这些度量。

标准安装路径Prometheus Operator安装用于监控Kubernetes的附加组件，如kube状态度量、节点导出器和cAdvisor。即使使用默认的Prometheus Operator来监控一个小型的3节点Kubernetes集群，也会产生大约40000个不同的度量。这是起点，而且是在添加任何应用性或自定义度量之前。

这个数字还在快速增长。 VictoriaMetrics的CTO Aliaksandr Valialkin表示，自2018年以来，Kubernetes暴露的度量数量增加了3.5倍。这意味着用户被来自Kubernetes的监控数据淹没。真的需要所有这些度量吗？

一点也不！事实上，这些指标中的绝大多数都没有在任何地方使用。Valialkin表示，这些度量中有75%从未在任何仪表盘或警报规则中使用。

真正需要的度量

度量需要可用。如果你不采取行动，就不要收集它们。这一点在托管Kubernetes解决方案中更为明显——在该解决方案中，最终用户无论如何都不会管理底层系统，因此许多公开的度量对他们来说根本不可用。

这促使一些供应商编写了推荐度量，这些度量是从自托管的Kubernetes或从EKS、AKS和GKE等托管Kubernete服务中收集的重要Kubernets度量。

然而，我们不能依赖单个供应商来创建这样的集合。而且大多数最终用户对各种度量不够熟悉，无法确定自己需要什么，所以他们会寻找默认值，更喜欢收集所有信息的最安全的方式，以免以后缺少重要数据。

Kubernetes和云原生社区、供应商和最终用户应该走到一起，共同为每个组件定义一组标准的黄金度量。Valialkin还认为，“第三方监控解决方案不应安装额外的组件来监控Kubernetes本身”，指的是kube状态度量、节点导出器和cadvisor等额外组件。他建议“所有这些来自这些伙伴的指标都应该包含在Kubernetes本身中。”

笔者还要补充一点，我们应该考虑删除未使用的标签。我们真的需要Prometheus节点导出器提供每个网卡或CPU核心的详细信息吗？每个标签为度量添加一个维度，并与时间序列数据指数相乘。

微服务激增

Kubernetes用容器把大规模打包、部署和管理复杂的微服务架构变得容易。微服务数量的增长导致监控系统的负载增加：每个微服务都会暴露系统度量，如CPU、内存和网络利用率。除此之外，每个微服务都会根据其实现的业务逻辑公开自己的一组应用程序度量。此外，还需要监测微服务之间的网络延迟、RPS和类似指标。微服务的激增会产生大量的遥测数据，这可能会变得非常昂贵。

pod的高搅动率

人们转向Kubernetes是为了变得更加敏捷和更频繁地发布。这导致了新版本微服务的频繁部署。在Kubernetes中的每一次部署中，都会创建和删除新的pod实例，这就是所谓的“pod搅动”。新的pod会获得一个唯一的标识符，与以前的实例不同，即使它本质上是同一服务实例的新版本。

笔者想在这里澄清一下关于度量的一个要点。度量数据是时间序列数据。时间序列由度量名称和一组标记值唯一定义。如果其中一个标签值发生更改，则会创建一个新的时间序列。

回到短暂pod，许多从业者在他们的度量时间序列数据中使用pod名称作为标签。这意味着，随着每一次新的部署和相关的pod搅动，旧的时间序列停止接收新的样本并被有效地终止，而新的时间序列被启动，这会导致逻辑度量数据序列的不连续性。

Kubernetes工作负载通常具有较高的pod搅动率，这是由于频繁部署新版本的微服务，以及基于传入流量自动缩放pod，或者底层节点上的资源限制需要驱逐和重新调度pod。度量时间序列的不连续性使得很难对逻辑服务进行连续监控，也很难分析它们各自度量随时间的变化趋势。

一个潜在的解决方案可以是使用ReplicaSet或StatefulSet ID作为度量标签，因为在集合添加和删除pod时，这些ID保持不变。然而，Valialkin称这在某种程度上是一种黑客攻击，他说我们应该作为一个社区推动在Kubernetes监控中使用一级公民命名法，以提供一致的命名。

多重部署的配置复杂性

组织通常运行数百甚至数千个不同的应用程序。当这些应用程序部署在Kubernetes上时，会产生成百上千的部署配置，以及多个Prometheus scrape_config配置，这些配置定义了如何刮取（拉取）这些度量、规则、要应用的过滤器和重新标记、要刮取的端口和其他配置。在规模上管理成百上千种不同的配置可能很快变得难以管理。此外，它可能会给Kubernetes API服务器带来负担，后者需要在所有这些不同的配置上提供请求。

作为一个社区，我们可以在Prometheus服务发现机制的基础上，从Kubernetes中部署和pod的服务发现标准中受益。在Valialkin的设想中，“在大多数情况下，Prometheus或其他监控系统应该自动发现所有部署，所有需要抓取的pod，以收集指标，而无需为每次部署编写自定义配置。只有在某些特殊情况下，当你需要自定义某些东西时，你才能为抓取编写这些自定义定义。”