Linkerd 2.10(Step by Step)—配置重试

Linkerd 2.10 系列

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

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

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

重试

对于幂等且没有主体的路由，您可以编辑服务配置文件(service profile)并将 isRetryable 添加到可重试路由：

spec:
  routes:
  - name: GET /api/annotations
    condition:
      method: GET
      pathRegex: /api/annotations
    isRetryable: true ### ADD THIS LINE ###

重试预算

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

spec:
  retryBudget:
    retryRatio: 0.2
    minRetriesPerSecond: 10
    ttl: 10s

监控重试

可以使用带有 --to 标志和 -o wide 标志的 linkerd viz routes 命令来监视重试。由于重试是在客户端执行的，我们需要使用 --to 标志来查看一个资源发送到 另一个资源的请求的指标（从服务器的角度来看，重试只是常规请求）。当指定这两个标志时，linkerd routes 命令将区分“有效(effective)”和“实际(actual)”流量。

ROUTE                       SERVICE   EFFECTIVE_SUCCESS   EFFECTIVE_RPS   ACTUAL_SUCCESS   ACTUAL_RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
HEAD /authors/{id}.json     authors             100.00%          2.8rps           58.45%       4.7rps           7ms          25ms          37ms
[DEFAULT]                   authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms

实际请求代表客户端实际发送的所有请求，包括原始请求和重试。有效请求只计算原始请求。由于原始请求可能会触发一次或多次重试， 因此在启用重试时，实际请求量通常高于有效请求量。由于原始请求可能第一次失败，但该请求的重试可能会成功， 因此有效成功率(effective success rate) 通常（但不总是）高于实际成功率(actual success rate)。