LoadBalancerPolicy
LoadBalancerPolicy API reference.
Proto: load_balancer_policy.proto
Package: trafficcontrol.policy.gloo.solo.io
LoadBalancerPolicyReport
Report on the state of the LoadBalancerPolicyReport
| Field | Description |
|---|---|
workspaces | (repeated LoadBalancerPolicyReport.WorkspacesEntry)A list of workspaces in which the policy can apply to workloads. |
selectedDestinationPorts | (repeated common.gloo.solo.io.DestinationReference)Destination ports selected by the policy |
LoadBalancerPolicyReport.WorkspacesEntry
| Field | Description |
|---|---|
key | (string) |
value | (common.gloo.solo.io.Report) |
LoadBalancerPolicySpec
LoadBalancerPolicy provides settings to configure traffic distribution among destination workloads.
| Field | Description |
|---|---|
applyToDestinations | (repeated common.gloo.solo.io.DestinationSelector) |
config | (LoadBalancerPolicySpec.Config) |
LoadBalancerPolicySpec.Config
| Field | Description |
|---|---|
simple | (LoadBalancerPolicySpec.Config.SimpleLB) |
consistentHash | (LoadBalancerPolicySpec.Config.ConsistentHashLB) |
warmupDurationSecs | (google.protobuf.Duration)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. |
healthyPanicThreshold | (google.protobuf.DoubleValue)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%. |
updateMergeWindow | (google.protobuf.Duration)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. |
LoadBalancerPolicySpec.Config.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 |
|---|---|
httpHeaderName | (string)Hash based on a specific HTTP header. |
httpCookie | (LoadBalancerPolicySpec.Config.ConsistentHashLB.HTTPCookie)Hash based on HTTP cookie. |
useSourceIp | (bool)Hash based on the source IP address. This is applicable for both TCP and HTTP connections. |
httpQueryParameterName | (string)Hash based on a specific HTTP query parameter. |
LoadBalancerPolicySpec.Config.ConsistentHashLB.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 |
|---|---|
name | (string)Name of the cookie. |
path | (string)Path to set for the cookie. |
ttl | (google.protobuf.Duration)Lifetime of the cookie. |
LoadBalancerPolicyStatus
The status of the policy after it is applied to your Gloo environment.Status
| Field | Description |
|---|---|
common | (common.gloo.solo.io.Status)The state and workspace conditions of the applied resource. |
numSelectedDestinationPorts | (uint32)The number of destination ports selected by the policy. |
LoadBalancerPolicySpec.Config.SimpleLB
Standard load balancing algorithms that require no tuning.
| Name | Number | Description |
|---|---|---|
UNSPECIFIED | 0 | No load balancing algorithm has been specified by the user. Istio will select an appropriate default. |
RANDOM | 1 | 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 | 2 | 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 | 3 | A 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_REQUEST | 4 | 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. |