You are browsing documentation for the next version of Kuma. Use this version at your own risk.
Retry is an outbound policy. Dataplanes whose configuration is modified are in the
This policy enables Kuma to know how to behave if there is a failed scenario (i.e. HTTP request) which could be retried.
As usual, we can apply
destinations selectors to determine how retries will be performed across our data plane proxies.
The policy let you configure retry behaviour for
apiVersion: kuma.io/v1alpha1 kind: Retry mesh: default metadata: name: web-to-backend-retry-policy spec: sources: - match: kuma.io/service: web_default_svc_80 destinations: - match: kuma.io/service: backend_default_svc_80 conf: http: numRetries: 5 perTryTimeout: 200ms backOff: baseInterval: 20ms maxInterval: 1s retriableStatusCodes: - 500 - 504 retriableMethods: - GET grpc: numRetries: 5 perTryTimeout: 200ms backOff: baseInterval: 20ms maxInterval: 1s retryOn: - cancelled - deadline_exceeded - internal - resource_exhausted - unavailable tcp: maxConnectAttempts: 3
We will apply the configuration with
kubectl apply -f [..].
Amount of attempts which will be made on failed (and retriable) requests
Amount of time after which retry attempt should timeout (i.e. all the values:
0.0005mare equivalent and can be used to express the same timeout value, equal to
Configuration of durations which will be used in exponential backoff strategy between retries
Base amount of time which should be taken between retries (i.e.
A maximal amount of time which will be taken between retries (i.e.
A list of status codes which will cause the request to be retried. When this field will be provided it will overwrite the default behaviour of accepting as retriable codes:
504and if they also should be considered as
retriableyou have to manually place them in the list
For example to add a status code
retriableStatusCodes: - 418 - 502 - 503 - 504
retriableStatusCodesis provided in addition to
retryOn(below), but the latter doesn’t contain
retriable_status_codesas a condition, it will be automatically added.
List of conditions which will cause a retry.
Note that if
retryOnis not defined or if it’s empty, the policy will default to the equivalent of:
retryOn: - gateway_error - connect_failure - refused_stream
retriable_status_codeswithout also providing
retriableStatusCodes(above) will fail policy validation.
A list of HTTP methods in which a request’s method must be contained before that request can be retried. The default behavior is that all methods are retriable.
You can configure your GRPC Retry policy in similar fashion as the HTTP one with the only difference of the
retryOn property which replace the
retriableStatusCodes from the HTTP policy
List of values which will cause retry.
Note that if
retryOnis not defined or if it’s empty, the policy will default to all values and is equivalent to:
retryOn: - cancelled - deadline_exceeded - internal - resource_exhausted - unavailable
A maximal amount of TCP connection attempts which will be made before giving up
This policy will make attempt to retry the TCP connection which fail to be established and will be applied in the scenario when both, the dataplane, and the TCP service matched as a destination will be down.
Retry is an Outbound Connection Policy.
The only supported value for
Builtin Gateway support
Retries can be configured on each route by matching the
Retry connection policy to the backend destination tags.