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)The list of destination ports selected by the policy. |
LoadBalancerPolicyReport.WorkspacesEntry
| Field | Description |
|---|---|
key | (string) |
value | (common.gloo.solo.io.Report) |
LoadBalancerPolicySpec
Specifications for the policy.
| Field | Description |
|---|---|
applyToDestinations | (repeated common.gloo.solo.io.DestinationSelector)Destinations to apply the policy to. If empty or unset, the policy applies to all destinations in the workspace. Configuration constraints: Only one load balancer policy can apply to a destination. Subsequent policies (sorted by creation time) are ignored and put into a FAILED state. |
config | (LoadBalancerPolicySpec.Config)The configuration for load balancer settings. |
LoadBalancerPolicySpec.Config
The configuration for load balancer settings.
| Field | Description |
|---|---|
simple | (LoadBalancerPolicySpec.Config.SimpleLB)Set a load balancing algorithm for selecting upstream services to forward incoming requests to. |
consistentHash | (LoadBalancerPolicySpec.Config.ConsistentHashLB)Set up soft session affinity between a client and an upstream service by using a consistent hashing algorithm based on HTTP headers, cookies, or other properties. |
warmupDurationSecs | (google.protobuf.Duration)The warm-up duration for a service. If set, the newly created endpoint of the service remains in warm-up mode, starting from its creation time and for the duration of this window. The gateway progressively increases the amount of traffic for that endpoint instead of sending a proportional amount of traffic. This setting is effective in scaling events, such as when new replicas are added to handle increased load. However, if all services start at the same time, this setting might not be as effective as all endpoints receiving the same amount of requests. Implementation notes: This setting is supported only when config.simple is set to ROUND_ROBIN (default) or LEAST_REQUEST.Configuration constraints:
|
healthyPanicThreshold | (google.protobuf.DoubleValue)The threshold at which Envoy disregards the upstream health status and either load balances requests either among all or no hosts. Implementation notes:
Configuration constraints: The value must be in the range 0 - 100, inclusive. |
updateMergeWindow | (google.protobuf.Duration)The duration of time within which the gateway merges all health check, weight, and metadata updates together. Implementation notes:
Configuration constraints:
|
LoadBalancerPolicySpec.Config.ConsistentHashLB
Provide soft session affinity based on HTTP headers, cookies, the source IP address, or a query parameter. The affinity to a particular destination host might be lost when one or more hosts are added or removed from the destination service.
Consistent hashing is less reliable than a common sticky session implementation, in which the upstream service is encoded in a cookie and affinity can be maintained for as long as the upstream service is available. With consistent hashing, affinity might be lost when an upstream service is added or removed.
Consistent hashing requires all proxies to be aware of the same endpoints. This requirement is not met if you configure locality-based load balancing and proxies are spread across localities. To use locality-based load balancing and consistent hashing together, all proxies must be in the same locality, or a high-level load balancer must handle locality affinity.
When using consistent hashing for virtual destinations in a multicluster setup,
you must set spec.clientMode.tlsTermination to {} on the virtual destination
to ensure proper hashing through the east-west gateway.
Keep in mind the following considerations when enabling TLS termination on a virtual destination:
With TLS termination enabled, the gateway allows traffic to be forwarded to both mTLS and non-mTLS workloads. For mTLS workloads, a new TLS connection is established with the destination before traffic is forwarded. However, unencrypted traffic is forwarded to non-mTLS workloads.
The SPIFFE ID of the request changes from the client to the east-west gateway. An Istio Authorization policy is automatically created that allows traffic from the east-west gateway. This can impact metrics collection as you might not be able to determine the clients that the request came from.
Configuration constraints: Only one of the following settings can be set.
| Field | Description |
|---|---|
httpHeaderName | (string)Hash based on a specific HTTP header. |
httpCookie | (LoadBalancerPolicySpec.Config.ConsistentHashLB.HTTPCookie)Hash based on an 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
An HTTP cookie that is used as the hash key for the consistent hash load balancer. If the cookie is not present, it is 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. Configuration constraints:
|
LoadBalancerPolicyStatus
The status of the policy after it is applied to your Gloo environment.
| 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
The load balancing algorithm for selecting upstream services to forward incoming requests to.
| Name | Number | Description |
|---|---|---|
UNSPECIFIED | 0 | No load balancing algorithm is specified. Istio selects an appropriate algorithm. |
RANDOM | 1 | The 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 | Forward the connection to the original IP address requested by the caller without doing any form of load balancing. Use caution with this setting, which is intended only for advanced use cases. |
ROUND_ROBIN | 3 | The load balancer performs basic round robin load balancing. This algorithm is generally unsafe for many scenarios, such as when endpoint weighting is used, as it can overburden endpoints. In general, LEAST_REQUEST is recommended as a drop-in replacement for ROUND_ROBIN. |
LEAST_REQUEST | 4 | The request load balancer spreads load across endpoints, favoring endpoints with the least outstanding requests. This is generally safer and performs better than ROUND_ROBIN in nearly all cases. |