Proto: load_balancer_policy.proto




Report on the state of the LoadBalancerPolicyReport

workspaces(repeated LoadBalancerPolicyReport.WorkspacesEntry)

A list of workspaces in which the policy can apply to workloads.

Destination ports selected by the policy





LoadBalancerPolicy provides settings to configure traffic distribution among destination workloads.


The destinations to which the policy should apply. If no selectors are specified, the policy will apply to all destinations in the workspace Only one LoadBalancer policy can apply to a given destination. In case of multiple policies, only the oldest policy will apply and the rest will be given an error status.

The configuration for the load balancer.





Represents the warmup duration of Service. If set, the newly created endpoint of service remains in warmup mode starting from its creation time for the duration of this window and Istio progressively increases amount of traffic for that endpoint instead of sending proportional amount of traffic. This should be enabled for services that require warm up time to serve full production load with reasonable latency. Please note that this is most effective when few new endpoints come up like scale event in Kubernetes. When all the endpoints are relatively new like new deployment, this is not very effective as all endpoints end up getting same amount of requests. Currently this is only supported for ROUND_ROBIN and LEAST_REQUEST load balancers.

A threshold at which Envoy will disregard health status and balance either among all hosts or no hosts. If not specified, the default is 50%. To disable panic mode, set to 0%.

Health check/weight/metadata updates that happen within this duration will be merged and delivered in one shot when the duration expires. If not specified, the default is 1000ms. To disable it, set the merge window to 0.


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.


Hash based on a specific HTTP header.

Hash based on HTTP cookie.

Hash based on the source IP address. This is applicable for both TCP and HTTP connections.

Hash based on a specific HTTP query parameter.


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.


Name of the cookie.

Path to set for the cookie.

Lifetime of the cookie.


The status of the policy after it is applied to your Gloo environment.Status


The state and workspace conditions of the applied resource.

The number of destination ports selected by the policy.


Standard load balancing algorithms that require no tuning.

UNSPECIFIED0No load balancing algorithm has been specified by the user. Istio will select an appropriate default.
RANDOM1The 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.
PASSTHROUGH2This 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_ROBIN3A basic round robin load balancing policy. This is generally unsafe for many scenarios (e.g. when endpoint weighting is used) as it can overburden endpoints. In general, we recommend using LEAST_REQUEST as a drop-in replacement for ROUND_ROBIN.
LEAST_REQUEST4The 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.