Linkerd Service Mesh

Linkerd 2.x 需要一个正常运行的 Kubernetes 集群来运行。 该集群可能托管在云提供商上， 也可能通过 Minikube 或 Docker for Desktop 在本地运行。

如果您需要 Linkerd 功能，如服务配置文件(Service Profiles)、流量拆分(Traffic Splits)等， 则需要进行额外的配置才能使 Ingress 控制器的 Linkerd

当 Kubernetes 开始终止一个 Pod 时，它首先向该 Pod 中的所有容器发送一个 TERM 信号。 当 Linkerd 代理 sidecar 收到此信号时， 它将立即开始正常关闭， 拒绝所

使用 Service Mesh Interface 的 Traffic Split API 很容易将故障注入应用程序。 TrafficSplit 允许您将一定比例的流量重定向到特定后端。 这个后端是完

要获取每个路由的指标，您必须首先创建一个 service profile。 创建 service profile 后，Linkerd 将向 Prometheus 指标添加标签， 将特定请求与特定路由相

为了支持网格化 Pod 之间的 mTLS 连接， Linkerd 需要一个信任锚证书(trust anchor certificate)和一个带有相应 key 的颁发者证书(issuer certif

您可以通过 ingress 暴露仪表板，而不是每次想要 查看发生了什么时都使用 linkerd viz dashboard。 这也会暴露 Grafana。

按照设计，Linkerd 仅在较短的固定时间窗口（目前为 6 小时）内保留指标数据。 这意味着如果 Linkerd 的指标数据对您很有价值，您可能希望将其导出到成熟的指标存储中。

本指南将引导您完成 emojivoto 的配置和启用跟踪。关于使用 Linkerd 使用分布式跟踪的最佳方式的一些建议，请跳到最后。

这个演示是一个Ruby应用程序，可以帮助您管理书架。 它由多个微服务组成，并通过 HTTP 使用 JSON 与其他服务通信。有三种服务：

演示应用程序 emojivoto 有一些问题。 让我们用它和 linker 来诊断一个应用程序，它的失败方式比整个服务崩溃要微妙得多。 本指南假设您已经按照入门指南中的步骤进行了操作， 并在 Kub

从 Linkerd 代理的角度来看，它只是看到它与应用程序的连接被拒绝或关闭，而无需解释。这使得 Linkerd 几乎不可能在 502 响应中报告任何错误消息。

Kustomize 可用于以一致的方式修补 linkerd install 的输出， 而不是分叉 Linkerd 安装和升级过程。这允许自定义安装以添加特定于安装的功能。

所有控制平面组件（Grafana 除外） 都使用 Go 的 pprof 包 通过路径 /debug/pprof 暴露运行时分析信息。

每个路由都可以定义一个超时， 它指定在发送请求后等待响应（包括重试）完成的最长时间。如果达到此超时，Linkerd 将取消请求，并返回 504 响应。如果未指定，默认超时为 10 秒。

retry budget 是一种机制，它限制可以对服务执行的重试次数占原始请求的百分比。这可以防止重试使您的系统不堪重负。默认情况下，重试最多可以增加 20% 的请求负载（加上每秒额外的 10 次“免

Linkerd 数据平面的代理是多线程(multithreaded)的， 并且能够运行可变数量的工作线程， 以便它们的资源使用(resource usage)与应用程序工作负载(application

尽管 linkerd-viz 扩展带有自己的 Prometheus 实例， 但在某些情况下，由于各种原因使用外部实例更有意义。

Linkerd 的自动 mTLS 功能使用一组 TLS 凭据(TLS credentials)为代理生成 TLS 证书(TLS certificates)： 信任锚(trust anchor)、颁发者