你是否有效地追踪Kubernetes应用程序？

客座文章作者：Leonid Sandler，ARMO 首席技术官和联合创始人

与日志记录和可观察性一样，分布式追踪是保持服务健康和可预测的关键功能。与日志和可观察性（显示服务上发生了什么）相反，追踪允许开发人员和操作人员遵循特定的请求，以及它如何调用不同的服务和依赖关系。它是围绕微服务架构设计的，而微服务架构不同于单体架构，它使用许多小型服务来运行一个平台。这些服务彼此通信，也与外部服务通信，以提供和存储用户请求的信息。

与单体架构比较，使用微服务当然有它的好处：

• 更容易维护：这是因为它简化了开发、测试和部署。
• 更具伸缩性：你可以增加或减少服务实例的数量，而不涉及系统的其他部分。

缺点是它还减少了错误和瓶颈检测功能，使得检测请求失败的原因和地点变得更加困难。

分布式追踪通过监视请求和服务之间的数据交换来简化检测，从而解决了这一问题（参见图 1）。收集的数据然后提供请求失败或变慢的服务的信息。

图 1：Jaeger UI 显示请求的轨迹（来源：Jaeger）

Kubernetes 是当今最流行的微服务平台之一。这个容器协调器允许你轻松地管理多个服务器/节点，这些服务器/节点运行着使用简单的声明性语言部署的几十个服务。

在下一节中，我们将介绍几种流行的分布式追踪解决方案，并展示它们在 Kubernetes 环境中的工作方式。

Kubernetes 分布式追踪解决方案

Kubernetes 中有一些工具可用于实现分布式追踪，每个工具提供不同的功能。在这里，我们回顾了几个使用 Kubernetes 的最流行的分布式追踪平台，涵盖了各种各样的工具：

• 成熟的 Zipkin 工具
• Jaeger 是对 Zipkin 概念的一种更现代的方法
• Grafana Tempo，与前两种相比以一种完全不同的方式存储数据
• 一个托管服务，AWS X-Ray

Jaeger

Jaeger[1]是一款最初由 Uber 开发的开源分布式追踪工具。它被设计成在生产中运行，性能受到的影响很小。它有许多可移动的部分（参见图 2），这有助于增加吞吐量，但可能会使部署复杂化。这些包括副载代理、Kafka 服务、数据库等。

图 2：Jaeger 流架构（来源：Jaeger）

每个服务都必须通过使用一个受支持的库修改其源代码来插装，不过也有一些针对其他平台的非官方库。这些客户端基于 OpenTracing API，并被设计为在生产中始终启用。但是追踪确实会带来计算成本，而且必须对数据进行采样，这样才不会影响整体性能。

默认情况下，Jaeger 客户端采样 0.1%的追踪，并且能够通过 Jaeger 中央后端应用正确的采样策略，而不需要为其每个服务进行特定的配置。

Jaeger 的文档中有一整节都是关于在 Kubernetes 进行部署[2]，所以部署一个简化版本并不难。Jaeger 的特点是在部署之前必须安装和配置 Kubernetes 操作器，并提供了三种部署策略：

• AllInOne是为测试目的而设计的。所有服务都部署到一个单独的 Pod 中，并使用内存存储。缺点是它不能提供可伸缩性，也不可靠。
• Production支持具有多个副本和持久存储的更可靠和性能的分布式追踪应用程序；它还支持 Elasticsearch 或 Cassandra。
• Streaming本质上是一种改进的 Production 策略，其中 Kafka 服务用于数据摄取。这减少了对存储的压力，允许改进查询和数据可视化。

图 3：Jaeger Kubernetes 生产部署（来源：Jaeger）

上述三种策略都需要一个代理作为 sidecar 服务，它可以连接到插装库并将追踪数据推送到收集器。每个部署都需要一个“sidecar.jaegertracing.io/inject”: “true”的注释指示 Jaeger 操作器将观察部署。请注意，此特性仅用于部署（Deployment），而其他类型的 Kubernetes 组件（例如 Pod 和 ReplicaSet）必须手动安装代理。

Zipkin

Zipkin[3]最初受到谷歌 Dapper 的启发，最初由 Twitter 开发，现在是一个拥有专门社区的 OSS 组织。它具有与 Jaeger 相似的功能和需求。与 Jager 相比，Zipkin 有一个更简单、非分布式的架构，简化了部署。但是，它的伸缩性不如 Jaeger，因为所有的服务都构建在同一个工件中。图 4 说明了 Zipkin 设计架构。

图 4：Zipkin 架构（来源：Zipkin）

作为比 Jager 更古老的服务，Zipkin 通过官方和社区支持的库提供了比 Jaeger 更多的支持语言和平台。另一方面，采样依赖于没有中心配置或一致性的客户端库。库有自己的策略和配置属性来定义如何对数据进行采样，Zipkin 存储它接收到的所有数据。

虽然 Zipkin 没有提供一种明确定义的部署在 kubernetes 上的方式——既不是为代理也不是为它的服务——但它为它的服务提供了一个 Docker 镜像，你可以很容易地在你的环境中运行。镜像可以在内存中运行所有内容，或者使用 Cassandra、MySQL 或 Elasticsearch 等外部存储。但是，它不支持多个 Zipkin 实例，因此可伸缩性受到限制。

也没有代理/边车。相反，所有内容都必须在应用程序客户端库中配置。这意味着人工操作人员要做更多的工作，因为每个库和平台可以有不同的配置属性。使用配置提供者（如 Kubernetes ConfigMap）可以在一定程度上帮助解决这些问题，但是被检测的应用程序必须与服务兼容。

Grafana Tempo

Grafana Tempo[4]于 2020 年宣布，是一个新的竞争者，旨在解决与其他分布式追踪工具的特定问题，特别是使用大型服务器和数据采样的困难。其他系统通过索引追踪数据花费了太多的资源，这导致了更高的成本和需要复杂的存储系统（例如 Cassandra 或 Elasticsearch）。虽然这些系统能够处理大量数据，但要部署一个大型集群，你需要支付更多的费用。

另一方面，Grafana Tempo 依赖于对象存储服务（例如 Amazon S3），并使用其查询引擎来发现追踪信息，这也被其他 Grafana 服务所使用。因此，虽然存储成本更低，但查询成本更高，因为消耗的时间和使用的 CPU 资源更多。参见下面图 5 中的 Grafana Tempo 架构。

图 5：Grafana Tempo 设计架构（来源：Grafana）

虽然 Grafana Tempo 平台出现的时间不长，但它有一组支持良好的库，可以使用 Jaeger、OpenTelemetry[5]或 Zipkin 现有的客户端仪表库。

Tempo 通过收集所有生成的数据来工作。这对于调试来说很好，但是在捕获数据时可能会导致性能问题。通过使用 Jaeger 或 OpenTelemetry 库，你可以手动配置采样。

尽管是一个新项目，但它没有为 Kubernetes 的部署提供任何特别的东西。安装将需要在集群上部署以下服务。这些额外的服务是否增加了部署成本或限制了客户选择其他监视工具的灵活性？

• Tempo backend
• Tempo-query engine
• Prometheus
• Grafana

至于存储，你所需要的只是在任何云平台上都可以轻松获得的基本对象存储。Tempo 还监听几个端口，每个协议一个（见表 1），确保你使用可用的最佳的检测库：

表 1：可用的 Tempo 协议（来源：Grafana）

与 Zipkin 一样，没有代理或副负载服务来简化部署和配置。每个系统都必须有正确的配置，这增加了操作成本，需要一个中央配置存储库。

AWS X-Ray

AWS X-Ray 是一种托管服务，旨在对运行在 AWS Cloud 中的服务提供无缝分布式追踪。作为一个特定于供应商的工具，当涉及到外部服务时，它确实有一些限制。尽管如此，AWS 团队仍然为 MySQL 或 PostgreSQL 等自托管服务提供库和代理。

X-Ray 提供了 Go、Java、Node.js、Python、Ruby 和.Net 的库。与 Jaeger 一样，X-Ray 使用一个侧面加载的代理来连接并将追踪数据推送到后端。这样，你就可以避免在运行时将大型配置属性放入应用程序中，并将所有数据摄取转移到另一个服务。然而，在非托管环境中，它可能会增加更多的复杂性。

在 Kubernetes 中使用 X-Ray 非常简单，因为你不需要部署任何额外的后端服务或存储解决方案。代理可以像 Jaeger 一样安装为 Kubernetes DaemonSet（多亏了 Operator 操作器，Jaeger 提供了更简单的配置）。

总结

下面的表 2 显示了上述工具从 A（最好）到 C（最差）的四个类别的比较：

• 成熟度：评估工具的稳定性和可预测性
• 配置：显示配置工具并将其投入生产的容易程度
• Kubernetes 特性：解释每个服务在 Kubernetes 环境下是如何匹配的
• 成本：部署解决方案的成本，包括各个方面（例如，存储服务）

表 2：服务比较

对于分布式追踪，有一些可靠的解决方案，并且新的解决方案正在出现，它们可以在不牺牲功能的情况下降低成本。不幸的是，Kubernetes 的支持仍然不够。

Jaeger 为使用 Kubernetes 提供了一些非常可靠的工具，AWS X-Ray 可以很容易地与 AWS 服务集成。至于 Zipkin 和 Grafana Tempo，它们都没有为 Kubernetes 提供标准化的解决方案。因此，操作人员需要为每个应用程序部署 Docker 镜像和特定配置。

除了考虑操作上的困难之外，你肯定还需要考虑实现这些解决方案的成本。在客户端，所有解决方案都依赖于嵌入式应用程序库，而有些还需要额外的代理。添加另一个库是一项耗时的任务，它将产品代码和基础设施代码结合在一起。这使得切换到另一个追踪工具变得困难（尽管大多数追踪工具是交叉兼容的）。这也需要大量的努力和专业知识，基本上是一项长期的承诺。

在后端，Jaeger 和 Zipkin 依赖传统的存储解决方案，其中索引是在摄入时建立的。当然，这大大增加了存储所有这些数据的成本。另一方面，Tempo 完全依赖对象存储，这是目前最便宜的云存储解决方案。

分布式追踪对于每个微服务架构都是必须的：它允许你快速检测问题，并提供有价值的见解，可以将响应时间从几个小时减少到几分钟。分布式追踪与 Kubernetes（当今最著名的微服务平台）相结合，为每个运营商提供了强大的工具集。

关于 ARMO

ARMO 正在通过 ARMO Kubernetes Fabric™ 创造 Kubernetes 安全的未来。它将安全性、可视性和控制注入到每个工作负载、容器和微服务中，从 CI/CD 流水线到其整个生命周期，并使上下文 Kubernetes 管理和主动运行时保护之间的强化循环。

访问我们的网站了解更多信息[6]，安排演示[7]，或者通过免费试用 ARMO[8]作为你的 Kubernetes 集群添加无缝保护的第一步。

参考资料

[1]

Jaeger: https://www.jaegertracing.io/

[2]

在 Kubernetes 进行部署: https://www.jaegertracing.io/docs/1.22/operator/

[3]

Zipkin: https://zipkin.io/

[4]

Grafana Tempo: https://grafana.com/oss/tempo/

[5]

OpenTelemetry: https://opentelemetry.io/

[6]

了解更多信息: https://www.armosec.io/

[7]

安排演示: https://www.armosec.io/schedule-a-demo

[8]

免费试用 ARMO: https://www.armosec.io/armo-sign-up