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 中文手册持续修正更新中：

• 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 的响应分类！

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

我是为少
微信：uuhells123
公众号：黑客下午茶
加我微信（互相学习交流），关注公众号（获取更多学习资料~）
复制代码