Kubernetesr的Service Mesh（第7部分）：让分布式跟踪变得简单

Linkerd作为Service Mesh（微服务的中间件层）的角色，使其成为围绕系统性能和运行时行为的数据源。在多语言环境或异构环境中尤其如此，在这种环境中，对每种语言或框架进行检测是非常困难的。服务网格可以提供一个统一、标准的应用程序跟踪和度量数据层，而不是直接对每个应用程序进行测试，这些数据可以通过Zipkin（分布式系统监控系统）和Prometheus（开源的系统监控和报警工具）等系统收集。

在这篇文章中，我们将通过一个简单的例子来介绍一下Linkerd和Zipkin如何在Kubernetes（Google开源的容器集群管理系统）中协同工作以自动获得分布式跟踪，只需要对应用程序进行一些小小的修改。

本文是关于Linkerd，Kubernetes和Service Mesh的系列文章之一。本系列的其他部分包括：

1. Service的重要指标
2. 以DaemonSet方式运行linkerd
3. 加密所有的东西
4. 通过流量切换进行连续部署
5. Dogfood环境，入口和边缘路由
6. 简单轻松的分期微服务
7. 让分布式跟踪变得简单（本文）
8. 使用Linkerd作为入口控制器
9. 使用gRPC（Google主导开发的RPC框架）的乐趣和优势
10. Service Mesh的API
11. 出口
12. 重试预算，截止日期传播，且如何优雅失败
13. 通过顶级指标自动缩放

在本系列的前几篇文章中，我们向你说明了如何使用Linkerd来捕获顶级服务指标。服务指标对于确定单个服务的状况很重要，但是它们不能捕捉多种服务工作（或不工作）的方式来请求服务。想要看到更好的系统级性能，我们需要转向分布式跟踪。

在之前的文章中，我们介绍了分布式跟踪的一些好处，以及如何配置Linkerd将跟踪的数据导出到Zipkin。在这篇文章中，我们会说明如何配置Kubernetes（包括Zipkin本身），以及如何从Linkerd导出的跟踪中获取有意义的数据。

A Kubernetes Service Mesh

在开始查看跟踪之前，我们需要部署Linkerd和Zipkin Kubernetes，以及一些示例应用程序。linkerd提供了实例的所有配置文件，我们将引导你完成以下步骤。

第1步：安装Zipkin

我们将开始安装Zipkin，它将用于收集和显示跟踪数据。在这个例子中，为了方便起见，我们将使用Zipkin的内存存储。（如果计划在生产环境中运行Zipkin，要切换到使用它的持久后端的一个。）

将Zipkin安装在默认的Kubernetes名称空间中，运行：

kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/zipkin.yml

可以通过查看Zipkin的Web UI来确认安装是否成功：

ZIPKIN_LB=$(kubectl get svc zipkin -o jsonpath="{.status.loadBalancer.ingress[0].*}")
open http://$ZIPKIN_LB # on OS X

请注意，入口IP可能需要几分钟时间才能使用。（另外请注意，如果在Minikube上运行，则需要运行一组不同的命令来加载Web UI。）

但是在我们安装Linkerd之前，Web UI将不会显示任何痕迹。

步骤2：安装 Service Mesh

接下来，我们将安装Linkerd Service Mesh，配置为将跟踪数据写入Zipkin。 要将Linkerd作为默认Kubernetes名称空间中的DaemonSet（即每个主机一个实例）安装，请运行：

kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/linkerd-zipkin.yml

此安装的Linkerd作为一个Service Mesh，出口Linkerd Zipkin telemeter追踪数据。相关的配置：

telemetry:
- kind: io.l5d.zipkin
  host: zipkin-collector.default.svc.cluster.local
  port: 9410
  sampleRate: 1.0

在这里，我们告诉linkerd发送跟踪数据到Zipkin服务，我们部署在上一步中，端口9410。配置还指定了一个采样速率，它决定了被跟踪请求的数量。在本例中，虽然正在跟踪所有请求，但在生产环境中，可能希望设置速率要低得多（默认值是0.001，或者是所有请求的0.1%）。

你可以通过查看Linkerd的管理界面来确认安装是否成功（再次注意，入口IP可能需要几分钟时间。）：

L5D_INGRESS_LB=$(kubectl get svc l5d -o jsonpath="{.status.loadBalancer.ingress[0].*}")
open http://$L5D_INGRESS_LB:9990 # on OS X

第3步：安装示例应用程序

现在，我们将通过运行以下命令在默认名称空间中安装“hello-world”应用程序：

kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/hello-world.yml

恭喜！在这一点上，我们有一个启用分布式跟踪功能的Service Mesh，以及一个使用它的应用程序。

让我们通过在端口4140上运行的Linkerd输出路由器发送流量，

http_proxy=http://$L5D_INGRESS_LB:4140 curl -s http://hello
Hello () world ()!

如果一切正常，你将看到类似于上面的“Hello world”消息，以及为请求提供服务的pod的IP。

第4步：享受视图

现在是时候看到一些跟踪。我们先看一下前面部分发送的测试请求发出的跟踪。Zipkin的用户界面允许你通过“span”名称进行搜索，而在我们的案例中，我们感兴趣的是在运行于0.0.0.0:4140的Linkerd路由器上的跨度，这是我们发送初​​始请求的地方。我们可以按如下方式搜索该跨度：

open http://$ZIPKIN_LB/?serviceName=0.0.0.0%2F4140 # on OS X

那应该用8个跨度来表示1个跟踪，并且搜索结果应该是这样的：

Zipkin搜索

点击这个视图中的跟踪将弹出跟踪详细视图：

Zipkin痕迹

从这个视图中，你可以看到Linkerd为这个跟踪发出的所有8个跨度的时间信息。事实上，Service Mesh配置中有两个服务之间的请求存在8个跨度，其中每个请求都经过两个Linkerd实例（这样协议可以升级或降级，或者 可以跨节点边界添加和删除TLS）。每个Linkerd路由器发出一个服务器跨度和一个客户端跨度，总共8个跨度。

点击一个跨度将会显示该跨度的更多细节。例如，上面跟踪中的最后一个跨度表示世界服务响应请求的时间 - 8毫秒。如果你点击那个跨度，你会看到span详细视图：

Zipkin跨度

这个视图有更多关于跨度的信息。在页面顶部，你将看到指示Linkerd何时向服务发送请求以及何时收到响应的时间信息。你还会看到很多键值对，其中包含有关请求的其他信息，例如请求URI，响应状态代码以及为请求提供服务的服务器的地址。所有这些信息都由Linkerd自动填充，对于追踪性能故障非常有用。

关于请求上下文的说明

为了使分布式跟踪正确分解，我们需要应用程序的一点帮助。具体而言，我们需要服务来将Linkerd的“上下文头”（任何以"l5d-ctx-"开头的内容）从传入请求转发到传出请求。如果没有这些头文件，就不可能通过服务将传出的请求与传入的请求对齐。（上面提供的hello和world服务默认是这样做的。）

除了跟踪之外，转发上下文头还有一些额外的好处。从我们之前关于这个话题的博客文章：

Linkerd的转发请求上下文具有比追踪更多的好处。例如，将l5d-dtab 头添加到入站请求将为请求上下文添加一个dtab覆盖。如果传播请求上下文，则可以使用dtab覆盖来在堆栈中的任意位置应用每个请求路由覆盖，这对于在生产应用程序的上下文中暂存特别服务特别有用。若请求上下文将用于传播整体延迟预算，这将使分布式系统中的处理请求性能更高。 最后， L5d-sample 标题可以用来根据请求调整跟踪采样率。为了保证一个请求被跟踪，设置 L5d-sample: 1.0。如果你不希望跟踪系统在加载测试中发送一连串请求，，请考虑将其设置为远低于Linkerd配置中定义的稳态采样速率。

结论

我们演示了如何在Kubernetes中运行Zipkin，以及如何配置Linkerd Service Mesh自动将跟踪数据导出到Zipkin。如果你已经在使用Linkerd，分布式跟踪是一种功能强大的工具。可搜索Linkerd的Zipkin telemeter相关配置参考。

附录：了解跟踪

在分布式跟踪中，跟踪是形成树结构的跨度集合。每个跨度都有一个开始时间戳和一个结束时间戳，以及有关在该间隔内发生的额外元数据。跟踪中的第一个跨度称为根跨度。所有其他跨度都有一个父ID标识引用，指的是根跨度或其后代之一。有两种类型的跨度：服务器和客户端。在Linkerd的上下文中，当Linkerd路由器收到来自上游客户端的请求时，会创建服务器跨度。当Linkerd将请求发送到下游服务器时，会创建客户端跨度。因此，客户端跨度的父节点始终是服务器跨度。在路由多服务请求的过程中，Linkerd将发出多个客户端和服务器跨度，在Zipkin UI中显示为单个跟踪。

例如，请考虑以下跟踪：

Zipkin跨度

在这个例子中，一个外部请求被Linkerd路由到“Web”服务，然后在返回响应之前依次（通过Linkerd）调用“服务B”和“服务C”。跟踪有6个跨度，总持续时间20毫秒。3个黄色跨度是服务器跨度，3个蓝色跨度是客户端跨度。该根跨度是Span A，它表示从Linkerd最初接收外部请求到返回响应之间的时间。量程A有子量程B，它表示Web服务响应Linkerd转发的请求所花费的时间。同样，跨度D表示服务B响应来自Web服务的请求所花费的时间。有关跟踪的更多信息，请阅读我们以前的博客帖子， 分布式跟踪的Polyglot微服务。