mirror of https://github.com/status-im/consul.git
[NET-5916] Update locality-aware routing docs (#19529)
* docs: Update locality-aware routing docs - Align locality-aware routing documentation to the recommended use of the feature and incorporate engineer feedback. - Remove docs for unreleased multi-cluster failover feature. - Fix minor typos and formatting in examples. * docs: Fix rate limit docs typo
This commit is contained in:
Michael Zalimeni
GitHub
parent
28b1469cb8
commit
c9f2a6add4
|
|
@ -1284,9 +1284,9 @@ subsystem that provides Consul's service mesh capabilities.
|
|||
corresponding to the NIST P-\* curves of the same name.
|
||||
- `private_key_type = rsa`: `2048, 4096`
|
||||
|
||||
- `locality` <EnterpriseAlert inline/>: Specifies a map of configurations that set the region and zone of the Consul agent. When specified on server agents, `locality` applies to all partitions on the server. When specified on clients, `locality` applies to all services registered to the client. Configure this field to enable Consul to route traffic to the nearest physical service instance. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
- `region`: String value that specifies the region where the Consul agent is running. Consul matches this value to regions defined for services in the network. When service agent regions match, Consul is able to prioritize routes between the agent and the service in the same region over healthy service instances in other regions. When multiple healthy service instances are available in the local region, Consul prioritizes services that match the agent's `zone`. You must specify values that are consistent with how regions are defined in your network, for example `us-west-1` for networks in AWS.
|
||||
- `zone`: String value that specifies the availability zone where the Consul agent is running. Consul matches this value to zones defined for services in the region. When service agent zones match, Consul is able to prioritize routes between the agent and the service in the same zone over healthy service instances in other zones. When multiple healthy service instances are available in the local zone, Consul distributes traffic equally the services. You must specify values that are consistent with how zones are defined in your network, for example `us-west-1a` for networks in AWS.
|
||||
- `locality` <EnterpriseAlert inline/>: Specifies a map of configurations that set the region and zone of the Consul agent. When specified on server agents, `locality` applies to all partitions on the server. When specified on clients, `locality` applies to all services registered to the client. Configure this field to enable Consul to route traffic to the nearest physical service instance. This field is intended for use primarily with VM and Nomad workloads. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
- `region`: String value that specifies the region where the Consul agent is running. Consul assigns this value to services registered to that agent. When service proxy regions match, Consul is able to prioritize routes between service instances in the same region over instances in other regions. You must specify values that are consistent with how regions are defined in your network, for example `us-west-1` for networks in AWS.
|
||||
- `zone`: String value that specifies the availability zone where the Consul agent is running. Consul assigns this value to services registered to that agent. When service proxy regions match, Consul is able to prioritize routes between service instances in the same region and zone over instances in other regions and zones. When healthy service instances are available in multiple zones within the most-local region, Consul prioritizes instances that also match the downstream proxy's `zone`. You must specify values that are consistent with how zones are defined in your network, for example `us-west-1a` for networks in AWS.
|
||||
|
||||
## DNS and Domain Parameters
|
||||
|
||||
|
|
|
|||
|
|
@ -50,9 +50,7 @@ The following list outlines field hierarchy, language-specific data types, and r
|
|||
- [`ListenerPort`](#expose-paths): number | `0`
|
||||
- [`Protocol`](#expose-paths): string | `http`
|
||||
- [`PrioritizeByLocality`](#prioritizebylocality): map | <EnterpriseAlert inline/>
|
||||
- [`Mode`](#prioritizebylocality): string | `failover`
|
||||
- [`FailoverPolicy`](#failoverpolicy): map
|
||||
- [`Mode`](#failoverpolicy-mode): string
|
||||
- [`Mode`](#prioritizebylocality): string | `failover`
|
||||
- [`AccessLogs`](#accesslogs): map
|
||||
- [`Enabled`](#accesslogs): boolean | `false`
|
||||
- [`DisableListenerLogs`](#accesslogs): boolean | `false`
|
||||
|
|
@ -92,9 +90,7 @@ The following list outlines field hierarchy, language-specific data types, and r
|
|||
- [`listenerPort`](#spec-expose-paths): number | `0`
|
||||
- [`protocol`](#spec-expose-paths): string | `http`
|
||||
- [`prioritizeByLocality`](#prioritizebylocality): map | <EnterpriseAlert inline/>
|
||||
- [`mode`](#prioritizebylocality): string | `failover`
|
||||
- [`failoverPolicy`](#spec-failoverpolicy): map
|
||||
- [`mode`](#spec-failoverpolicy-mode): string
|
||||
- [`mode`](#prioritizebylocality): string | `failover`
|
||||
- [`accessLogs`](#spec-accesslogs): map
|
||||
- [`enabled`](#spec-accesslogs): boolean | `false`
|
||||
- [`disableListenerLogs`](#spec-accesslogs): boolean | `false`
|
||||
|
|
@ -467,29 +463,15 @@ The following table describes the parameters for each map you can define in the
|
|||
|
||||
### `PrioritizeByLocality`
|
||||
|
||||
Sets a default `mode` for proxies that allows them to prioritize upstream targets that are in the same geographic area. You can specify the following string values for the `mode` field:
|
||||
Sets a mode for the service that allows instances to prioritize upstream targets that are in the same network region and zone. You can specify the following string values for the `mode` field:
|
||||
|
||||
- `failover`: If the upstream target that a service is connected to becomes unreachable, the service prioritizes a healthy upstream with the same `locality` configuration. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
- `failover`: If the upstream targets that a service is connected to become unreachable, the service prioritizes healthy upstream instances with matching `Locality` configuration. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: Map
|
||||
|
||||
### `FailoverPolicy`
|
||||
|
||||
Sets the failover policy `mode` field for all proxies. The failover policy mode defines how Consul directs traffic to failover service instances if the primary instance becomes unreachable. For example, you can direct Consul to send failover traffic to local service instances. Refer to [Failover overview](/consul/docs/connect/manage-traffic/failover) for additional information.
|
||||
|
||||
You can specify the following string values for the `mode` field:
|
||||
|
||||
- `default`: Envoy sends failover traffic to the first failover target with healthy instances.
|
||||
- `order-by-locality`: Envoy prioritizes failover targets that are closer to the downstream service. Envoy deterministically orders failover targets that are the same distance from the local proxy.
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: Map containing the `mode` field
|
||||
|
||||
### `AccessLogs`
|
||||
|
||||
Specifies [Envoy access logger](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/access_logging.html?highlight=access%20logs) configurations for all proxies in the service mesh, including gateways. This field also configures access logs on [Envoy's administration interface](https://www.envoyproxy.io/docs/envoy/latest/operations/admin.html?highlight=administration%20logs).
|
||||
|
|
@ -710,30 +692,15 @@ The following table describes the parameters for each map you can define in the
|
|||
|
||||
### `spec.prioritizeByLocality`
|
||||
|
||||
Sets a default `mode` for proxies that allows them to prioritize upstream targets that are in the same geographic area. You can specify the following string values for the `mode` field:
|
||||
Sets a mode for the service that allows instances to prioritize upstream targets that are in the same network region and zone. You can specify the following string values for the `mode` field:
|
||||
|
||||
- `failover`: If the upstream target that a service is connected to becomes unreachable, the service prioritizes a healthy upstream with the same `locality` configuration. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
- `failover`: If the upstream targets that a service is connected to become unreachable, the service prioritizes healthy upstream instances with matching `locality` configuration. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: Map
|
||||
|
||||
|
||||
### `spec.failoverPolicy`
|
||||
|
||||
Sets the failover policy `mode` field for all proxies. The failover policy mode defines how Consul directs traffic to failover service instances if the primary instance becomes unreachable. For example, you can direct Consul to send failover traffic to local service instances. Refer to [Failover overview](/consul/docs/connect/manage-traffic/failover) for additional information.
|
||||
|
||||
You can specify the following string values for the `mode` field:
|
||||
|
||||
- `default`: Envoy sends failover traffic to the first failover target with healthy instances.
|
||||
- `order-by-locality`: Envoy prioritizes failover targets that are closer to the downstream service. Envoy deterministically orders failover targets that are the same distance from the local proxy.
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- Data type: Map containing the `mode` field
|
||||
|
||||
### `spec.accessLogs`
|
||||
|
||||
Specifies [Envoy access logger](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/access_logging.html?highlight=access%20logs) configurations for all proxies in the service mesh, including gateways. This field also configures access logs on [Envoy's administration interface](https://www.envoyproxy.io/docs/envoy/latest/operations/admin.html?highlight=administration%20logs).
|
||||
|
|
|
|||
|
|
@ -205,7 +205,7 @@ BalanceInboundConnections = "exact_balance"
|
|||
Mode = "<mode for directing traffic>"
|
||||
RateLimits = {
|
||||
InstanceLevel = {
|
||||
RequestsPerScond = <average number of requests allowed to the service per second>
|
||||
RequestsPerSecond = <average number of requests allowed to the service per second>
|
||||
RequestsMaxBurst = <max number of concurrent requests allowed to the service>
|
||||
Routes = [ # Configure RequestsPerSecond and one route matching parameter for each member of the list
|
||||
{
|
||||
|
|
@ -318,7 +318,7 @@ spec:
|
|||
mode: <mode for directing traffic>
|
||||
rateLimits:
|
||||
instanceLevel:
|
||||
requestsPerScond: <average number of requests allowed to the service per second>
|
||||
requestsPerSecond: <average number of requests allowed to the service per second>
|
||||
requestsMaxBurst: <max number of concurrent requests allowed to the service>
|
||||
routes: # Configure RequestsPerSecond and one route matching parameter for each member of the list
|
||||
- pathExact: "<limits apply paths that match this value>"
|
||||
|
|
@ -409,7 +409,7 @@ spec:
|
|||
"Mode": "<mode for directing traffic>",
|
||||
"RateLimits": {
|
||||
"InstanceLevel": {
|
||||
"RequestsPerScond": 100,
|
||||
"RequestsPerSecond": 100,
|
||||
"RequestsMaxBurst": 200,
|
||||
"Routes": [
|
||||
{
|
||||
|
|
@ -623,7 +623,7 @@ Map containing a set of request rate limit configurations for instances of the s
|
|||
- Default: None
|
||||
- Data type: Map
|
||||
|
||||
### `RateLimits{}.InstanceLevel{}.RequestsPerScond`
|
||||
### `RateLimits{}.InstanceLevel{}.RequestsPerSecond`
|
||||
|
||||
Specifies the average number of requests per second allowed to the service. If the [`RequestsMaxBurst`](#ratelimits-instancelevel-requestsmaxburst) parameter is set, the number of requests per second to the service can temporarily exceed the limit specified in the `RequestsPerSecond` up to the value specified in `RequestsMaxBurst`. Internally, this is the refill rate of the token bucket used for rate limiting.
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ The following list outlines field hierarchy, language-specific data types, and r
|
|||
- [`Datacenter`](#redirect-datacenter): string
|
||||
- [`Peer`](#redirect-peer): string
|
||||
- [`PrioritizeByLocality`](#prioritizebylocality): map <EnterpriseAlert inline/>
|
||||
- [`Mode`](#prioritizebylocality): string | `failover`
|
||||
- [`Mode`](#prioritizebylocality): string | `failover`
|
||||
- [`Failover`](#failover): map
|
||||
- [`Service`](#failover-service): string
|
||||
- [`ServiceSubset`](#failover-servicesubset): string
|
||||
|
|
@ -171,7 +171,7 @@ Redirect = {
|
|||
}
|
||||
|
||||
PrioritizeByLocality = {
|
||||
Mode = "failover"
|
||||
Mode = "failover"
|
||||
}
|
||||
|
||||
Failover = { ## requires at least one of the following: Service, ServiceSubset, Namespace, Targets, Datacenters, SamenessGroup
|
||||
|
|
@ -195,12 +195,12 @@ Failover = { ## requires at least one of the following: Servic
|
|||
|
||||
LoadBalancer = {
|
||||
Policy = "random"
|
||||
LeastRequestConfig = { ## requires Policy = "least_request"
|
||||
LeastRequestConfig = { ## requires Policy = "least_request"
|
||||
ChoiceCount = 2
|
||||
RingHashConfig = { ## requires Policy = "ring_hash"
|
||||
MinimumRingSize = 1024
|
||||
MaximumRingSize = 8192
|
||||
}
|
||||
RingHashConfig = { ## requires Policy = "ring_hash"
|
||||
MinimumRingSize = 1024
|
||||
MaximumRingSize = 8192
|
||||
}
|
||||
HashPolicies = [
|
||||
{
|
||||
|
|
@ -257,7 +257,7 @@ LoadBalancer = {
|
|||
},
|
||||
"PrioritizeByLocality" : {
|
||||
"Mode": "failover"
|
||||
},
|
||||
},
|
||||
"Failover":{ // requires at least one of the following": Service, ServiceSubset, Namespace, Targets, Datacenters, SamenessGroup
|
||||
"<local=subset-name>":{
|
||||
"Targets":[
|
||||
|
|
@ -552,9 +552,9 @@ Specifies the cluster with an active cluster peering connection at the redirect
|
|||
|
||||
### `PrioritizeByLocality`
|
||||
|
||||
Sets a mode for the service that allows instances to prioritize upstream targets that are in the same geographic area. You can specify the following string values for the `mode` field:
|
||||
Sets a mode for the service that allows instances to prioritize upstream targets that are in the same network region and zone. You can specify the following string values for the `mode` field:
|
||||
|
||||
- `Failover`: If the upstream target that a service is connected to becomes unreachable, the service prioritizes a healthy upstream with the same `Locality` configuration. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
- `failover`: If the upstream targets that a service is connected to become unreachable, the service prioritizes healthy upstream instances with matching `Locality` configuration. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
|
||||
#### Values
|
||||
|
||||
|
|
@ -1023,11 +1023,11 @@ Specifies the cluster with an active cluster peering connection at the redirect
|
|||
- Default: None
|
||||
- Data type: String
|
||||
|
||||
### `spec.prioritizeByLocality`
|
||||
### `spec.prioritizeByLocality`
|
||||
|
||||
Sets a mode for the service that allows instances to prioritize upstream targets that are in the same geographic area. You can specify the following string values for the `mode` field:
|
||||
Sets a mode for the service that allows instances to prioritize upstream targets that are in the same network region and zone. You can specify the following string values for the `mode` field:
|
||||
|
||||
- `failover`: If the upstream target that a service is connected to becomes unreachable, the service prioritizes a healthy upstream with the same `locality` configuration. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
- `failover`: If the upstream targets that a service is connected to become unreachable, the service prioritizes healthy upstream instances with matching `locality` configuration. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
|
||||
#### Values
|
||||
|
||||
|
|
|
|||
|
|
@ -51,4 +51,4 @@ You can configure a sameness group so that it functions as the default for failo
|
|||
|
||||
## Locality-aware routing
|
||||
|
||||
By default, Consul balances traffic to all healthy upstream instances in the cluster, even if the instances are in different network regions and zones. You can configure Consul to route requests to upstreams in the same geographic region, which reduces latency and transfer costs. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
By default, Consul balances traffic to all healthy upstream instances in the cluster, even if the instances are in different network regions and zones. You can configure Consul to route requests to upstreams in the same region and zone, which reduces latency and transfer costs. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
|
|
@ -81,4 +81,4 @@ Service resolver configuration entries can also process network layer, also call
|
|||
|
||||
## Locality-aware routing
|
||||
|
||||
By default, Consul balances traffic to all healthy upstream instances in the cluster, even if the instances are in different availability zones. You can configure Consul to route requests to upstreams in the same network zone, which reduces latency and transfer costs. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
By default, Consul balances traffic to all healthy upstream instances in the cluster, even if the instances are in different network regions and zones. You can configure Consul to route requests to upstreams in the same region and zone, which reduces latency and transfer costs. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
|
|
|
|||
|
|
@ -6,16 +6,20 @@ description: Learn how to enable locality-aware routing in Consul so that proxie
|
|||
|
||||
# Route traffic to local upstreams
|
||||
|
||||
This topic describes how to enable locality-aware routing so that Consul can prioritize sending traffic to upstream services that are in the same region and zone as the downstream service. You should only follow these instructions when every service within a zone has at least enough capacity to handle requests from downstream services within the same zone.
|
||||
This topic describes how to enable locality-aware routing so that Consul can prioritize sending traffic to upstream services that are in the same region and zone as the downstream service.
|
||||
|
||||
<EnterpriseAlert> This feature is available in Consul Enterprise. </EnterpriseAlert>
|
||||
|
||||
!> **Warning**: Locality-aware routing is an advanced feature that may adversely impact service capacity if used incorrectly. By default, this feature routes 100% of traffic to the most local set of service instances, and failover only occurs when there are no healthy instances available in the most local set. You should only follow these instructions when every service within a zone has enough capacity to handle requests from downstream services within the same zone.
|
||||
|
||||
-> **Note**: It is possible to adjust the load balancing and failover behavior for this feature globally or per-service via the [Property Override Envoy extension](/consul/docs/connect/proxies/envoy-extensions/usage/property-override). Please familiarize with Envoy docs on [`overprovisioning_factor`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/endpoint/v3/endpoint.proto#config-endpoint-v3-clusterloadassignment) and [outlier detection](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/cluster/v3/outlier_detection.proto#config-cluster-v3-outlierdetection) before attempting to modify configuration.
|
||||
|
||||
## Introduction
|
||||
|
||||
By default, Consul balances traffic to all healthy upstream instances in the cluster, even if the instances are in different network zones. You can specify the cloud service provider (CSP) locale for Consul server agents and services registered to the service mesh, which enables several benefits:
|
||||
By default, Consul balances traffic to all healthy upstream instances in the cluster, even if the instances are in different network zones. You can specify the cloud service provider (CSP) locality for Consul server agents and services registered to the service mesh, which enables several benefits:
|
||||
|
||||
- Consul prioritizes the nearest upstream when routing traffic through the mesh.
|
||||
- When a service instance in the same partition becomes unhealthy, Consul prioritizes failing over to upstream services that are in the same region as the downstream service. Refer to [Failover](/consul/docs/connect/traffic-management/failover) for additional information about failover strategies in Consul.
|
||||
- Consul prioritizes the nearest upstream instances when routing traffic through the mesh.
|
||||
- When upstream service instances becomes unhealthy, Consul prioritizes failing over to instances that are in the same region as the downstream service. Refer to [Failover](/consul/docs/connect/traffic-management/failover) for additional information about failover strategies in Consul.
|
||||
|
||||
When properly implemented, routing traffic to local upstreams can reduce latency and transfer costs associated with sending requests to other regions.
|
||||
|
||||
|
|
@ -23,12 +27,10 @@ When properly implemented, routing traffic to local upstreams can reduce latency
|
|||
|
||||
For networks deployed to virtual machines, complete the following steps to route traffic to local upstream services:
|
||||
|
||||
1. Specify the region and zone for your Consul client agents.
|
||||
1. It is not required, but you can specify the region and zone for your services. Skip this step to allow services to inherit the region and zone configured for the Consul client that the services are registered with.
|
||||
1. Enable service mesh proxies to route traffic locally within the partition.
|
||||
1. Start service mesh proxies.
|
||||
1. Specify the region and zone for your Consul client agents. This allows services to inherit the region and zone configured for the Consul agent that the services are registered with.
|
||||
1. Configure service mesh proxies to route traffic locally within the partition.
|
||||
|
||||
For Kubernetes-orchestrated networks, Consul automatically populates geographic information about service instances using the `topology.kubernetes.io/region` and `topology.kubernetes.io/zone` annotations from the Kubernetes nodes. As a result, you do not need to specify the regions and zones unless you are implementing a custom Kuberenetes deployment.
|
||||
For Kubernetes-orchestrated networks using `consul-k8s`, Consul automatically populates geographic information about service instances using the `topology.kubernetes.io/region` and `topology.kubernetes.io/zone` annotations from the Kubernetes nodes. Similarly, when deploying on AWS ECS using `consul-ecs`, the `AWS_REGION` environment variable and `AvailabilityZone` attribute of the ECS task meta are used. As a result, you do not need to specify the regions and zones on these platforms unless you are implementing a custom deployment.
|
||||
|
||||
## Specify the locality of your Consul agents
|
||||
|
||||
|
|
@ -49,11 +51,11 @@ locality = {
|
|||
}
|
||||
```
|
||||
|
||||
## Specify the localities of your service instances
|
||||
## Specify the localities of your service instances (optional)
|
||||
|
||||
You may only need to configure service localities in service mesh deployments that use [Consul dataplane](/consul/docs/connect/dataplane). This step is optional for networks deployed to virtual machines, which you should allow services to inherit the localities of the Consul agent that they are registered with.
|
||||
-> This step is not typically required and should only be used if defining a custom network topology or your deployed environment requires explicitly setting the locality of certain services instances. Otherwise, follow the instructions above for VM workloads. For Kubernetes and ECS deployments using `consul-k8s` / `consul-ecs`, locality information will be inherited from the host machine.
|
||||
|
||||
1. Configure the `locality` block in your service definition. The `locality` block is a map containing the `region` and `zone` parameters. When you start a proxy for the service, Consul passes the locale to the proxy so that it can route traffic accordingly.
|
||||
1. Configure the `locality` block in your service definition. The `locality` block is a map containing the `region` and `zone` parameters. When you start a proxy for the service, Consul passes the locality to the proxy so that it can route traffic accordingly.
|
||||
|
||||
The parameters should match the values for regions and zones defined in your network. Refer to [`locality`](/consul/docs/services/configuration/services-configuration-reference#locality) in the services configuration reference for additional information.
|
||||
|
||||
|
|
@ -69,9 +71,12 @@ service {
|
|||
region = "us-west-1"
|
||||
zone = "us-west-1a"
|
||||
}
|
||||
connect = { sidecar_service = {} }
|
||||
}
|
||||
```
|
||||
|
||||
If registering services manually via the `/agent/service/register` API endpoint, you can specify the `locality` configuration in the payload. Refer to [Register Service](/consul/api-docs/agent/service#register-service) in the API documentation for additional information.
|
||||
|
||||
## Enable service mesh proxies to route traffic locally
|
||||
|
||||
You can configure the default routing behavior for all proxies in the mesh as well as configure the routing behavior for specific services.
|
||||
|
|
@ -86,11 +91,12 @@ You can configure the default routing behavior for all proxies in the mesh as we
|
|||
```shell-session
|
||||
$ consul config write proxy-defaults.hcl
|
||||
```
|
||||
|
||||
### Configure routing behavior for individual service
|
||||
|
||||
1. Create a service resolver configuration entry and specify the following fields:
|
||||
- `Name`: Specify the name of the service that the routing behavior defined in the configuration entry applies to.
|
||||
- `PrioritizeByLocality`: This block enables proxies in the mesh to use the region and zone defined in the service configuration to route traffic. Set the `mode` inside the block to - `failover`. Refer to [`PrioritizeByLocality`](/consul/docs/connect/config-entries/service-resolver#prioritzebylocality) in the service resolver reference for details about the configuration.
|
||||
- `Name`: Specify the name of the target upstream service for which downstream clients should use locality-aware routing.
|
||||
- `PrioritizeByLocality`: This block enables proxies in the mesh to use the region and zone defined in the service configuration to route traffic. Set the `mode` inside the block to `failover`. Refer to [`PrioritizeByLocality`](/consul/docs/connect/config-entries/service-resolver#prioritizebylocality) in the service resolver reference for details about the configuration.
|
||||
1. Apply the configuration by either calling the [`/config` HTTP API endpoint](/consul/api-docs/config) or running the [`consul config write` CLI command](/consul/commands/config/write).
|
||||
The following example writes a proxy defaults configuration entry from a local HCL file using the CLI:
|
||||
|
||||
|
|
|
|||
|
|
@ -347,17 +347,17 @@ The following table describes the parameters that you can place in the `connect`
|
|||
|
||||
### `locality` <EnterpriseAlert inline/>
|
||||
|
||||
Map of configurations that specify the region and zone in the cloud service provider (CSP) where the service is available. Configure this field to enable Consul to route traffic to the nearest physical service instance. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
Map of configurations that specify the region and zone in the cloud service provider (CSP) where the service is available. Configure this field to enable Consul to route traffic to the nearest physical service instance. Services inherit the `locality` configuration of the Consul agent they are registered with, but you can explicitly define locality for your service instances if an override is needed. Refer to [Route traffic to local upstreams](/consul/docs/connect/manage-traffic/route-to-local-upstreams) for additional information.
|
||||
|
||||
- Default: None
|
||||
- Data type: Map
|
||||
|
||||
Services inherit the `locality` configuration of the Consul agent they are registered with, but you can explicitly define locale for your services. The following table describes the parameters you can explicitly configure in the `locality` block:
|
||||
The following table describes the parameters you can explicitly configure in the `locality` block:
|
||||
|
||||
| Parameter | Description | Data type | Default |
|
||||
| --- | --- | --- | --- |
|
||||
| `region` | Specifies the region where the service instance is available. You can specify values that map to regions as defined in your network, for example `us-west-1` for networks in AWS. Consul matches this value to regions defined for Consul agents and other services in the network. When the region matches an entity, Consul is able to prioritize routes between service instances in the same region over healthy service instances in other regions. When multiple healthy service instances are available in the local region, Consul prioritizes services that match the `zone`. | String | None |
|
||||
| `zone` | Specifies the zone where the service instance is available. You can specify values that map to zones defined in your network, for example `us-west-1a` for networks in AWS. Consul matches this value to zones defined for Consul agents and other services in the network. When the zone matches an entity, Consul is able to prioritize routes between service instances in the same zone over healthy service instances in other zones. When multiple healthy service instances are available in the local zone, Consul distributes traffic equally the services. | String | None |
|
||||
| `region` | Specifies the region where the Consul agent is running. Consul assigns this value to services registered to that agent. When service proxy regions match, Consul is able to prioritize routes between service instances in the same region over instances in other regions. You must specify values that are consistent with how regions are defined in your network, for example `us-west-1` for networks in AWS. | String | None |
|
||||
| `zone` | Specifies the availability zone where the Consul agent is running. Consul assigns this value to services registered to that agent. When service proxy regions match, Consul is able to prioritize routes between service instances in the same region and zone over instances in other regions and zones. When healthy service instances are available in multiple zones within the most-local region, Consul prioritizes instances that also match the downstream proxy's `zone`. You must specify values that are consistent with how zones are defined in your network, for example `us-west-1a` for networks in AWS. | String | None |
|
||||
|
||||
### weights
|
||||
Object that configures how the service responds to DNS SRV requests based on the service's health status. Configuring allows service instances with more capacity to respond to DNS SRV requests. It also reduces the load on services with checks in `warning` status by giving passing instances a higher weight.
|
||||
|
|
|
|||
Loading…
Reference in New Issue