instruction: How do you deploy and configure Linkerd service mesh?
output: Configuring Retries | Linkerd Docs Community Get Involved Adopters & Case Studies Linkerd Ambassadors Become an Ambassador Buoyant's Linkerd Forum Blog FAQ Enterprise Star Join Forum Announcing Linkerd 2.18: Battlescars, lessons learned, and preliminary Windows support Learn more You are viewing docs for an older version of Linkerd. View the latest docs . Linkerd edge Linkerd 2.18 Linkerd 2.17 Linkerd 2.16 Linkerd 2.15 Linkerd 2.14 Linkerd 2.13 Linkerd 2.12 Linkerd 2.11 Linkerd 2.10 Overview Getting Started Features HTTP, HTTP/2, and gRPC Proxying TCP Proxying and Protocol Detection Retries and Timeouts Automatic mTLS Ingress Telemetry and Monitoring Load Balancing Authorization Policy Automatic Proxy Injection CNI Plugin Dashboard and on-cluster metrics stack Distributed Tracing Fault Injection High Availability HTTP Access Logging Multi-cluster communication Proxy Init Iptables Modes Service Profiles Topology Aware Routing Traffic Split (canaries, blue/green deploys) Tasks Adding your services to Linkerd Automated Canary Releases Automatic Multicluster Failover Automatically Rotating Control Plane TLS Credentials Automatically Rotating Webhook TLS Credentials Bringing your own Prometheus Configuring Per-Route Policy Configuring Proxy Concurrency Configuring Retries Configuring Timeouts Control Plane Debug Endpoints Customizing Linkerd's Configuration with Kustomize Debugging 502s Debugging gRPC applications with request tracing Debugging HTTP applications with per-route metrics Distributed tracing with Linkerd Enabling Topology Aware Routing Exporting Metrics Exposing the Dashboard Generating your own mTLS root certificates Getting Per-Route Metrics Getting started with Linkerd SMI extension Graceful Pod Shutdown Grafana Ingress traffic Injecting Faults Installing Linkerd Installing Linkerd with Helm Installing Multi-cluster Components Linkerd and Pod Security Policies (PSP) Manually Rotating Control Plane TLS Credentials Modifying the Proxy Log Level Multi-cluster communication Multi-cluster communication with StatefulSets Replacing expired certificates Restricting Access To Services Rotating webhooks certificates Securing Linkerd Tap Setting Up Service Profiles Troubleshooting Uninstalling Linkerd Uninstalling Multicluster Upgrading Linkerd Using a Custom Cluster Domain Using A Private Docker Repository Using extensions Using GitOps with Linkerd with Argo CD Using the Debug Sidecar Validating your mTLS traffic Reference Architecture Authorization Policy CLI authz check completion diagnostics identity inject install install-cni jaeger multicluster profile uninject uninstall upgrade version viz Cluster Configuration Extensions List Helm Chart Version Matrix IPTables Reference Proxy Configuration Proxy Log Level Proxy Metrics Service Profiles What is a service mesh? Frequently Asked Questions Releases and Versions Design Principles Going to Production Service Mesh Glossary Configuring Retries In order for Linkerd to do automatic retries of failures, there are two questions that need to be answered: Which requests should be retried? How many times should the requests be retried? Both of these questions can be answered by specifying a bit of extra information in the service profile for the service you&rsquo;re sending requests to. Note Routes configured in service profiles are different from HTTPRoute resources. Service profile routes allow you to collect per-route metrics and configure client-side behavior such as retries and timeouts. HTTPRoute resources, on the other hand, can be the target of AuthorizationPolicies and allow you to specify per-route authorization. The reason why these pieces of configuration are required is because retries can potentially be dangerous. Automatically retrying a request that changes state (e.g. a request that submits a financial transaction) could potentially impact your user&rsquo;s experience negatively. In addition, retries increase the load on your system. A set of services that have requests being constantly retried could potentially get taken down by the retries instead of being allowed time to recover. Check out the retries section of the books demo for a tutorial of how to configure retries. Retries For routes that are idempotent, you can edit the service profile and add isRetryable to the retryable route: spec : routes : - name : GET /api/annotations condition : method : GET pathRegex : /api/annotations isRetryable : true ### ADD THIS LINE ### Retries are supported for all idempotent requests, whatever verb they use, and whether or not they have a body . In particular, this mean that gRPC requests can be retried. However, requests will not be retried if the body exceeds 64KiB. Retry Budgets A retry budget is a mechanism that limits the number of retries that can be performed against a service as a percentage of original requests. This prevents retries from overwhelming your system. By default, retries may add at most an additional 20% to the request load (plus an additional 10 &ldquo;free&rdquo; retries per second). These settings can be adjusted by setting a retryBudget on your service profile. spec : retryBudget : retryRatio : 0.2 minRetriesPerSecond : 10 ttl : 10s Monitoring Retries Retries can be monitored by using the linkerd viz routes command with the --to flag and the -o wide flag. Since retries are performed on the client-side, we need to use the --to flag to see metrics for requests that one resource is sending to another (from the server&rsquo;s point of view, retries are just regular requests). When both of these flags are specified, the linkerd routes command will differentiate between &ldquo;effective&rdquo; and &ldquo;actual&rdquo; traffic. 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 Actual requests represent all requests that the client actually sends, including original requests and retries. Effective requests only count the original requests. Since an original request may trigger one or more retries, the actual request volume is usually higher than the effective request volume when retries are enabled. Since an original request may fail the first time, but a retry of that request might succeed, the effective success rate is usually ( but not always ) higher than the actual success rate. Linkerd was originally created by Buoyant View Code of Conduct Community GitHub Slack Linkerd Forum Follow Linkedin YouTube Twitter Edit This Site Copyright © 2025 Linkerd Authors. All rights reserved.