Traffic Setting

Traffic settings for proxy workloads in a traffic group.

AuthenticationSettings

Configuration for connection authentication parameters. This allows the enforcement of mutual TLS connections to upstream services that do not have a sidecar. This ensures that gateways or mesh workloads do not communicate in plain text with services outside the mesh.

Field	Description	Validation Rule
trafficMode	tetrateio.api.tsb.traffic.v2.AuthenticationSettings.AuthenticationMode If set to REQUIRED, client sidecars under this configuration will be configured to initiate mTLS connections using mesh-generated client certificates to services that do not have a sidecar injected.	–

DownstreamResilienceSettings

DownstreamResilienceSettings control the reliability knobs in Envoy when accepting inbound connections.

Field	Description	Validation Rule
connectionPool	tetrateio.api.tsb.traffic.v2.DownstreamResilienceSettings.ConnectionPoolSettings Configures tolerance and other settings for TCP/HTTP connections to the service.	–
meshTimeout	tetrateio.api.tsb.traffic.v2.DownstreamResilienceSettings.MeshTimeout Configures the max connection and stream durations for HTTP and TCP connections. This applies to the inbound connections at the Sidecars and Gateways coming from a mesh-internal service.	–

ConnectionPoolSettings

Connection pool settings for downstream connections.

Field	Description	Validation Rule
tcp	tetrateio.api.tsb.traffic.v2.DownstreamResilienceSettings.ConnectionPoolSettings.TCP TCP connection pool settings	–

TCP

TCP Settings for inbound requests.

Field	Description	Validation Rule
keepAlive	tetrateio.api.tsb.traffic.v2.TcpKeepAlive Keep Alive Settings.	–

MeshTimeout

Connection and Stream timeout settings for the mesh. These apply to the inbound connections at the Sidecars and Gateways.

Field	Description	Validation Rule
maxConnectionDuration	google.protobuf.Duration This specifies the duration of time after which a downstream and upstream connection will be drained and/or closed, starting from when it was first established. If there are no active streams, the connection will be closed. If there are any active streams, the drain sequence will kick-in, and the connection will be force-closed after the drain period. The default value of max connection duration is 0 or unlimited, which means that the connections will never be closed due to aging. This setting applies to the entire HTTP connection and all streams (HTTP/2 and HTTP/3) the connection carries.	–
maxStreamDuration	google.protobuf.Duration The max stream duration is the maximum time that a stream’s lifetime will span.	–
maxDownstreamConnectionDuration	google.protobuf.Duration The maximum duration of a TCP connection. The duration is defined as the period since a connection was established. If not set, there is no max duration. When max_downstream_connection_duration is reached the connection will be closed. This can be used alongside with max_connection_duration.	–
proxyType	tetrateio.api.tsb.traffic.v2.ProxyType Specifies the type of proxy to which to apply the mesh timeout settings. The default is to apply the settings to both Gateways and Sidecars.	enum = {   defined_only: true }

HTTPRetry

HTTPRetry defines the parameters for retrying API calls to a service.

Field	Description	Validation Rule
attempts	int32 REQUIRED Number of retries for a given request. The interval between retries will be determined automatically (25ms+). Actual number of retries attempted depends on the httpReqTimeout.	int32 = {   gte: 0 }
perTryTimeout	google.protobuf.Duration Timeout per retry attempt for a given request. format: 1h/1m/1s/1ms. MUST BE >=1ms.	–
retryOn	string Specifies the conditions under which retry takes place. One or more policies can be specified using a ‘,’ delimited list. See the retry policies and gRPC retry policies for more details.	string = {   pattern: ^$|^(5xx|gateway-error|reset|connect-failure|envoy-ratelimited|retriable-4xx|refused-stream|retriable-status-codes|retriable-headers|cancelled|deadline-exceeded|internal|resource-exhausted|unavailable)(,(5xx|gateway-error|reset|connect-failure|envoy-ratelimited|retriable-4xx|refused-stream|retriable-status-codes|retriable-headers|cancelled|deadline-exceeded|internal|resource-exhausted|unavailable))*$ }
retryBackOff	tetrateio.api.tsb.traffic.v2.HTTPRetry.RetryBackOff Specifies the parameters that controls the interval between retry attempts, i.e., how soon the next retry should be attempted after a failure. The back-off interval for the N-th retry is chosen randomly in the range: [0, min((2^N - 1)* B, max_interval)] where B is the base_interval. The interval increases exponentially with each attempt, but is capped at max_interval. Example (B = 25ms, max_interval = 250ms): 1st retry: randomly delayed between 0–24ms 2nd retry: randomly delayed between 0–74ms 3rd retry: randomly delayed between 0–174ms …and so on. Maximum delay is capped at 250ms. This field is optional. If unset, the default base_interval is 25ms which is sufficient for most fast-fail retry scenarios. The default value of max_interval is 10 times the base_interval. You may want to configure this value specific to your retry strategy, for example: Retries occur before Envoy finishes ejecting a failed endpoint, causing wasted attempts. A larger backoff helps avoid this. The backend is slow or rate-limited and needs more recovery time between requests. See envoy retry algorithm for more details.	–

RetryBackOff

Specifies parameters that control exponential retry back off.

Field	Description	Validation Rule
baseInterval	google.protobuf.Duration REQUIRED The base interval between retry attempts. This parameter is required and must be greater than zero. Values less than 1 ms are rounded up to 1 ms. The default value is 25ms.	–
maxInterval	google.protobuf.Duration The maximum interval between retry attempts. This parameter is optional but must be greater than or equal to base_interval if set. The default is 10 times the base_interval.	–

InboundTrafficSetting

Configuration for inbound traffic.

Field	Description	Validation Rule
rateLimiting	tetrateio.api.tsb.gateway.v2.RateLimiting Configuration for rate limiting requests. Only applies to sidecars in traffic group today.	–
resilience	tetrateio.api.tsb.traffic.v2.DownstreamResilienceSettings Resiliency configuration for inbound connections.	–
failoverSettings	tetrateio.api.tsb.types.v2.FailoverSettings Failover settings apply to all clients accessing the hostname defined in this section. While the configuration is set by the user on the server/service side, TSB ensures that client proxies implement these settings.	–

KeepAliveSettings

Keep Alive Settings.

Field	Description	Validation Rule
tcp	tetrateio.api.tsb.traffic.v2.TcpKeepAliveSettings TCP Keep Alive settings associated with the upstream and downstream TCP connections.	–

LoadBalancerSettings

Defines Load Balancing policies to be applied on the client requests.

Field	Description	Validation Rule
simple	tetrateio.api.tsb.traffic.v2.LoadBalancerSettings.SimpleLB oneof _lb_policy Use standard load balancing algorithms that require no tuning.	enum = {   defined_only: true }
consistentHash	tetrateio.api.tsb.traffic.v2.LoadBalancerSettings.ConsistentHashLB oneof _lb_policy Use consistent hash load balancing which can provide soft session affinity.	–

ConsistentHashLB

Consistent Hash-based load balancing can be used to provide soft session affinity based on HTTP headers, cookies or other properties. The affinity to a particular destination host may be lost when one or more hosts are added/removed from the destination service.

Note: consistent hashing is less reliable at maintaining affinity than common "sticky sessions" implementations, which often encode a specific destination in a cookie, ensuring affinity is maintained as long as the backend remains. With consistent hash, the guarantees are weaker; any host addition or removal can break affinity for 1/backends requests.

Warning: consistent hashing depends on each proxy having a consistent view of endpoints. This is not the case when locality load balancing is enabled. Locality load balancing and consistent hash will only work together when all proxies are in the same locality, or a high level load balancer handles locality affinity.

Field	Description	Validation Rule
httpHeaderName	string oneof _hash_key Hash based on a specific HTTP header.	–
httpCookie	tetrateio.api.tsb.traffic.v2.LoadBalancerSettings.ConsistentHashLB.HTTPCookie oneof _hash_key Hash based on HTTP cookie.	–
useSourceIp	bool oneof _hash_key Hash based on the source IP address. This is applicable for both TCP and HTTP connections.	–
httpQueryParameterName	string oneof _hash_key Hash based on a specific HTTP query parameter.	–
ringHash	tetrateio.api.tsb.traffic.v2.LoadBalancerSettings.ConsistentHashLB.RingHash oneof _hash_algorithm The ring/modulo hash load balancer implements consistent hashing to backend hosts.	–
maglev	tetrateio.api.tsb.traffic.v2.LoadBalancerSettings.ConsistentHashLB.MagLev oneof _hash_algorithm The Maglev load balancer implements consistent hashing to backend hosts.	–

HTTPCookie

Describes a HTTP cookie that will be used as the hash key for the Consistent Hash load balancer. If the cookie is not present, it will be generated.

Field	Description	Validation Rule
name	string REQUIRED Name of the cookie.	string = {   min_len: 1 }
path	string Path to set for the cookie.	–
ttl	google.protobuf.Duration REQUIRED Lifetime of the cookie.	duration = {   required: true }

MagLev

Implements consistent hashing to upstream hosts. It can be used as a drop in replacement for RingHash. It has higher speed than RingHash with faster hash table lookups. Please refer https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancers#maglev

Field	Description	Validation Rule
tableSize	uint32 REQUIRED The table size for Maglev hashing. This helps in controlling the disruption when the backend hosts change. Increasing the table size reduces the amount of disruption.	uint32 = {   gte: 1 }

RingHash

Implements consistent hashing to upstream hosts. Each upstream host is mapped onto a circle (ring) by hashing its address, each request is then routed using some hash property of the request. Please refer https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancers#ring-hash

Field	Description	Validation Rule
minimumRingSize	uint32 The minimum number of virtual nodes to use for the hash ring. Defaults to 1024. Larger ring sizes result in more granular load distributions. If the number of hosts in the load balancing pool is larger than the ring size, each host will be assigned a single virtual node.	–

OutboundTrafficSetting

Configuration for outbound traffic.

Field	Description	Validation Rule
reachability	tetrateio.api.tsb.traffic.v2.ReachabilitySettings The set of services and hosts accessed by a workload (and hence its sidecar) in the mesh. Defining the set of services accessed by a workload (i.e. its dependencies) in advance reduces the memory and CPU consumption both the Istio control plane and the individual Envoy proxy workloads in the data plane.	–
egress	tetrateio.api.tsb.traffic.v2.OutboundTrafficSetting.EgressGateway Specifies the details of the egress proxy to which traffic to services that are not part to the mesh should be forwarded to from the proxy workloads. If not specified, the proxy workloads will send this traffic directly to the IP requested by the application.	–
upstreamTrafficSettings	List of tetrateio.api.tsb.traffic.v2.UpstreamTrafficSettings List of hosts and the associated traffic settings to be used by the clients sending traffic to them.	–

EgressGateway

EgressGateway specifies the gateway where traffic external to the mesh will be redirected.

Field	Description	Validation Rule
host	string REQUIRED Specifies the egress gateway hostname. Must be in \<namespace\>/\<fqdn\> format.	string = {   pattern: ^[^/]+/[^/]+$ }

ReachabilitySettings

ReachabilitySettings define the set of services and hosts accessed by a workload (and hence its sidecar) in the mesh. Defining the set of services accessed by a workload (i.e. its dependencies) in advance reduces the memory and CPU consumption both the Istio control plane and the individual Envoy proxy workloads in the data plane.

Field	Description	Validation Rule
mode	tetrateio.api.tsb.traffic.v2.ReachabilitySettings.Mode A short cut for specifying the set of services accessed by the workload.	–
hosts	List of string When the mode is CUSTOM, hosts specify the set of services that the sidecar should be able to reach. Must be in the \<namespace\>/\<fqdn\> format. ./* indicates all services in the namespace where the sidecar resides. ns1/* indicates all services in the ns1 namespace. ns1/svc1.com indicates svc1.com service in ns1 namespace. */svc1.com indicates svc1.com service in any namespace.	–

ResilienceSettings

ResilienceSettings control the reliability knobs in Envoy when making outbound connections from a gateway or proxy workload.

Field	Description	Validation Rule
httpRequestTimeout	google.protobuf.Duration This field is DEPRECATED in favor of upstreamTrafficSettings.resilience.connectionPool.http.requestTimeout. Timeout for HTTP requests. Disabled if not set.	–
httpRetries	tetrateio.api.tsb.traffic.v2.HTTPRetry This field is DEPRECATED in favor of upstreamTrafficSettings.resilience.connectionPool.http.retries. Retry policy for HTTP requests. Disabled if not set.	–
keepAlive	tetrateio.api.tsb.traffic.v2.KeepAliveSettings Keep Alive Settings.	–
circuitBreakerSensitivity	tetrateio.api.tsb.traffic.v2.ResilienceSettings.Sensitivity This field is DEPRECATED in favor of upstreamTrafficSettings.resilience.circuitBreakerSensitivity. Circuit breakers in Envoy are applied per endpoint in a load balancing pool. By default, circuit breakers are disabled. If set, the sensitivity level determines the maximum number of consecutive failures that Envoy will tolerate before ejecting an endpoint from the load balancing pool.	–

TcpKeepAlive

Field	Description	Validation Rule
probes	google.protobuf.UInt32Value The total number of unacknowledged probes to send before deciding the connection is dead. Default is to use the OS level configuration, Linux defaults to 9.	–
idleTime	google.protobuf.UInt32Value The number of seconds a connection needs to be idle before keep-alive probes start being sent. Default is to use the OS level configuration, Linux defaults to 7200s.	–
interval	google.protobuf.UInt32Value The number of seconds between keep-alive probes. Default is to use the OS level configuration, Linux defaults to 75s.	–

TcpKeepAliveSettings

TCP Keep Alive Settings.

Field	Description	Validation Rule
downstream	tetrateio.api.tsb.traffic.v2.TcpKeepAlive TCP Keep Alive Settings associated with the downstream (client) connection.	–
upstream	tetrateio.api.tsb.traffic.v2.TcpKeepAlive This field is DEPRECATED in favor of upstreamTrafficSettings.resilience.connectionPool.tcp.keepAlive. TCP Keep Alive Settings associated with the upstream (backend) connection.	–

TrafficSetting

A traffic setting applies configuration to a set of proxy workloads in a traffic group or a workspace. When applied to a traffic group, missing fields will inherit values from the workspace-wide setting if any.

Traffic Settings allow configuring the behavior of the proxy workloads in a set of namespaces owned by a traffic group. Specifically, it allows configuring the dependencies of proxy workloads on namespaces outside the traffic group as well as reliability settings for outbound calls made by the proxy workloads to other services.

This is a global object that uniquely configures the traffic group, and there can be only one traffic setting object defined for each traffic group.

The following example creates a traffic group for the proxy workloads in ns1, ns2 and ns3 namespaces owned by its parent workspace w1 under tenant mycompany. It then defines a traffic setting for the all workloads in these namespaces, adding a dependency on all the services in the shared db namespace, and forwarding all unknown traffic via the egress gateway in the istio-system namespace.

apiVersion: traffic.tsb.tetrate.io/v2
kind: Group
metadata:
  name: t1
  workspace: w1
  tenant: mycompany
  organization: myorg
spec:
  namespaceSelector:
    names:
    - "*/ns1"
    - "*/ns2"
    - "*/ns3"
  configMode: BRIDGED

And the associated traffic settings for the proxy workloads:

apiVersion: traffic.tsb.tetrate.io/v2
kind: TrafficSetting
metadata:
  name: defaults
  group: t1
  workspace: w1
  tenant: mycompany
  organization: myorg
spec:
  outbound:
    reachability:
      mode: CUSTOM
      hosts:
      - "ns1/*"
      - "ns2/*"
      - "ns3/*"
      - "db/*"
    upstreamTrafficSettings:
    - hosts:
      - '*'
      settings:
        resilience:
          circuitBreakerSensitivity: MEDIUM
    egress:
      host: istio-system/istio-egressgateway

To setup load balancing algorithm as ROUND_ROBIN for all outbound requests to service foo.bar.svc.cluster.local from clients in t1 traffic group:

apiVersion: traffic.tsb.tetrate.io/v2
kind: TrafficSetting
metadata:
  name: defaults
  group: t1
  workspace: w1
  tenant: mycompany
  organization: myorg
spec:
  outbound:
    upstreamTrafficSettings:
    - hosts:
      - 'foo.bar.svc.cluster.local'
      settings:
        loadBalancer:
          simple: ROUND_ROBIN

upstreamTrafficSettings can be used to configure the outbound traffic with grouping a particular group of upstream hosts to have a certain setting. In the below example all outbound requests to hosts matching wildcard *.ns1.svc.cluster.local will use request timeout of 10s while hosts matching *.ns2.svc.cluster.local and *.ns3.svc.cluster.local will use request timeout of 5s.

apiVersion: traffic.tsb.tetrate.io/v2
kind: TrafficSetting
metadata:
  name: defaults
  group: t1
  workspace: w1
  tenant: mycompany
  organization: myorg
spec:
  outbound:
    upstreamTrafficSettings:
    - hosts:
      - '*.ns1.svc.cluster.local'
      settings:
        resilience:
          connectionPool:
            http:
              requestTimeout: 10s
    - hosts:
      - '*.ns2.svc.cluster.local'
      - '*.ns3.svc.cluster.local'
      settings:
        resilience:
          connectionPool:
            http:
              requestTimeout: 5s

The following traffic setting confines the reachability of proxy workloads in the traffic group t1 to other namespaces inside the group. The resilience and egress gateway settings will be inherited from the workspace wide traffic setting.

apiVersion: traffic.tsb.tetrate.io/v2
kind: TrafficSetting
metadata:
  name: defaults
  group: t1
  workspace: w1
  tenant: mycompany
  organization: myorg
spec:
  outbound:
    reachability:
      mode: GROUP

The above fields are now moved to two different sections called inbound and outbound to allow better control over these fields. Please refer the below example to configure a traffic setting for all services in traffic group t1 configuring similar knobs as explained in earlier examples:

apiVersion: traffic.tsb.tetrate.io/v2
kind: TrafficSetting
metadata:
  name: defaults
  group: t1
  workspace: w1
  tenant: mycompany
  organization: myorg
spec:
  inbound:
    resilience:
      connectionPool:
        tcp:
          keepAlive:
            idleTime: 300
  outbound:
    reachability:
      mode: GROUP
    upstreamTrafficSettings:
    - hosts:
      - '*.ns1.svc.cluster.local'
      settings:
        resilience:
          connectionPool:
            http:
              requestTimeout: 10s

This traffic setting configuration specifies upstream traffic settings for specific hosts within the client namespace. It is associated with the w1 workspace and the t1 traffic group.

apiVersion: traffic.tsb.tetrate.io/v2
kind: TrafficSetting
metadata:
  name: client-upstream-traffic-setting
  namespace: client
  group: t1
  workspace: w1
  tenant: mycompany
  organization: myorg
spec:
  outbound:
    upstreamTrafficSettings:
    - hosts:
      - 'httpbin.app1.svc.cluster.local'
      - '*.app3.svc.cluster.local'
      - '*.app4.svc.cluster.local'
      settings:
        authentication:
          trafficMode: REQUIRED
    - hosts:
      - '*.app2.svc.cluster.local'
      - 'tetrate.app4.svc.cluster.local'
      settings:
        authentication:
          trafficMode: OPTIONAL

This configuration specifies authentication requirements for traffic to the following hosts:

• httpbin.app1.svc.cluster.local requires mTLS authentication.
• All non-injected services in app3 namespace require mTLS authentication.
• All non-injected services in app4 namespace require mTLS authentication, except for tetrate.app4.svc.cluster.local, which is excluded.
• Authentication enforcement is skipped for all non-injected services in app2 namespace.

Field	Description	Validation Rule
reachability	tetrateio.api.tsb.traffic.v2.ReachabilitySettings The set of services and hosts accessed by a workload (and hence its sidecar) in the mesh. Defining the set of services accessed by a workload (i.e. its dependencies) in advance reduces the memory and CPU consumption both the Istio control plane and the individual Envoy proxy workloads in the data plane. DEPRECATED. Moved to outbound.	–
resilience	tetrateio.api.tsb.traffic.v2.ResilienceSettings Resilience settings such as timeouts, retries, etc., affecting outbound traffic from proxy workloads. DEPRECATED. Moved to outbound.	–
egress	tetrateio.api.tsb.traffic.v2.TrafficSetting.EgressGateway Specifies the details of the egress proxy to which unknown traffic should be forwarded to from the proxy workload. If not specified, the proxy workload will send the unknown traffic directly to the IP requested by the application. DEPRECATED. Moved to outbound.	–
rateLimiting	tetrateio.api.tsb.gateway.v2.RateLimiting Configuration for rate limiting requests. These settings are only applied to sidecar proxies in the traffic group. Use the rateLimiting field in the Tier1Gateway and the Ingressgateway API to configure ratelimiting at the ingressgateway proxies. DEPRECATED. Moved to inbound.	–
upstreamTrafficSettings	List of tetrateio.api.tsb.traffic.v2.UpstreamTrafficSettings List of hosts and the associated traffic settings to be used by the clients that are downstreams to the defined upstream hosts. DEPRECATED. Moved to outbound.	–
inbound	tetrateio.api.tsb.traffic.v2.InboundTrafficSetting Configures inbound traffic. Applicable when service acts as a server.	–
outbound	tetrateio.api.tsb.traffic.v2.OutboundTrafficSetting Configures outbound traffic. Applicable when service acts as a client.	–
configGenerationMetadata	tetrateio.api.tsb.types.v2.ConfigGenerationMetadata Metadata values that will be add into the Istio generated configurations. When using YAML APIs like tctl or gitops, put them into the metadata.labels or metadata.annotations instead. This field is only necessary when using gRPC APIs directly.	–

EgressGateway

EgressGateway specifies the gateway where traffic external to the mesh will be redirected.

Field	Description	Validation Rule
host	string REQUIRED Specifies the egress gateway hostname. Must be in \<namespace\>/\<fqdn\> format.	string = {   pattern: ^[^/]+/[^/]+$ }
port	int32 Deprecated. This field is ignored and will be removed in upcoming releases. Specifies the port on the host to connect to.	–

UpstreamResilienceSettings

UpstreamResilienceSettings controls the reliability knobs for client connections to the upstream hosts.

Field	Description	Validation Rule
connectionPool	tetrateio.api.tsb.traffic.v2.UpstreamResilienceSettings.ConnectionPoolSettings Configures tolerance and other settings for TCP/HTTP connections to the service.	–
circuitBreakerSensitivity	tetrateio.api.tsb.traffic.v2.UpstreamResilienceSettings.Sensitivity Circuit breakers in Envoy are applied per endpoint in a load balancing pool. By default, circuit breakers are disabled. If set, the sensitivity level determines the maximum number of consecutive failures that Envoy will tolerate before ejecting an endpoint from the load balancing pool.	enum = {   defined_only: true }
outlierDetection	tetrateio.api.tsb.traffic.v2.UpstreamResilienceSettings.OutlierDetection Outlier detection settings for the upstream host when custom mode is used.	–

ConnectionPoolSettings

Connection pool settings for the upstream host.

Field	Description	Validation Rule
http	tetrateio.api.tsb.traffic.v2.UpstreamResilienceSettings.ConnectionPoolSettings.HTTP HTTP connection pool settings	–
tcp	tetrateio.api.tsb.traffic.v2.UpstreamResilienceSettings.ConnectionPoolSettings.TCP TCP connection pool settings	–

HTTP

HTTP Settings for outbound requests.

Field	Description	Validation Rule
requestTimeout	google.protobuf.Duration Timeout for HTTP requests. format: 1h/1m/1s/1ms. MUST BE >=1ms. Disabled if not set.	–
retries	tetrateio.api.tsb.traffic.v2.HTTPRetry Retry policy for HTTP requests. Disabled if not set.	–
maxRequests	uint32 Maximum number of active requests to the service. Applicable to both HTTP/1.1 and HTTP2. Default 0, meaning "unlimited", up to 2^32 - 1.	–
maxRequestsPerConnection	uint32 Maximum number of requests per connection to the service. If set to 1, it disables keep alive. Default 0, meaning "unlimited", up to 2^29.	–

TCP

TCP Settings for outbound requests.

Field	Description	Validation Rule
keepAlive	tetrateio.api.tsb.traffic.v2.TcpKeepAlive Keep Alive Settings.	–
maxConnections	uint32 Maximum number of HTTP1 /TCP connections to the service. Default 0, meaning "unlimited", up to 2^32 - 1.	–
connectTimeout	google.protobuf.Duration TCP connection timeout. format: 1h/1m/1s/1ms. MUST BE >=1ms. Default is 10s.	duration = {   gte: {nanos:1000000} }

OutlierDetection

Outlier detection settings for the upstream host.

Field	Description	Validation Rule
consecutiveGatewayFailure	google.protobuf.UInt32Value The number of consecutive gateway failures (502, 503, 504 status codes) before a consecutive gateway failure ejection occurs. Defaults to circuitBreakerSensitivity of MEDIUM(5) in TSB.	–
enforcingConsecutiveGatewayFailure	google.protobuf.UInt32Value The percentage of a host to be ejected when an outlier status is detected through consecutive gateway failures. This setting can be used to disable ejection or to ramp it up slowly. Defaults to 100 in TSB.	uint32 = {   lte: 100 }
consecutive5xx	google.protobuf.UInt32Value The number of consecutive server-side error responses (for HTTP traffic, 5xx responses; for TCP traffic, connection failures; for Redis, failure to respond PONG; etc.) before a consecutive 5xx ejection occurs. Defaults to 5.	–
enforcingConsecutive5xx	google.protobuf.UInt32Value The percentage of a host to be actually ejected when an outlier status is detected through consecutive 5xx. This setting can be used to disable ejection or to ramp it up slowly. Defaults to 0 in TSB.	uint32 = {   lte: 100 }
splitExternalLocalOriginErrors	bool Determines whether to distinguish local origin failures from external errors. Local Origin Failures are errors that occur within the Envoy process itself, before the request is actually sent to the upstream host. example of these are connection timeout, TCP reset etc. External errors are errors that occur after the request is sent to the upstream host. example of these are 5xx errors, connection refused etc. If set to true, consecutiveLocalOriginFailure and enforcingConsecutiveLocalOriginFailure will be taken into account. Defaults to false. The number of consecutive locally originated failures before ejection occurs. Defaults to 5. Parameter takes effect only when splitExternalLocalOriginErrors is set to true.	–
consecutiveLocalOriginFailure	google.protobuf.UInt32Value	–
enforcingConsecutiveLocalOriginFailure	google.protobuf.UInt32Value The percentage of a host to be actually ejected when an outlier status is detected through consecutive locally originated failures. This setting can be used to disable ejection or to ramp it up slowly. Defaults to 100. Parameter takes effect only when splitExternalLocalOriginErrors is set to true.	uint32 = {   lte: 100 }
interval	google.protobuf.Duration The time interval between ejection analysis sweeps. This can result in both new ejections as well as hosts being returned to service. Defaults to 10000ms or 10s.	duration = {   gt: {nanos:0} }
baseEjectionTime	google.protobuf.Duration The base time that a host is ejected for. The real time is equal to the base time multiplied by the number of times the host has been ejected. Defaults to 30000ms or 30s.	duration = {   gt: {nanos:0} }

UpstreamTrafficSettings

Traffic settings for the clients that are downstreams to the defined upstream hosts.

Field	Description	Validation Rule
hosts	List of string List of hosts for which the settings will be created. Can contain wildcard hosts. The host should be a service from the service registry or a host declared by ServiceEntries.	repeated = {   items: {string:{min_len:1}} }
settings	tetrateio.api.tsb.traffic.v2.UpstreamTrafficSettings.Settings A single setting to be applied to all the clients connecting to the upstream hosts.	–

Settings

Traffic settings to be applied to the clients of the upstream hosts.

Field	Description	Validation Rule
resilience	tetrateio.api.tsb.traffic.v2.UpstreamResilienceSettings Resilience settings for the clients.	–
loadBalancer	tetrateio.api.tsb.traffic.v2.LoadBalancerSettings Load balancing settings for the clients.	–
authentication	tetrateio.api.tsb.traffic.v2.AuthenticationSettings Configuration for connection authentication parameters.	–

AuthenticationMode

AuthenticationMode configures whether to initiate only mutual TLS connections or to allow plaintext traffic as well.

Field	Number	Description
UNSET	0	Default is UNSET.
OPTIONAL	1	Accept both plaintext and mTLS authenticated connections.
REQUIRED	2	Always initiate mutual TLS authenticated connections, and fail if the upstream does not support it.

SimpleLB

Standard load balancing algorithms that require no tuning.

Field	Number	Description
UNSPECIFIED	0	No load balancing algorithm has been specified by the user. An appropriate default will be used.
RANDOM	2	The random load balancer selects a random healthy host. The random load balancer generally performs better than round robin if no health checking policy is configured.
PASSTHROUGH	3	This option will forward the connection to the original IP address requested by the caller without doing any form of load balancing. This option must be used with care. It is meant for advanced use cases. Refer to Original Destination load balancer in Envoy for further details.
ROUND_ROBIN	4	A basic round robin load balancing policy. This is generally unsafe for many scenarios (e.g. when enpoint weighting is used) as it can overburden endpoints. In general, prefer to use LEAST_REQUEST as a drop-in replacement for ROUND_ROBIN.
LEAST_REQUEST	5	The least request load balancer spreads load across endpoints, favoring endpoints with the least outstanding requests. This is generally safer and outperforms ROUND_ROBIN in nearly all cases. Prefer to use LEAST_REQUEST as a drop-in replacement for ROUND_ROBIN.

ProxyType

ProxyType defines the type of a proxy within the service mesh.

This enum is used to apply configurations based on the type of the proxy.

Field	Number	Description
ANY	0	ANY is the default proxy type that represents both sidecar, and gateway proxies. Use this value to apply configurations to both sidecars and gateways.
SIDECAR	1	SIDECAR represents a sidecar proxy that runs alongside an application. Use this value to apply configurations only to the sidecars.
GATEWAY	2	GATEWAY represents a gateway proxy that runs standalone and, acts as an entry/exit point into/out of the service mesh. Use this value to apply configurations only to the gateways.

Mode

A short cut for defining the common reachability patterns

Field	Number	Description
UNSET	0	Inherit from parent if possible. Otherwise treated as CLUSTER.
NAMESPACE	1	The workload may talk to any service in its own namespace.
GROUP	2	The workload may talk to any service in the traffic group.
WORKSPACE	3	The workload may talk to any service in the workspace.
CLUSTER	4	The workload may talk to any service in the cluster.
CUSTOM	5	The workload may talk to services defined explicitly.

Sensitivity

Available sensitivity levels for the circuit breaker.

Field	Number	Description
UNSET	0	Default values will be used.
LOW	1	Tolerate up to 20 consecutive 5xx or connection failures from an endpoint before ejecting it temporarily from the load balancing pool.
MEDIUM	2	Tolerate up to 10 consecutive 5xx or connection failures from an endpoint before ejecting it temporarily from the load balancing pool.
HIGH	3	Tolerate up to 5 consecutive 5xx or connection failures from an endpoint before ejecting it temporarily from the load balancing pool.

Sensitivity

Available sensitivity levels for the circuit breaker.

Field	Number	Description
UNSET	0	Default values will be used.
LOW	1	Tolerate up to 20 consecutive 5xx or connection failures from an endpoint before ejecting it temporarily from the load balancing pool.
MEDIUM	2	Tolerate up to 10 consecutive 5xx or connection failures from an endpoint before ejecting it temporarily from the load balancing pool.
HIGH	3	Tolerate up to 5 consecutive 5xx or connection failures from an endpoint before ejecting it temporarily from the load balancing pool.
CUSTOM	4	When selected, the outlier detection settings must be specified in the resilience.outlierDetection field. If that field is set but the mode is not CUSTOM, those settings will be ignored.