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
)。