Linkerd 2.10(Step by Step)—使用请求跟踪调试 gRPC 应用程序

Linkerd 2.10 系列

• 快速上手 Linkerd v2.10 Service Mesh（服务网格）
• 腾讯云 K8S 集群实战 Service Mesh—Linkerd2 & Traefik2 部署 emojivoto 应用
• 详细了解 Linkerd 2.10 基础功能，一起步入 Service Mesh 微服务架构时代
• Linkerd 2.10—将您的服务添加到 Linkerd
• Linkerd 2.10—自动化的金丝雀发布
• Linkerd 2.10—自动轮换控制平面 TLS 与 Webhook TLS 凭证
• Linkerd 2.10—如何配置外部 Prometheus 实例
• Linkerd 2.10—配置代理并发
• Linkerd 2.10—配置重试
• Linkerd 2.10—配置超时
• Linkerd 2.10—控制平面调试端点
• Linkerd 2.10—使用 Kustomize 自定义 Linkerd 的配置

Linkerd 2.10 中文手册持续修正更新中：

• https://linkerd.hacker-linner.com

演示应用程序 emojivoto 有一些问题。让我们用它和 linker 来诊断一个应用程序，它的失败方式比整个服务崩溃要微妙得多。本指南假设您已经按照入门指南中的步骤进行了操作， 并在 Kubernetes 集群中运行了 linker 和演示应用程序。如果你还没做完，那就开始吧，做完就回来！

如果您看一眼 Linkerd 仪表板（通过运行 linkerd viz dashboard 命令）， 您应该会看到 emojivoto 命名空间中的所有资源，包括部署。运行 Linkerd 的每个部署都会显示 成功率(success rate)、每秒请求数(requests per second)和延迟百分位数(latency percentiles)。

这很不错，但您可能会注意到的第一件事是成功率远低于 100%！点击 web，让我们深入了解。

您现在应该查看 web deployment 的 Deployment 页面。您将在这里看到的第一件事是 Web deployment 正在从 vote-bot （emojivoto 中包含的 deployment 以持续生成低水平的实时流量）中获取流量。web deployment 还有两个传出依赖项，emoji 和 voting。

当 emoji deployment 成功处理来自网络的每个请求时， 看起来 voting deployment 失败了一些请求！依赖 deployment 中的失败可能正是导致 Web 返回错误的原因。

让我们进一步向下滚动页面，我们将看到传入和传出 web 的所有流量的实时列表。这是有趣的：

有两个调用不是 100%：第一个是 vote-bot 对 /api/vote 端点的调用。第二个是 VoteDoughnut 调用从 web deployment 到它的依赖 deployment，voting。很有意思！由于 /api/vote 是传入调用，而 VoteDoughnut 是传出调用， 这是一个很好的线索，表明该端点是导致问题的原因！

最后，为了更深入地挖掘，我们可以单击最右侧栏中的 tap 图标。这将带我们进入仅与此端点匹配的请求的实时列表。您将在 GRPC status 列下看到 Unknown。这是因为请求失败并显示 gRPC status code 2， 这是您从代码中看到的常见错误响应。Linkerd 无需任何其他配置即可了解 gRPC 的响应分类！

在这一点上，我们拥有修复端点和恢复应用程序整体健康所需的一切。