一文教你如何在生产环境中在Kubernetes上部署Jaeger
翻译 | 火火酱~
责编 | 晋兆雨
出品 | CSDN云计算
日志、指标和跟踪是“可观察性”领域的三大支柱。最近几个月，随着OpenTelemetry标准化以及Jaeger开源项目从CNCF孵化项目中顺利毕业，分布式跟踪领域出现了很多创新。
根据DevOps Pulse最近的报告可知，在实施分布式跟踪时，有超过30%的人会选择使用Jaeger。许多公司都已经认识到：要想使系统获得更好的可观察性并解决各类性能问题（特别是在处理复杂的微服务体系结构时），实施分布式跟踪是非常有必要的。
就Jaeger而言，首先要检测你的代码，将跟踪发送给Jaeger。然后设置Jaeger后端来收集、处理并可视化追踪。在本文中，我将介绍如何在生产环境中部署和管理Jaeger后端，内容主要涵盖：
Jaeger安装组件
Jaeger使用的非Jaeger组件，例如后端存储
Jaeger Deployment部署策略, 特别是围绕生产系统的部署策略
代理（Agent）vs. 无代理（Agentless）
agent安装方法：sidecar vs. DaemonSet
安装工具：Manual、Operator、Helm chart
在部署Jaeger Tracing时，我们需要用到以下组件：
代理（Agent）组件与应用程序处于同一位置，用于在本地收集Jaeger跟踪数据。它负责Collector（见下文）的连接和流量控制以及数据丰富工作。
收集器（Collector）是一个集中式集线器，从agent那收集跟踪信息，并发送到后端进行存储。collector可以在span上进行验证和丰富。
查询（Query）检索跟踪并通过UI进行展示
当然，以上每个组件展开来讲的话都要讲上几天几夜，而且也有其他的Jaeger组件可供选择，但为了便于讨论，我们就不展开介绍了。在下文中，我们将深入了解一下如何在各种设置和策略中部署Agent、Collector和Query组件。
根据部署策略的不同（详见下文），Jaeger可能会用到其他（非Jaeger）组件，主要是持久化后端存储（Elasticsearch、Cassandra或其他）和流式传输队列（Kafka）。这些服务通常都是独立部署的，你只需将Jaeger指向相关的端点即可，不过也可以让Jaeger自行提供这些服务。
如果你想将Jaeger部署在多个不同的系统上（例如自己用于开发的笔记本电脑或者大规模和高负载生产环境）的话，这里有一些可供选择的部署策略：
jaegertracing All-in-One：该设置易于部署，非常适合试用产品、开发和演示使用。你可以将其作为预打包的二进制文件或Docker镜像运行。它所有服务与内存存储都被打包并部署在一个副本中。
Production：专注于高可用性和可扩展性的生产环境需求。所有后端服务都进行独立部署，并支持多个副本和扩展选项。它还使用持久化后端存储来保持跟踪数据的弹性。目前它支持Elasticsearch和Cassandra存储解决方案，并将Elasticsearch作为生产环境的推荐解决方案。
Streaming：对于高负载环境而言，这种设置可以将Kafka添加到生产部署策略中，从而减轻后端存储的压力。如果你需要在跟踪上运行后处理逻辑的话，它在写入存储之前便可以轻松执行。
该一体式设置很容易上手，并且附带了捆绑包。如果你想试用一下的话，可以参阅下方教程，了解如何将其与Elasticsearch后端以及Kibana结合使用。
（教程链接：
https://logz.io/blog/jaeger-and-the-elk-stack/?ref=hackernoon.com）
接下来，我将重点介绍生产环境的部署，以及在这个过程中需要考虑的事情和选择。
agent需要驻留在应用程序的实例中。如果你运行着复杂的微服务架构，需要多个agent的话，或许会想了解Jaeger是否可以在无代理的情况下运行。
简而言之：不要这样做。
从技术上展开来讲，我们确实可以让Jaeger客户端库直接将span数据发送到Collector，但是这需要我们自己来处理各方面的问题，如collector的查找、流量控制、以及根据本地系统信息用附加元数据标记span。
虽然推荐使用Jaeger Agent进行部署，但在某些情况下是不能部署agent的。例如，如果你的应用程序以AWS lambda函数或类似的无服务器框架方式运行，无法控制pod部署和agent共存的话，就不能部署agent。如果使用Zipkin的话，agent也是无效的。在这种情况下，应该将span直接提交给Jaeger Collector。
agent需要与应用程序放在一起，这样Jaeger客户端库便可以在localhost上对其进行访问，并通过UDP向它发送数据，而不必承担因网络中断而导致数据丢失的风险（与TCP不同，UDP传输协议中不包含数据丢失保护，但也因此更快、更经济）。
要在Kubernetes环境中实现这一点可以采取两种方法：sidecar或daemonset。下面我们一个个来看：
DaemonSet
以DeamonSet方式来安装agent是最简单，也是最经济的选择。该方法会在节点上提供一个Agent实例，为该节点上的所有pods提供服务。
但是，对于涉及多租户、安全隔离需求或针对不同应用程序的多个Jaeger实例的生产环境来说，这种策略可能过于简单。在这种情况下，你可以考虑以Sidecar模式进行部署。
Sidecar
这种方法是将agent作为各个pod的附加容器运行。此设置可以支持多租户环境，其中每个租户都有各自的Jaeger Collector，并且可以配置agent将其发送到相关的Collector。
你还可以对内存分配进行调控，防止特定租户占用内存。在同一个pod中运行时，安全性配置则更简单。sidecar方法自带额外容器。一些安装工具可以自动注入agent sidecar并简化管理。
既然我们已经了解了需要部署的组件以及策略，那下面就来看一下有哪些工具可以帮助我们将计划付诸实践吧：
手动使用kubectl：如果你想快速入门，又不想为自动化而烦恼的话，这应该很适合你。但对于生产部署来说，还是不太建议这样做。这是Jaeger社区推荐的官方方式，下方链接中提供了完善的YAML模板。然而，它已于2020年5月被弃用。手动执行的另一选择是使用Jaeger Operator生成静态清单文件:运行Jaeger Operator generate生成YAML，然后运行kubectl apply将其手动应用到你的环境中。该功能目前尚处于实验阶段，因此使用时需要十分谨慎。
（链接：
https://github.com/jaegertracing/jaeger-kubernetes?ref=hackernoon.com）
Kubernetes Operator：Jaeger Operator让Kubernetes实现了热门的Operator模式，因此你可以让指定的Controller作为自定义资源管理Jaeger后端。它将默认部署Jaeger Agent为sidecar。如果你在集群中运行控制器的话，Jaeger Operator还可以自动注入Jaeger Agent sidecar，省去了手动定义的麻烦。你还可以将agent策略设置为DaemonSet。需要注意的是，Jaeger Operator在使用基于gRPC插件的外部持久化存储时的表现似乎差强人意。如果你属于此类情况的话，或许可以试一试Helm。更多详细信息请参阅下方Jaeger Operator repo链接。
（Jaeger Operator repo：
https://github.com/jaegertracing/jaeger-operator?ref=hackernoon.com）
Helm Chart：它具备完整程序包管理器的优点，如果你使用Helm来管理生产环境中的其他应用程序（如Jaeger使用的持久化存储）的话，那么它将是你不二之选。你可以在下方链接中找到官方的Jaeger图表，但需要注意它仍然是测试版。它将默认以DaemonSet方式来安装Jaeger Agent。此外，你也可以使用Helm来安装Jaeger Operator。
（链接：
https://github.com/jaegertracing/helm-charts?ref=hackernoon.com）
至此，我们一直都在讨论Jaeger span。但其实有很多系统使用的都是Zipkin instrumentation，因此需要注意，Jaeger同样也接受Zipkin格式的span，即Thrift、JSON v1/v2和Protobuf。
如果你Jaeger后端部署的目的是接收Zipkin协议的话：
Jaeger Agent与收集Zipkin span无关。
你的Zipkin instrumentation 应该直接将Zipkin span发送给Jaeger Collector。Zipkin span可以通过POST请求提交到以下RESTful端点：
/api/v1/spans for Zipkin JSON v1 或 Zipkin Thrift
/api/v2/spans for Zipkin JSON v2将Jaeger Collector配置为在指定的HTTP端口上接收Zipkin span，标志是–collector.zipkin.http-port=9411（Zipkin collector使用9411端口）。
Jaeger是Kubernetes领域中的新项目，强大的社区为Kubernetes部署提供了最佳的实践和自动化。但是，作为一个年轻项目，它在生产环境中的使用和效果仍在不断优化完善。我们在应用时，要紧跟社区更新，并且多方考量，找到最适合自己需求的运行方式。
原文链接：https://hackernoon.com/a-guide-to-deploying-jaeger-on-kubernetes-in-production-0p2n3tub
本文由CSDN云计算翻译，转载请注明出处
更多阅读推荐