mirror of https://github.com/hashicorp/consul
Added rate limit section to agent overview, updated headings per style guide
trujillo-adam
parent
9d55cd1f18
commit
5042d8d753
|
|
@ -33,7 +33,7 @@ The following process describes the agent lifecycle within the context of an exi
|
|||
As a result, all nodes will eventually become aware of each other.
|
||||
1. **Existing servers will begin replicating to the new node** if the agent is a server.
|
||||
|
||||
### Failures and Crashes
|
||||
### Failures and crashes
|
||||
|
||||
In the event of a network failure, some nodes may be unable to reach other nodes.
|
||||
Unreachable nodes will be marked as _failed_.
|
||||
|
|
@ -48,7 +48,7 @@ catalog.
|
|||
Once the network recovers or a crashed agent restarts, the cluster will repair itself and unmark a node as failed.
|
||||
The health check in the catalog will also be updated to reflect the current state.
|
||||
|
||||
### Exiting Nodes
|
||||
### Exiting nodes
|
||||
|
||||
When a node leaves a cluster, it communicates its intent and the cluster marks the node as having _left_.
|
||||
In contrast to changes related to failures, all of the services provided by a node are immediately deregistered.
|
||||
|
|
@ -61,6 +61,9 @@ interval of 72 hours (changing the reap interval is _not_ recommended due to
|
|||
its consequences during outage situations). Reaping is similar to leaving,
|
||||
causing all associated services to be deregistered.
|
||||
|
||||
## Limit traffic rates
|
||||
You can define a set of rate limiting configurations that help operators protect Consul servers from excessive or peak usage. The configurations enable you to gracefully degrade Consul servers to avoid a global interruption of service. You can allocate a set of resources to different Consul users and eliminate the risks that some users consuming too many resources pose to others. Consul supports global server rate limiting, which lets configure Consul servers to deny requests that exceed the read or write limits. Refer to [Traffic Rate Limits Overview](/consul/docs/agent/limits/limit-traffic-rates).
|
||||
|
||||
## Requirements
|
||||
|
||||
You should run one Consul agent per server or host.
|
||||
|
|
@ -73,7 +76,7 @@ Refer to the following sections for information about host, port, memory, and ot
|
|||
|
||||
The [Datacenter Deploy tutorial](/consul/tutorials/production-deploy/reference-architecture#deployment-system-requirements) contains additional information, including licensing configuration, environment variables, and other details.
|
||||
|
||||
### Maximum Latency Network requirements
|
||||
### Maximum latency network requirements
|
||||
|
||||
Consul uses the gossip protocol to share information across agents. To function properly, you cannot exceed the protocol's maximum latency threshold. The latency threshold is calculated according to the total round trip time (RTT) for communication between all agents. Other network usages outside of Gossip are not bound by these latency requirements (i.e. client to server RPCs, HTTP API requests, xDS proxy configuration, DNS).
|
||||
|
||||
|
|
@ -82,7 +85,7 @@ For data sent between all Consul agents the following latency requirements must
|
|||
- Average RTT for all traffic cannot exceed 50ms.
|
||||
- RTT for 99 percent of traffic cannot exceed 100ms.
|
||||
|
||||
## Starting the Consul Agent
|
||||
## Starting the Consul agent
|
||||
|
||||
Start a Consul agent with the `consul` command and `agent` subcommand using the following syntax:
|
||||
|
||||
|
|
@ -111,7 +114,7 @@ $ consul agent -data-dir=tmp/consul -dev
|
|||
|
||||
Agents are highly configurable, which enables you to deploy Consul to any infrastructure. Many of the default options for the `agent` command are suitable for becoming familiar with a local instance of Consul. In practice, however, several additional configuration options must be specified for Consul to function as expected. Refer to [Agent Configuration](/consul/docs/agent/config) topic for a complete list of configuration options.
|
||||
|
||||
### Understanding the Agent Startup Output
|
||||
### Understanding the agent startup output
|
||||
|
||||
Consul prints several important messages on startup.
|
||||
The following example shows output from the [`consul agent`](/consul/commands/agent) command:
|
||||
|
|
@ -162,7 +165,7 @@ When running under `systemd` on Linux, Consul notifies systemd by sending
|
|||
this either the `join` or `retry_join` option has to be set and the
|
||||
service definition file has to have `Type=notify` set.
|
||||
|
||||
## Configuring Consul Agents
|
||||
## Configuring Consul agents
|
||||
|
||||
You can specify many options to configure how Consul operates when issuing the `consul agent` command.
|
||||
You can also create one or more configuration files and provide them to Consul at startup using either the `-config-file` or `-config-dir` option.
|
||||
|
|
@ -180,7 +183,7 @@ $ consul agent -config-file=server.json
|
|||
The configuration options necessary to successfully use Consul depend on several factors, including the type of agent you are configuring (client or server), the type of environment you are deploying to (e.g., on-premise, multi-cloud, etc.), and the security options you want to implement (ACLs, gRPC encryption).
|
||||
The following examples are intended to help you understand some of the combinations you can implement to configure Consul.
|
||||
|
||||
### Common Configuration Settings
|
||||
### Common configuration settings
|
||||
|
||||
The following settings are commonly used in the configuration file (also called a service definition file when registering services with Consul) to configure Consul agents:
|
||||
|
||||
|
|
@ -195,7 +198,7 @@ The following settings are commonly used in the configuration file (also called
|
|||
| `addresses` | Block of nested objects that define addresses bound to the agent for internal cluster communication. | `"http": "0.0.0.0"` See the Agent Configuration page for [default address values](/consul/docs/agent/config/config-files#addresses) |
|
||||
| `ports` | Block of nested objects that define ports bound to agent addresses. <br/>See (link to addresses option) for details. | See the Agent Configuration page for [default port values](/consul/docs/agent/config/config-files#ports) |
|
||||
|
||||
### Server Node in a Service Mesh
|
||||
### Server node in a service mesh
|
||||
|
||||
The following example configuration is for a server agent named "`consul-server`". The server is [bootstrapped](/consul/docs/agent/config/cli-flags#_bootstrap) and the Consul GUI is enabled.
|
||||
The reason this server agent is configured for a service mesh is that the `connect` configuration is enabled. Connect is Consul's service mesh component that provides service-to-service connection authorization and encryption using mutual Transport Layer Security (TLS). Applications can use sidecar proxies in a service mesh configuration to establish TLS connections for inbound and outbound connections without being aware of Connect at all. See [Connect](/consul/docs/connect) for details.
|
||||
|
|
@ -243,7 +246,7 @@ connect {
|
|||
|
||||
</CodeTabs>
|
||||
|
||||
### Server Node with Encryption Enabled
|
||||
### Server node with encryption enabled
|
||||
|
||||
The following example shows a server node configured with encryption enabled.
|
||||
Refer to the [Security](/consul/docs/security) chapter for additional information about how to configure security options for Consul.
|
||||
|
|
@ -313,7 +316,7 @@ tls {
|
|||
|
||||
</CodeTabs>
|
||||
|
||||
### Client Node Registering a Service
|
||||
### Client node registering a service
|
||||
|
||||
Using Consul as a central service registry is a common use case.
|
||||
The following example configuration includes common settings to register a service with a Consul agent and enable health checks (see [Checks](/consul/docs/discovery/checks) to learn more about health checks):
|
||||
|
|
@ -371,7 +374,7 @@ service {
|
|||
|
||||
</CodeTabs>
|
||||
|
||||
## Client Node with Multiple Interfaces or IP addresses
|
||||
## Client node with multiple interfaces or IP addresses
|
||||
|
||||
The following example shows how to configure Consul to listen on multiple interfaces or IP addresses using a [go-sockaddr template].
|
||||
|
||||
|
|
@ -422,7 +425,7 @@ advertise_addr = "{{ GetInterfaceIP \"en0\" }}"
|
|||
|
||||
</CodeTabs>
|
||||
|
||||
## Stopping an Agent
|
||||
## Stopping an agent
|
||||
|
||||
An agent can be stopped in two ways: gracefully or forcefully. Servers and
|
||||
Clients both behave differently depending on the leave that is performed. There
|
||||
|
|
|
|||
Loading…
Reference in New Issue