Retry

As usual, we can apply and destinations selectors to determine how retries will be performed across our data plane proxies.

The policy let you configure retry behaviour for HTTP, GRPC and TCP protocols.

We will apply the configuration with kubectl apply -f [..].

We will apply the configuration with kumactl apply -f [..] or via the HTTP API.

• numRetries (optional)

  Amount of attempts which will be made on failed (and retriable) requests

• Configuration of durations which will be used in exponential backoff strategy between retries

  • baseDuration (required)

    Base amount of time which should be taken between retries (i.e. 30ms, 0.03s, 0.0005m)

  • maxDuration (optional)

    A maximal amount of time which will be taken between retries (i.e. 1s, 0.5m)

• retriableStatusCodes (optional)

  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: 502, 503 and 504 and if they also should be considered as retriable you hove to manually place them in the list

  For example to add a status code 418:

  • when server responds with one of status codes: 502, 503 or 504,
  • when server won’t respond at all (disconnect/reset/read timeout),

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

• retryOn (optional)

  List of values which will cause retry.

  Acceptable values

  • cancelled
  • deadline_exceeded
  • internal
  • resource_exhausted
  • unavailable

  Note that if retryOn is not defined or if it’s empty, the policy will default to all values and is equivalent to: