Backport of docs: Fix spelling errors across various pages on the site into release/1.16.x (#18537)
docs: Fix spelling errors across various pages on the site (#18533) This commit fixes numerous spelling errors across the site and also removes unnecessary whitespace that was present in the edited files. Co-authored-by: Blake Covarrubias <blake@covarrubi.as>
This commit is contained in:
hc-github-team-consul-core
GitHub
parent
31b1ac0568
commit
dbc627cb33
|
|
@ -2,7 +2,7 @@
|
|||
layout: commands
|
||||
page_title: 'Commands: Intention List'
|
||||
description: >-
|
||||
The `consul intention list` command returns all L4 service intentions, including a unique ID and intention precendence. It was deprecated in Consul v1.9.0; use `consul config` instead.
|
||||
The `consul intention list` command returns all L4 service intentions, including a unique ID and intention precedence. It was deprecated in Consul v1.9.0; use `consul config` instead.
|
||||
---
|
||||
|
||||
# Consul Intention List
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
layout: commands
|
||||
page_title: 'Commands: KV'
|
||||
description: >-
|
||||
The `consul kv` command interacts with Consul's key/value store. It exposes top level commands to insert, update, read, and delte data from the store.
|
||||
The `consul kv` command interacts with Consul's key/value store. It exposes top level commands to insert, update, read, and delete data from the store.
|
||||
---
|
||||
|
||||
# Consul KV
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
layout: commands
|
||||
page_title: 'Commands: Services Deregister'
|
||||
description: |
|
||||
The `consul services deregister` command removes a service from the Consul catalog. Run the commeand on the agent that initially registered the service.
|
||||
The `consul services deregister` command removes a service from the Consul catalog. Run the command on the agent that initially registered the service.
|
||||
---
|
||||
|
||||
# Consul Agent Service Deregistration
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Corresponding HTTP API Endpoint: [\[PUT\] /v1/agent/service/register](/consul/ap
|
|||
The `services register` command registers a service with the local agent.
|
||||
This command returns after registration and must be paired with explicit
|
||||
service deregistration. This command simplifies service registration from
|
||||
scripts. Refer to [Register Services and Health Checks](/consul/docs/services/usage/register-services-checks) for information about other service registeration methods.
|
||||
scripts. Refer to [Register Services and Health Checks](/consul/docs/services/usage/register-services-checks) for information about other service registration methods.
|
||||
|
||||
The following table shows the [ACLs](/consul/api-docs/api-structure#authentication) required to use the `consul services register` command:
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ description: Learn how to set read and request rate limits on RPC and gRPC traff
|
|||
|
||||
# Limit traffic rates from source IP addresses
|
||||
|
||||
This topic describes how to configure RPC and gRPC traffic rate limits for source IP addresses. This enables you to specify a budget for read and write requests to prevent any single source IP from overwhelming the Consul server and negatively affecting the network. For information about setting global traffic rate limits, refer to [Set a global limit on traffic rates](/consul/docs/agent/limits/usage/set-glogal-traffic-rate-limits). For an overview of Consul's server rate limiting capabilities, refer to [Limit traffic rates overview](/consul/docs/agent/limits/overview).
|
||||
This topic describes how to configure RPC and gRPC traffic rate limits for source IP addresses. This enables you to specify a budget for read and write requests to prevent any single source IP from overwhelming the Consul server and negatively affecting the network. For information about setting global traffic rate limits, refer to [Set a global limit on traffic rates](/consul/docs/agent/limits/usage/set-global-traffic-rate-limits). For an overview of Consul's server rate limiting capabilities, refer to [Limit traffic rates overview](/consul/docs/agent/limits).
|
||||
|
||||
<EnterpriseAlert>
|
||||
|
||||
|
|
@ -69,4 +69,4 @@ $ kubectl apply control-plane-request-limit.yaml
|
|||
|
||||
## Disable request rate limits
|
||||
|
||||
Set the [limits.request_limits.mode](/consul/docs/agent/config/config-files#mode-1) in the agent configuration to `disabled` to allow services to exceed the specified read and write requests limits. The `disabled` mode applies to all request rate limits, even limits specifed in the [control plane request limits configuration entry](/consul/docs/connect/config-entries/control-plane-request-limits). Note that any other mode specified in the agent configuration only applies to global traffic rate limits.
|
||||
Set the [limits.request_limits.mode](/consul/docs/agent/config/config-files#mode-1) in the agent configuration to `disabled` to allow services to exceed the specified read and write requests limits. The `disabled` mode applies to all request rate limits, even limits specified in the [control plane request limits configuration entry](/consul/docs/connect/config-entries/control-plane-request-limit). Note that any other mode specified in the agent configuration only applies to global traffic rate limits.
|
||||
|
|
|
|||
|
|
@ -55,8 +55,8 @@ limits = {
|
|||
|
||||
## Monitor request rate traffic
|
||||
|
||||
You should continue to mmonitor request traffic to ensure that request rates remain within the threshold you defined. Refer to [Monitor traffic rate limit data](/consul/docs/agent/limits/usage/monitor-rate-limits) for instructions about checking metrics and log entries, as well as troubleshooting informaiton.
|
||||
You should continue to monitor request traffic to ensure that request rates remain within the threshold you defined. Refer to [Monitor traffic rate limit data](/consul/docs/agent/limits/usage/monitor-rate-limits) for instructions about checking metrics and log entries, as well as troubleshooting information.
|
||||
|
||||
## Disable request rate limits
|
||||
|
||||
Set the [limits.request_limits.mode](/consul/docs/agent/config/config-files#mode-1) to `disabled` to allow services to exceed the specified read and write requests limits, even limits specifed in the [control plane request limits configuration entry](/consul/docs/connect/config-entries/control-plane-request-limits). Note that any other mode specified in the agent configuration only applies to global traffic rate limits.
|
||||
Set the [`limits.request_limits.mode`](/consul/docs/agent/config/config-files#mode-1) to `disabled` to allow services to exceed the specified read and write requests limits, even limits specified in the [control plane request limits configuration entry](/consul/docs/connect/config-entries/control-plane-request-limit). Note that any other mode specified in the agent configuration only applies to global traffic rate limits.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ To track the free space, Consul must write extra metadata to disk with every wri
|
|||
|
||||
To mitigate risks associated with sudden bursts of log data, Consul tries to limit lots of logs from accumulating in the LogStore. Significantly larger BoltDB files are slower to append to because the tree is deeper and freelist larger. For this reason, Consul's default options associated with snapshots, truncating logs, and keeping the log history have been aggressively set toward keeping BoltDB small rather than using disk IO optimally.
|
||||
|
||||
But the larger the file, the more likely it is to have a large freelist or suddenly form one after a burst of writes. For this reason, the many of Consul's default options asssociated with snapshots, truncating logs, and keeping the log history aggressively keep BoltDT small rather than uisng disk IO more efficiently.
|
||||
But the larger the file, the more likely it is to have a large freelist or suddenly form one after a burst of writes. For this reason, the many of Consul's default options associated with snapshots, truncating logs, and keeping the log history aggressively keep BoltDT small rather than using disk IO more efficiently.
|
||||
|
||||
Other reliability issues, such as [raft replication capacity issues](/consul/docs/agent/telemetry#raft-replication-capacity-issues), are much simpler to solve without the performance concerns caused by storing more logs in BoltDB.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ run the following command:
|
|||
$ systemctl stop consul
|
||||
```
|
||||
|
||||
If your environment uses configuration management automation that might interfere with this process, such as Chef or Puppet, you must disable them until you have completely revereted the storage backend.
|
||||
If your environment uses configuration management automation that might interfere with this process, such as Chef or Puppet, you must disable them until you have completely reverted the storage backend.
|
||||
|
||||
## Remove data directory from target server
|
||||
|
||||
|
|
|
|||
|
|
@ -240,7 +240,7 @@ If you have any active `ReferencePolicy` resources, you will receive output simi
|
|||
from:
|
||||
- group: gateway.networking.k8s.io
|
||||
kind: HTTPRoute
|
||||
namespace: example-namesapce
|
||||
namespace: example-namespace
|
||||
to:
|
||||
- group: ""
|
||||
kind: Service
|
||||
|
|
@ -418,7 +418,7 @@ Ensure that the following requirements are met prior to upgrading:
|
|||
"crossNamespaceSecrets": {
|
||||
"group": "",
|
||||
"kind": "Secret",
|
||||
"name": "cexample-certificate",
|
||||
"name": "example-certificate",
|
||||
"namespace": "certificate-namespace"
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -120,4 +120,4 @@ configuration, but Sentinels determine whether the Redis instance is a
|
|||
primary or a secondary. Enable the
|
||||
[`enable_tag_override`](/consul/docs/services/configuration/services-configuration-reference#enable_tag_override) parameter in your service definition file to tell the Consul agent where the Redis database is running to bypass
|
||||
tags during anti-entropy synchronization. Refer to
|
||||
[Modify anti-entropy synchronozation](/consul/docs/services/usage/define-services#modify-anti-entropy-synchronization) for additional information.
|
||||
[Modify anti-entropy synchronization](/consul/docs/services/usage/define-services#modify-anti-entropy-synchronization) for additional information.
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ If appropriate for your use case, we recommend breaking up a single Consul datac
|
|||
|
||||
Be aware that the number 5,000 is a heuristic for deployments. The number of agents you deploy per datacenter is limited by performance, not Consul itself. Because gossip stability risk is determined by _the rate of agent churn_ rather than _the number of nodes_, a gossip pool with mostly static nodes may be able to operate effectively with more than 5,000 agents. Meanwhile, a gossip pool with highly dynamic agents, such as spot fleet instances and serverless functions where 10% of agents are replaced each day, may need to be smaller than 5,000 agents.
|
||||
|
||||
For additional information about the specifc tests we conducted on Consul deployments at scale in order to generate these recommendations, refer to [Consul Scale Test Report to Observe Gossip Stability](https://www.hashicorp.com/blog/consul-scale-test-report-to-observe-gossip-stability) on the HashiCorp blog.
|
||||
For additional information about the specific tests we conducted on Consul deployments at scale in order to generate these recommendations, refer to [Consul Scale Test Report to Observe Gossip Stability](https://www.hashicorp.com/blog/consul-scale-test-report-to-observe-gossip-stability) on the HashiCorp blog.
|
||||
|
||||
For most use cases, a limit of 5,000 agents is appropriate. When the `consul.serf.queue.Intent` metric is consistently high, it is an indication that the gossip pool cannot keep up with the sustained level of churn. In this situation, reduce the churn by lowering the number agents per datacenter.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ In this diagram, the `default` partition in Consul DC 1 has a cluster peering co
|
|||
|
||||
Cluster peering leverages several components of Consul's architecture to enforce secure communication between services:
|
||||
|
||||
- A _peering token_ contains an embedded secret that securely establishes communication when shared symetrically between datacenters. Sharing this token enables each datacenter's server agents to recognize requests from authorized peers, similar to how the [gossip encryption key secures agent LAN gossip](/consul/docs/security/encryption#gossip-encryption).
|
||||
- A _peering token_ contains an embedded secret that securely establishes communication when shared symmetrically between datacenters. Sharing this token enables each datacenter's server agents to recognize requests from authorized peers, similar to how the [gossip encryption key secures agent LAN gossip](/consul/docs/security/encryption#gossip-encryption).
|
||||
- A _mesh gateway_ encrypts outgoing traffic, decrypts incoming traffic, and directs traffic to healthy services. Consul's service mesh features must be enabled in order to use mesh gateways. Mesh gateways support the specific admin partitions they are deployed on. Refer to [Mesh gateways](/consul/docs/connect/gateways/mesh-gateway) for more information.
|
||||
- An _exported service_ communicates with downstreams deployed in other admin partitions. They are explicitly defined in an [`exported-services` configuration entry](/consul/docs/connect/config-entries/exported-services).
|
||||
- A _service intention_ secures [service-to-service communication in a service mesh](/consul/docs/connect/intentions). Intentions enable identity-based access between services by exchanging TLS certificates, which the service's sidecar proxy verifies upon each request.
|
||||
|
|
@ -75,7 +75,7 @@ The following resources are available to help you use Consul's cluster peering f
|
|||
|
||||
- [Cluster peering](/hcp/docs/consul/usage/cluster-peering)
|
||||
- [Cluster peering topologies](/hcp/docs/consul/usage/cluster-peering/topologies)
|
||||
- [Establish cluster peering connnections on HCP Consul](/hcp/docs/consul/usage/cluster-peering/create-connections)
|
||||
- [Establish cluster peering connections on HCP Consul](/hcp/docs/consul/usage/cluster-peering/create-connections)
|
||||
- [Cluster peering with management plane](/hcp/docs/consul/usage/management-plane#cluster-peering)
|
||||
|
||||
### Reference documentation
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Control Plane Request Limit Configuration Entry Configuration Reference
|
||||
description: Learn how to configure the control-plane-request-limit configuration entry, which defines how Consul agents limit read and reqeust traffic rate limits.
|
||||
description: Learn how to configure the control-plane-request-limit configuration entry, which defines how Consul agents limit read and request traffic rate limits.
|
||||
---
|
||||
|
||||
# Control Plane Request Limit Configuration Entry Configuration Reference
|
||||
|
|
@ -191,7 +191,7 @@ Specifies the maximum number of read and write ACL requests to the Consul server
|
|||
|
||||
### `acl.read_rate`
|
||||
S
|
||||
pecifies the maximum number of ACL read requests per second allowed to the Consul server.
|
||||
Specifies the maximum number of ACL read requests per second allowed to the Consul server.
|
||||
|
||||
#### Values
|
||||
|
||||
|
|
|
|||
|
|
@ -270,7 +270,7 @@ A asterisk wildcard (`*`) cannot be specified as the `Peer`. Added in Consul 1.1
|
|||
- `Partition`: <EnterpriseAlert inline /> Specifies an admin partition in the datacenter to export the service to.
|
||||
A asterisk wildcard (`*`) cannot be specified as the `Partition`.
|
||||
- `SamenessGroup`: <EnterpriseAlert inline /> Specifies as sameness group to export the service to.
|
||||
A asterisk wildcard (`*`) cannot be specified as the `SamennessGroup`.
|
||||
A asterisk wildcard (`*`) cannot be specified as the `SamenessGroup`.
|
||||
|
||||
|
||||
## Examples
|
||||
|
|
|
|||
|
|
@ -588,7 +588,7 @@ Specifies default configurations for connecting upstream services.
|
|||
- Default: None
|
||||
- The data type is a map containing the following parameters:
|
||||
|
||||
- [`MaxConnnections`](#defaults-maxconnections)
|
||||
- [`MaxConnections`](#defaults-maxconnections)
|
||||
- [`MaxPendingRequests`](#defaults-maxpendingrequests)
|
||||
- [`MaxConcurrentRequests`](#defaults-maxconcurrentrequests)
|
||||
|
||||
|
|
@ -963,7 +963,7 @@ Kubernetes-only parameter that specifies the version of the Consul API that the
|
|||
|
||||
### `kind`
|
||||
|
||||
Specifies the type of configuration entry to implement. Must be set to `IngressGatewa`.
|
||||
Specifies the type of configuration entry to implement. Must be set to `IngressGateway`.
|
||||
|
||||
#### Values
|
||||
|
||||
|
|
@ -1115,7 +1115,7 @@ Specifies default configurations for upstream connections.
|
|||
- Default: None
|
||||
- The data type is a map containing the following parameters:
|
||||
|
||||
- [`maxConnnections`](#spec-defaults-maxconnections)
|
||||
- [`maxConnections`](#spec-defaults-maxconnections)
|
||||
- [`maxPendingRequests`](#spec-defaults-maxpendingrequests)
|
||||
- [`maxConcurrentRequests`](#spec-defaults-maxconcurrentrequests)
|
||||
|
||||
|
|
@ -1495,7 +1495,7 @@ The following table describes how to configure SDS parameters. Refer to [Configu
|
|||
|
||||
Refer to the following examples for common ingress gateway configuration patterns:
|
||||
- [Define a TCP listener](#define-a-tcp-listener)
|
||||
- [Use wildcards to define listeners](#use-wilcards-to-define-an-http-listener)
|
||||
- [Use wildcards to define listeners](#use-wildcards-to-define-an-http-listener)
|
||||
- [HTTP listener with path-based routes](#http-listener-with-path-based-routes)
|
||||
|
||||
### Define a TCP listener
|
||||
|
|
|
|||
|
|
@ -571,7 +571,7 @@ You cannot specify [`TLSCertificates{}.CaCertificateProviderInstance`](#jsonwebk
|
|||
|
||||
### `JSONWebKeySet{}.Remote{}.JWKSCluster{}.TLSCertificates{}.CaCertificateProviderInstance`
|
||||
|
||||
Speficies the certificate provider instance for fetching TLS certificates.
|
||||
Specifies the certificate provider instance for fetching TLS certificates.
|
||||
|
||||
#### Values
|
||||
|
||||
|
|
@ -1017,7 +1017,7 @@ You cannot specify [`spec.tlsCertificates.caCertificateProviderInstance`](#spec-
|
|||
|
||||
### `spec.jsonWebKeySet.remote.jwksCluster.tlsCertificates.caCertificateProviderInstance`
|
||||
|
||||
Speficies the certificate provider instance for fetching TLS certificates.
|
||||
Specifies the certificate provider instance for fetching TLS certificates.
|
||||
|
||||
#### Values
|
||||
|
||||
|
|
|
|||
|
|
@ -254,7 +254,7 @@ metadata:
|
|||
namespace: <Consul Enterprise namespace>
|
||||
spec:
|
||||
protocol: tcp
|
||||
balanceInboundConnnections: exact_balance
|
||||
balanceInboundConnections: exact_balance
|
||||
mode: transparent
|
||||
upstreamConfig:
|
||||
overrides:
|
||||
|
|
@ -325,7 +325,7 @@ spec:
|
|||
},
|
||||
"spec": {
|
||||
"protocol": "tcp",
|
||||
"balanceInboundConnnections": "exact_balance",
|
||||
"balanceInboundConnections": "exact_balance",
|
||||
"mode": "transparent",
|
||||
"upstreamConfig": {
|
||||
"overrides": [
|
||||
|
|
@ -476,7 +476,7 @@ You can set the global protocol for proxies in the [`proxy-defaults`](/consul/do
|
|||
#### Values
|
||||
|
||||
- Default: `tcp`
|
||||
- You can speciyf one of the following string values:
|
||||
- You can specify one of the following string values:
|
||||
- `tcp` (default)
|
||||
- `http`
|
||||
- `http2`
|
||||
|
|
@ -535,7 +535,7 @@ Specifies the name of the upstream service that the configuration applies to. We
|
|||
|
||||
### `UpstreamConfig.Overrides[].Namespace` <Enterprise/>
|
||||
|
||||
Specifies the namespace containing the upstream service that the configuration applies to. Do not use the `*` wildcard to prevent the configuration from appling to unintended upstreams.
|
||||
Specifies the namespace containing the upstream service that the configuration applies to. Do not use the `*` wildcard to prevent the configuration from applying to unintended upstreams.
|
||||
|
||||
#### Values
|
||||
|
||||
|
|
@ -1660,7 +1660,7 @@ represents a location outside the Consul cluster. Services can dial destinations
|
|||
proxy upstream config will not fully enable some
|
||||
[L7 features](/consul/docs/connect/l7-traffic).
|
||||
It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
|
||||
In addition, the \`protocol\` of a peered service cannot be overriden. Any value in
|
||||
In addition, the \`protocol\` of a peered service cannot be overridden. Any value in
|
||||
this field is ignored for peered services.
|
||||
`,
|
||||
},
|
||||
|
|
@ -1792,7 +1792,7 @@ represents a location outside the Consul cluster. Services can dial destinations
|
|||
type: 'duration: 30s',
|
||||
description: `The base time that a host is ejected for. The real time is equal to the base
|
||||
time multiplied by the number of times the host has been ejected and is capped by
|
||||
max_ejection_time (Default 300s). If not speficied, inherits Envoy's default value of 30s.`,
|
||||
max_ejection_time (Default 300s). If not specified, inherits Envoy's default value of 30s.`,
|
||||
},
|
||||
],
|
||||
},
|
||||
|
|
@ -1957,7 +1957,7 @@ represents a location outside the Consul cluster. Services can dial destinations
|
|||
type: 'duration: 30s',
|
||||
description: `The base time that a host is ejected for. The real time is equal to the base
|
||||
time multiplied by the number of times the host has been ejected and is capped by
|
||||
max_ejection_time (Default 300s). If not speficied, inherits Envoy's default value of 30s.`,
|
||||
max_ejection_time (Default 300s). If not specified, inherits Envoy's default value of 30s.`,
|
||||
},
|
||||
],
|
||||
},
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ Sources = [
|
|||
Action = "allow" or "deny" # string for L4 intentions
|
||||
Permissions = [
|
||||
{
|
||||
Action = "allow" or "deny" # string for L7 intenions
|
||||
Action = "allow" or "deny" # string for L7 intentions
|
||||
HTTP = {
|
||||
PathExact = "<exact path to match>" # string
|
||||
PathPrefix = "<path prefix to match>" # string
|
||||
|
|
@ -510,7 +510,7 @@ The `Peer` and `Partition` fields are mutually exclusive.
|
|||
|
||||
### `Sources[].SamenessGroup` <EnterpriseAlert inline />
|
||||
|
||||
Specifies the name of a sameness group that the intention allows or denies traffic from. Refer to [create samenes groups](/consul/docs/connect/cluster-peering/usage/create-sameness-groups) for additional information.
|
||||
Specifies the name of a sameness group that the intention allows or denies traffic from. Refer to [create sameness groups](/consul/docs/connect/cluster-peering/usage/create-sameness-groups) for additional information.
|
||||
|
||||
#### Values
|
||||
|
||||
|
|
@ -848,7 +848,7 @@ Specifies the name of an admin partition that the intention allows or denies tra
|
|||
|
||||
### `spec.sources[].samenessGroup` <EnterpriseAlert inline />
|
||||
|
||||
Specifies the name of a sameness group that the intention allows or denies traffic from. Refer to [create samenes groups](/consul/docs/k8s/connect/cluster-peering/usage/create-sameness-groups) for additional information.
|
||||
Specifies the name of a sameness group that the intention allows or denies traffic from. Refer to [create sameness groups](/consul/docs/k8s/connect/cluster-peering/usage/create-sameness-groups) for additional information.
|
||||
|
||||
#### Values
|
||||
|
||||
|
|
|
|||
|
|
@ -220,7 +220,7 @@ LoadBalancer = {
|
|||
"Kind":"service-resolver", // required
|
||||
"Name":"<name-of-service-configuration-applies-to>",
|
||||
"Namespace":"<namespace-configuration-applies-to>",
|
||||
"Partition":"parition-configuration-applies-to>",
|
||||
"Partition":"partition-configuration-applies-to>",
|
||||
"Meta":{
|
||||
"<key>":"<value>"
|
||||
},
|
||||
|
|
@ -798,7 +798,7 @@ Specifies additional configuration options for the `cookie` hash policy type. Th
|
|||
|
||||
### `LoadBalancer{}.HashPolicies[].SourceIP`
|
||||
|
||||
Determines if the hash type should besource IP address. You cannot specify `SourceIP` if `Field` or `FieldValue` are configured.
|
||||
Determines if the hash type should be source IP address. You cannot specify `SourceIP` if `Field` or `FieldValue` are configured.
|
||||
|
||||
#### Values
|
||||
|
||||
|
|
@ -1259,7 +1259,7 @@ Specifies additional configuration options for the `cookie` hash policy type. Th
|
|||
|
||||
### `spec.loadBalancer.hashPolicies[].sourceIP`
|
||||
|
||||
Determines if the hash type should besource IP address. You cannot specify `sourceIP` if `field` or `fieldValue` are configured.
|
||||
Determines if the hash type should be source IP address. You cannot specify `sourceIP` if `field` or `fieldValue` are configured.
|
||||
|
||||
#### Values
|
||||
|
||||
|
|
@ -1346,7 +1346,7 @@ spec:
|
|||
|
||||
### Resolve virtual upstreams
|
||||
|
||||
The folowing example uses the [`Redirect` parameter](#redirect) to expose a set of services to another datacenter as a virtual service.
|
||||
The following example uses the [`Redirect` parameter](#redirect) to expose a set of services to another datacenter as a virtual service.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL" group="hcl">
|
||||
|
|
|
|||
|
|
@ -169,7 +169,7 @@ Routes = [
|
|||
Name = "<text-to-match-in-query-parameter>" ## required when specifying Routes.Match.HTTP.Header
|
||||
Present = false
|
||||
Exact = "<exact-text-to-match-in-query-parameter>"
|
||||
Regex = "<regex-to-match-in-query-paramater>"
|
||||
Regex = "<regex-to-match-in-query-parameter>"
|
||||
]
|
||||
}
|
||||
},
|
||||
|
|
@ -249,7 +249,7 @@ Routes = [
|
|||
"Name": "<text-to-match-in-query-parameter>", // required when specifying Routes.Match.HTTP.Header
|
||||
"Present": false,
|
||||
"Exact": "<exact-text-to-match-in-query-parameter>",
|
||||
"Regex": "<regex-to-match-in-query-paramater>"
|
||||
"Regex": "<regex-to-match-in-query-parameter>"
|
||||
]
|
||||
}
|
||||
},
|
||||
|
|
@ -317,7 +317,7 @@ spec:
|
|||
- name: <text-to-match-in-query-parameter> ## required when specifying spec.routes.match.http.header
|
||||
present: false
|
||||
exact: <exact-text-to-match-in-query-parameter>
|
||||
regex: <regex-to-match-in-query-paramater>
|
||||
regex: <regex-to-match-in-query-parameter>
|
||||
|
||||
destination:
|
||||
service: <service-name-at-destination>
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Usage: `consul-dataplane [options]`
|
|||
|
||||
### Requirements
|
||||
|
||||
Consul Dataplane requires servers running Consul version `v1.14+`. To find a specific version of Consul, refer to [Hashicorp's Official Release Channels](https://www.hashicorp.com/official-release-channels).
|
||||
Consul Dataplane requires servers running Consul version `v1.14+`. To find a specific version of Consul, refer to [HashiCorp's Official Release Channels](https://www.hashicorp.com/official-release-channels).
|
||||
|
||||
### Startup
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Datacenters can reside in different clouds or runtime environments where general
|
|||
|
||||
## Prerequisites
|
||||
|
||||
Mesh gateways can be used with any of the following Consul configrations for managing separate datacenters or partitions.
|
||||
Mesh gateways can be used with any of the following Consul configurations for managing separate datacenters or partitions.
|
||||
|
||||
1. WAN Federation
|
||||
* [Mesh gateways can be used to route service-to-service traffic between datacenters](/consul/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters)
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ Peering {
|
|||
|
||||
```yaml
|
||||
Kind: mesh
|
||||
Peeering:
|
||||
Peering:
|
||||
PeerThroughMeshGateways: true
|
||||
```
|
||||
</CodeTabs>
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ You can create single intentions or create them in batches using the Consul API,
|
|||
|
||||
Consul grants permissions for creating and managing intentions based on the destination, not the source. When ACLs are enabled, services and operators must present a token linked to a policy that grants read and write permissions to the destination service.
|
||||
|
||||
Consul implicitly grants `intentions:read` permissions to destination services when they are configured with `service:read` or `service:write` permissions. This is so that the services can allow or deny inbound connections when they attempt to join the service mesh. Refer to [Service rules](/consul/docs/security/acl/acl-rules#service-rules) for additional information about configuring ALCs for intentions.
|
||||
Consul implicitly grants `intentions:read` permissions to destination services when they are configured with `service:read` or `service:write` permissions. This is so that the services can allow or deny inbound connections when they attempt to join the service mesh. Refer to [Service rules](/consul/docs/security/acl/acl-rules#service-rules) for additional information about configuring ACLs for intentions.
|
||||
|
||||
The default ACL policy configuration determines the default behavior for intentions. If the policy is set to `deny`, then all connections or requests are denied and you must enable them explicitly. Refer to [`default_policy`](/consul/docs/agent/config/config-files#acl_default_policy) for details.
|
||||
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ PluginConfig = {
|
|||
HttpURI = {
|
||||
Service = {
|
||||
Name = "<name of the upstream service>"
|
||||
Namespace = "<Consul namespace containing the usptream service>"
|
||||
Namespace = "<Consul namespace containing the upstream service>"
|
||||
Partition = "<Consul partition containing the upstream service>"
|
||||
}
|
||||
URI = "<URI of the plugin data>"
|
||||
|
|
@ -295,13 +295,13 @@ The following table describes the fields you can specify in the `Service` map:
|
|||
|
||||
### `PluginConfig{}.VmConfig{}.Code{}.Remote{}.HttpURI{}.URI`
|
||||
|
||||
Specifies the URI Envoy uses to fetch the plugin file from the upstream. This field is required for Envoy to retrieve plugin code from a remote location. You must specify the fully-qualified domain name (FDQN) of the remote URI, which includes the protocol, host, and path.
|
||||
Specifies the URI Envoy uses to fetch the plugin file from the upstream. This field is required for Envoy to retrieve plugin code from a remote location. You must specify the fully-qualified domain name (FQDN) of the remote URI, which includes the protocol, host, and path.
|
||||
|
||||
#### Values
|
||||
|
||||
- Default: None
|
||||
- This field is required.
|
||||
- Data type: String value that specifies a FDQN
|
||||
- Data type: String value that specifies a FQDN
|
||||
|
||||
### `PluginConfig{}.VmConfig{}.Code{}.Remote{}.HttpURI{}.Timeout`
|
||||
|
||||
|
|
@ -370,9 +370,9 @@ Specifies the configuration Envoy encodes as bytes and passes to the plugin duri
|
|||
|
||||
### `PluginConfig{}.VmConfig{}.EnvironmentVariables{}`
|
||||
|
||||
Specifies environment variables for Enovy to inject into this VM so that they are available through WASI’s `environ_get` and `environ_get_sizes` system calls.
|
||||
Specifies environment variables for Envoy to inject into this VM so that they are available through WASI's `environ_get` and `environ_get_sizes` system calls.
|
||||
|
||||
In most cases, WASI calls the functions implicitly in your language’s standard library. As a result, you do not need to call them directly. You can also access environment variables as you would on native platforms.
|
||||
In most cases, WASI calls the functions implicitly in your language's standard library. As a result, you do not need to call them directly. You can also access environment variables as you would on native platforms.
|
||||
|
||||
Envoy rejects the configuration if there’s conflict of key space.
|
||||
|
||||
|
|
|
|||
|
|
@ -44,4 +44,4 @@ The `property-override` extension lets you set and unset individual properties o
|
|||
|
||||
### WebAssembly
|
||||
|
||||
The `wasm` extension enables you to configure TCP and HTTP filters that invoke custom WebAssembly (Wasm) plugins. Refer to the [WebAssembly extenstion documentation](/consul/docs/connect/proxies/envoy-extensions/usage/wasm) for more information.
|
||||
The `wasm` extension enables you to configure TCP and HTTP filters that invoke custom WebAssembly (Wasm) plugins. Refer to the [WebAssembly extension documentation](/consul/docs/connect/proxies/envoy-extensions/usage/wasm) for more information.
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Consul supports **four major Envoy releases** at the beginning of each major Con
|
|||
|
||||
### Envoy and Consul Dataplane
|
||||
|
||||
The Consul dataplane component was introduced in Consul v1.14 as a way to manage Envoy proxies without the use of Consul clients. Each new minor version of Consul is released with a new minor version of Consul dataplane, which packages both Envoy and the `consul-dataplane` binary in a single container image. For backwards compatability reasons, each new minor version of Consul will also support the previous minor version of Consul dataplane to allow for seamless upgrades. In addition, each minor version of Consul will support the next minor version of Consul dataplane to allow for extended dataplane support via newer versions of Envoy.
|
||||
The Consul dataplane component was introduced in Consul v1.14 as a way to manage Envoy proxies without the use of Consul clients. Each new minor version of Consul is released with a new minor version of Consul dataplane, which packages both Envoy and the `consul-dataplane` binary in a single container image. For backwards compatibility reasons, each new minor version of Consul will also support the previous minor version of Consul dataplane to allow for seamless upgrades. In addition, each minor version of Consul will support the next minor version of Consul dataplane to allow for extended dataplane support via newer versions of Envoy.
|
||||
|
||||
| Consul Version | Default `consul-dataplane` Version | Other compatible `consul-dataplane` Versions |
|
||||
| ------------------- | ------------------------------------------------------------|----------------------------------------------|
|
||||
|
|
@ -204,7 +204,7 @@ The [Advanced Configuration](#advanced-configuration) section describes addition
|
|||
If you are running Consul on a Windows VM, attempting to bootstrap Envoy with the `consul connect envoy` command returns the following output:
|
||||
|
||||
```shell-session hideClipboard
|
||||
Directly running Envoy is only supported on linux and macOS since envoy itself doesn't build on other plataforms currently.
|
||||
Directly running Envoy is only supported on linux and macOS since envoy itself doesn't build on other platforms currently.
|
||||
Use the -bootstrap option to generate the JSON to use when running envoy on a supported OS or via a container or VM.
|
||||
```
|
||||
|
||||
|
|
@ -423,7 +423,7 @@ definition](/consul/docs/connect/registration/service-registration) or
|
|||
- `base_ejection_time` - The base time that a host is ejected for. The real
|
||||
time is equal to the base time multiplied by the number of times the host has
|
||||
been ejected and is capped by max_ejection_time (Default 300s). If not
|
||||
speficied, inherits Envoy's default value of 30s.
|
||||
specified, inherits Envoy's default value of 30s.
|
||||
|
||||
- `balance_outbound_connections` - Specifies the strategy for balancing outbound connections
|
||||
across Envoy worker threads. Consul service mesh Envoy integration supports the
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
layout: docs
|
||||
page_title: Consul compared to other service meshes
|
||||
description: >-
|
||||
Consul's service mesh provides zero trust networking based on service identities to authorize, authenticate, and encrypt network services. Consul's service mesh can also provide advanced traffic management capabilties. Although there are many similar capabilities between Consul and other providers like Istio, Solo, Linkerd, Kong, Tetrate, and AWS App Mesh, we highlight the main differentiating factors for help customers compare.
|
||||
Consul's service mesh provides zero trust networking based on service identities to authorize, authenticate, and encrypt network services. Consul's service mesh can also provide advanced traffic management capabilities. Although there are many similar capabilities between Consul and other providers like Istio, Solo, Linkerd, Kong, Tetrate, and AWS App Mesh, we highlight the main differentiating factors for help customers compare.
|
||||
---
|
||||
|
||||
# Consul compared to other service mesh software
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
layout: docs
|
||||
page_title: Consul on AWS Elastic Container Service (ECS) Compatability Matrix
|
||||
page_title: Consul on AWS Elastic Container Service (ECS) Compatibility Matrix
|
||||
description: >-
|
||||
The binary for Consul on Amazon Web Services ECS and the Terraform modules for automating deployments are tightly coupled and have specific version requirements. Review compatibility information for versions of Consul and `consul-ecs` to help you choose compatible versions.
|
||||
---
|
||||
|
||||
# Consul on AWS Elastic Container Service (ECS) compatability matrix
|
||||
# Consul on AWS Elastic Container Service (ECS) compatibility matrix
|
||||
|
||||
For every release of Consul on ECS, the `consul-ecs` binary and `consul-ecs` Terraform module are updated. The versions of the Terraform module and binary are tightly coupled. For example, `consul-ecs` 0.5.2 binary must use the `consul-ecs` 0.5.2 Terraform module.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
layout: docs
|
||||
page_title: Consul Enterprise
|
||||
description: >-
|
||||
Consul Enterprise is a paid offering that extends Consul’s open source functions to support large and complex deployments. Learn about scaling infrastructure, simplifying operations, and making networks more resilient with Enterprise. Evaluate Enteprise features with the feature availability and compatibility matrix.
|
||||
Consul Enterprise is a paid offering that extends Consul’s open source functions to support large and complex deployments. Learn about scaling infrastructure, simplifying operations, and making networks more resilient with Enterprise. Evaluate Enterprise features with the feature availability and compatibility matrix.
|
||||
---
|
||||
|
||||
# Consul Enterprise
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ To enable automated reporting, complete the following steps:
|
|||
|
||||
### Allow outbound HTTPS traffic on port 443
|
||||
|
||||
Make sure that your network allows HTTPS egress on port 443 from `https://reporting.hashicorp.services` by adding the following IP adddresses to your allow-list:
|
||||
Make sure that your network allows HTTPS egress on port 443 from `https://reporting.hashicorp.services` by adding the following IP addresses to your allow-list:
|
||||
|
||||
- `100.20.70.12`
|
||||
- `35.166.5.222`
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ This topic describes how to create Consul network segments so that services can
|
|||
[INFO] consul: Started listener for LAN segment "beta" on 10.20.10.11:8304
|
||||
[INFO] serf: EventMemberJoin: server1 10.20.10.11
|
||||
```
|
||||
1. Verfiy that the server is a member of all segments:
|
||||
1. Verify that the server is a member of all segments:
|
||||
|
||||
```shell-session
|
||||
$ consul members
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ When transparent proxy mode is enabled, all service-to-service traffic is requir
|
|||
|
||||
### Kubernetes service mesh workload scenarios
|
||||
|
||||
-> **Note:** A Kubernetes Service is required in order to register services on the Consul service mesh. Consul monitors the lifecyle of the Kubernetes Service and its service instances using the service object. In addition, the Kubernetes service is used to register and de-register the service from Consul's catalog.
|
||||
-> **Note:** A Kubernetes Service is required in order to register services on the Consul service mesh. Consul monitors the lifecycle of the Kubernetes Service and its service instances using the service object. In addition, the Kubernetes service is used to register and de-register the service from Consul's catalog.
|
||||
|
||||
The following configurations are examples for registering workloads on Kubernetes into Consul's service mesh in different scenarios. Each scenario provides an example Kubernetes manifest to demonstrate how to use Consul's service mesh with a specific Kubernetes workload type.
|
||||
|
||||
|
|
@ -244,7 +244,7 @@ spec:
|
|||
echo "Started test job"
|
||||
sleep 10
|
||||
echo "Killing proxy"
|
||||
curl --max-time 2 -s -f -XPOST http://127.0.0.1:20600/graceful_shutdown
|
||||
curl --max-time 2 -s -f -X POST http://127.0.0.1:20600/graceful_shutdown
|
||||
sleep 10
|
||||
echo "Ended test job"
|
||||
serviceAccountName: test-job
|
||||
|
|
@ -269,7 +269,6 @@ test-job 1/1 30s 4m31s
|
|||
|
||||
In addition, based on the logs emitted by the pod you can verify that the proxy was shut down before the Job completed.
|
||||
|
||||
|
||||
```shell-session
|
||||
$ kubectl logs test-job-49st7 -c test-job
|
||||
Started test job
|
||||
|
|
|
|||
|
|
@ -476,7 +476,7 @@ Repeat the following steps for each datacenter in the cluster:
|
|||
acls:
|
||||
manageSystemACLs: true
|
||||
createReplicationToken: true
|
||||
boostrapToken:
|
||||
bootstrapToken:
|
||||
secretName: consul/data/secret/bootstrap
|
||||
secretKey: token
|
||||
replicationToken:
|
||||
|
|
|
|||
|
|
@ -446,7 +446,7 @@ Use these links to navigate to a particular top-level stanza.
|
|||
|
||||
- `secretName` ((#v-global-acls-partitiontoken-secretname)) (`string: null`) - The name of the Vault secret that holds the partition token.
|
||||
|
||||
- `secretKey` ((#v-global-acls-partitiontoken-secretkey)) (`string: null`) - The key within the Vault secret that holds the parition token.
|
||||
- `secretKey` ((#v-global-acls-partitiontoken-secretkey)) (`string: null`) - The key within the Vault secret that holds the partition token.
|
||||
|
||||
- `tolerations` ((#v-global-acls-tolerations)) (`string: ""`) - tolerations configures the taints and tolerations for the server-acl-init
|
||||
and server-acl-init-cleanup jobs. This should be a multi-line string matching the
|
||||
|
|
|
|||
|
|
@ -287,7 +287,7 @@ metadata:
|
|||
### Service meta
|
||||
|
||||
A service registered in Consul from Kubernetes sets the `external-source` key to
|
||||
`kubernetes`. This can be used from the APLI, CLI and UI to filter
|
||||
`kubernetes`. This can be used from the API, CLI and UI to filter
|
||||
service instances that are set in k8s. The Consul UI displays a Kubernetes icon next to all externally
|
||||
registered services from Kubernetes.
|
||||
|
||||
|
|
@ -422,7 +422,7 @@ configuration.
|
|||
|
||||
**If a conflicting service is found**: the service is not synced. This
|
||||
does not match the Kubernetes to Consul behavior, but given the current
|
||||
implementation we must do this because Kubernetes cannott mix both CNAME and
|
||||
implementation we must do this because Kubernetes cannot mix both CNAME and
|
||||
Endpoint-based services.
|
||||
|
||||
### Kubernetes service labels and annotations
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ to update to the new version. Before you upgrade to a new version:
|
|||
|
||||
</CodeBlockConfig>
|
||||
|
||||
2. Determine the version of your exisiting Helm installation. In this example, version `0.39.0` (from `consul-k8s:0.39.0`) is being used.
|
||||
2. Determine the version of your existing Helm installation. In this example, version `0.39.0` (from `consul-k8s:0.39.0`) is being used.
|
||||
|
||||
```shell-session
|
||||
$ helm list --filter consul --namespace consul
|
||||
|
|
@ -174,7 +174,7 @@ that can be used.
|
|||
1. Take specific note if `consul-server, StatefulSet` is listed, as it means your Consul server statefulset will be redeployed.
|
||||
|
||||
If your Consul server statefulset needs to be redeployed, follow the same pattern for upgrades as
|
||||
on other platforms by redploying servers one by one. Refer tp [Upgrading Consul](/consul/docs/upgrading) for more information.
|
||||
on other platforms by redeploying servers one by one. Refer tp [Upgrading Consul](/consul/docs/upgrading) for more information.
|
||||
|
||||
If neither the server statefulset is not being redeployed,
|
||||
then you can continue with the Helm upgrade without any specific sequence to follow.
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ When running a Consul agent with CTS in production, consider that CTS uses [bloc
|
|||
|
||||
To avoid reaching the limit prematurely, we recommend using HTTP/2 (requires HTTPS) to communicate between CTS and the Consul agent. When using HTTP/2, CTS establishes a single connection and reuses it for all communication. Refer to the [Consul Configuration section](/consul/docs/nia/configuration#consul) for details.
|
||||
|
||||
Alternatively, you can configure the [`limits.http_max_conns_per_client`](/consul/docs/agent/config/config-files#http_max_conns_per_client) option to set a maximimum number of connections to meet your needs.
|
||||
Alternatively, you can configure the [`limits.http_max_conns_per_client`](/consul/docs/agent/config/config-files#http_max_conns_per_client) option to set a maximum number of connections to meet your needs.
|
||||
|
||||
### Register services
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ description: >-
|
|||
# Run Consul-Terraform-Sync with high availability
|
||||
|
||||
<EnterpriseAlert>
|
||||
An enterpise license is only required for enterprise distributions of Consul-Terraform-Sync (CTS).
|
||||
An enterprise license is only required for enterprise distributions of Consul-Terraform-Sync (CTS).
|
||||
</EnterpriseAlert>
|
||||
|
||||
This topic describes how to run Consul-Terraform-Sync (CTS) configured for high availability. High availability is an enterprise capability that ensures that all changes to Consul that occur during a failover transition are processed and that CTS continues to operate as expected.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ description: >-
|
|||
|
||||
- **Simplified Service Mesh Deployments with Consul Dataplane:** Consul client agents are no longer deployed by default, and Consul service mesh no longer uses Consul clients to operate. A new component `consul-dataplane` is now injected as a sidecar-proxy instead of plain Envoy. `consul-dataplane` manages the Envoy proxy process and proxies xDS requests from Envoy to Consul servers. All service mesh consul-k8s components are configured to talk directly to Consul servers.
|
||||
|
||||
- **Cluster Peering GA with Peering over Mesh Gateways:** This version promotes Cluster Peering, a new model to federate Consul clusters for both service mesh and traditional service discovery, to General Availability. Cluster peering allows for service interconnectivity with looser coupling than the existing WAN federation. Cluster Peering on Consul K8s now enables [Cluster Peering with Control Plane traffic routed via Mesh Gateways](/consul/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways) by default instead of provisioning load balancers using the `servers.exposeServers` stanza. In addtion, failover for service to service traffic over Cluster Peering can be configured through the `failover.targets` field in the [ServiceResolver](/consul/docs/connect/config-entries/service-resolver#targets) CRD.
|
||||
- **Cluster Peering GA with Peering over Mesh Gateways:** This version promotes Cluster Peering, a new model to federate Consul clusters for both service mesh and traditional service discovery, to General Availability. Cluster peering allows for service interconnectivity with looser coupling than the existing WAN federation. Cluster Peering on Consul K8s now enables [Cluster Peering with Control Plane traffic routed via Mesh Gateways](/consul/docs/connect/gateways/mesh-gateway/peering-via-mesh-gateways) by default instead of provisioning load balancers using the `servers.exposeServers` stanza. In addition, failover for service to service traffic over Cluster Peering can be configured through the `failover.targets` field in the [ServiceResolver](/consul/docs/connect/config-entries/service-resolver#targets) CRD.
|
||||
|
||||
- **Consul API Gateway 0.5.0 Support:** Support to run Consul API Gateway without clients and allow Consul API Gateway to directly connect to Consul servers.
|
||||
|
||||
|
|
@ -22,7 +22,7 @@ description: >-
|
|||
- `externalServers.hosts` no longer supports [cloud auto-join](/consul/docs/install/cloud-auto-join) strings directly. Instead, include an [`exec=`](https://github.com/hashicorp/go-netaddrs#command-line-tool-usage) string in the `externalServers.hosts` list to invoke the `discover` CLI. For example, the following string invokes the `discover` CLI with a cloud auto-join string: `exec=discover -q addrs provider=aws region=us-west-2 tag_key=consul-server tag_value=true`. The `discover` CLI is included in the official `hashicorp/consul-dataplane` images by default.
|
||||
- `sync-catalog` now communicates directly to Consul servers. When communicating to servers outside of Kubernetes, use the `externalServers.hosts` stanza as described in [Join External Servers to Consul on Kubernetes](/consul/docs/k8s/deployment-configurations/servers-outside-kubernetes).
|
||||
- Consul snapshot agent runs as a sidecar to Consul servers. <EnterpriseAlert inline />
|
||||
- `client.snapshotAgent` values are moved to `server.snapshotAgent`, with the exception of the following values: `client.snaphostAgent.replicas`, `client.snaphostAgent.serviceAccount`
|
||||
- `client.snapshotAgent` values are moved to `server.snapshotAgent`, with the exception of the following values: `client.snapshotAgent.replicas`, `client.snapshotAgent.serviceAccount`
|
||||
- `global.secretsBackend.vault.consulSnapshotAgentRole` value is now removed. You should now use the `global.secretsBackend.vault.consulServerRole` for access to any Vault secrets.
|
||||
- Support simplified default deployment values to allow for easier quick starts and testing:
|
||||
* Set `server.replicas` to `1`. Formerly, this defaulted to `3`.
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Refer to [Service-to-service troubleshooting overview](/consul/docs/troubleshoot
|
|||
|
||||
## What's Changed
|
||||
|
||||
- ACL errors have now been ehanced to return descriptive errors when the specified resource cannot be found. Other ACL request errors provide more information about when a resource is missing. In addition, errors are now gracefully thrown when interacting with the ACL system before the ACL system been bootstrapped.
|
||||
- ACL errors have now been enhanced to return descriptive errors when the specified resource cannot be found. Other ACL request errors provide more information about when a resource is missing. In addition, errors are now gracefully thrown when interacting with the ACL system before the ACL system been bootstrapped.
|
||||
- The Delete Token/Policy/AuthMethod/Role/BindingRule endpoints now return 404 when the resource cannot be found. The new error format is as follows:
|
||||
|
||||
```log hideClipboard
|
||||
|
|
@ -74,14 +74,14 @@ The following issues are known to exist in the v1.15.x releases:
|
|||
due to a problem with leaf certificate rotation.
|
||||
This is resolved in Consul v1.15.2.
|
||||
|
||||
- For v1.15.0, Consul is reporting newer releases of Envoy (for example, v1.25.1) as not supported, even though these versions are listed as valid in the [Envoy compatilibity matrix](/consul/docs/connect/proxies/envoy#envoy-and-consul-client-agent). The following error would result for newer versions of Envoy:
|
||||
- For v1.15.0, Consul is reporting newer releases of Envoy (for example, v1.25.1) as not supported, even though these versions are listed as valid in the [Envoy compatibility matrix](/consul/docs/connect/proxies/envoy#envoy-and-consul-client-agent). The following error would result for newer versions of Envoy:
|
||||
|
||||
```log hideClipboard
|
||||
Envoy version 1.25.1 is not supported. If there is a reason you need to use this version of envoy use the ignore-envoy-compatibility flag. Using an unsupported version of Envoy is not recommended and your experience may vary.
|
||||
```
|
||||
|
||||
To workaround this issue on Consul v1.15.0, launch sidecar proxies
|
||||
with the `ignore-envoy-compatiblity` flag:
|
||||
with the `ignore-envoy-compatibility` flag:
|
||||
|
||||
```shell-session
|
||||
$ consul connect envoy --ignore-envoy-compatibility
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ description: ->
|
|||
This topic provides configuration reference information for health checks. For information about the different kinds of health checks and guidance on defining them, refer to [Define Health Checks].
|
||||
|
||||
## Introduction
|
||||
Health checks perform several safety functions, such as allowing a web balancer to gracefully remove failing nodes and allowing a database to replace a failed secondary. You can configure health checks to monitor the health of the entire node. Refer to [Define Health Checks](/consul/docs/services/usage/checks) for information about how to define the differnet types of health checks available in Consul.
|
||||
Health checks perform several safety functions, such as allowing a web balancer to gracefully remove failing nodes and allowing a database to replace a failed secondary. You can configure health checks to monitor the health of the entire node. Refer to [Define Health Checks](/consul/docs/services/usage/checks) for information about how to define the different types of health checks available in Consul.
|
||||
|
||||
## Check block
|
||||
Specify health check options in the `check` block. To register two or more heath checks in the same configuration, use the [`checks` block](#checks-block). The following table describes the configuration options contained in the `check` block.
|
||||
|
|
@ -19,7 +19,7 @@ Specify health check options in the `check` block. To register two or more heath
|
|||
| --- | --- | --- |
|
||||
| `name` | Required string value that specifies the name of the check. Default is `service:<service-id>`. If multiple service checks are registered, the autogenerated default is appended with colon and incrementing number starting with `1`. | <li>Script </li> <li>HTTP </li> <li>TCP </li> <li>UDP </li> <li>OSService </li> <li>TTL </li> <li>Docker </li> <li>gRPC </li> <li>H2ping </li> <li>Alias </li> |
|
||||
| `id` | A unique string value that specifies an ID for the check. Default to the `name` value. If `name` values conflict, specify a unique ID to avoid overwriting existing checks with same ID on the same node. Consul auto-generates an ID if the check is defined in a service definition file. | <li>Script </li> <li>HTTP </li> <li>TCP </li> <li>UDP </li> <li>OSService </li> <li>TTL </li> <li>Docker </li> <li>gRPC </li> <li>H2ping </li> <li>Alias </li> |
|
||||
| `notes` | String value that provides a human-readabiole description of the check. The contents are not visible to Consul. | <li>Script </li> <li>HTTP </li> <li>TCP </li> <li>UDP </li> <li>OSService </li> <li>TTL </li> <li>Docker </li> <li>gRPC </li> <li>H2ping </li> <li>Alias </li> |
|
||||
| `notes` | String value that provides a human-readable description of the check. The contents are not visible to Consul. | <li>Script </li> <li>HTTP </li> <li>TCP </li> <li>UDP </li> <li>OSService </li> <li>TTL </li> <li>Docker </li> <li>gRPC </li> <li>H2ping </li> <li>Alias </li> |
|
||||
| `interval` | Required string value that specifies how frequently to run the check. The `interval` parameter is required for supported check types. The value is parsed by the golang [time package formatting specification](https://golang.org/pkg/time/#ParseDuration). | <li>Script </li> <li>HTTP </li> <li>TCP </li> <li>UDP </li> <li>OSService </li> <li>Docker </li> <li>gRPC </li> <li>H2ping</li> |
|
||||
| `timeout` | String value that specifies how long unsuccessful requests take to end with a timeout. The `timeout` is optional for the supported check types and has the following defaults: <li> Script: `30s` </li> <li> HTTP: `10s` </li><li> TCP: `10s` </li><li> UDP: `10s` </li><li> gRPC: `10s` </li><li> H2ping: `10s` </li> | <li>Script </li> <li>HTTP </li> <li>TCP </li> <li>UDP </li> <li>gRPC </li> <li>H2ping </li> |
|
||||
| `status` | Optional string value that specifies the initial status of the health check. You can specify the following values: <li>`critical` (default)</li><li>`warning`</li><li>`passing`</li> | <li>Script </li> <li>HTTP </li> <li>TCP </li> <li>UDP </li> <li>OSService </li> <li>TTL </li> <li>Docker </li> <li>gRPC </li> <li>H2ping </li> <li>Alias </li> |
|
||||
|
|
@ -39,7 +39,7 @@ Specify health check options in the `check` block. To register two or more heath
|
|||
| `tls_skip_verify` | Boolean value that disbles TLS for HTTP checks when set to `true`. Default is `false`. | <li>HTTP</li> |
|
||||
| `method` | String value that specifies the request method to send during HTTP checks. Default is `GET`. | <li>HTTP</li> |
|
||||
| `header` | Object that specifies header fields to send in HTTP check requests. Each header specified in `header` object contains a list of string values. | <li>HTTP</li> |
|
||||
| `body` | String value that contains JSON attributes to send in HTTP check requests. You must escap the quotation marks around the keys and values for each attribute. | <li>HTTP</li> |
|
||||
| `body` | String value that contains JSON attributes to send in HTTP check requests. You must escape the quotation marks around the keys and values for each attribute. | <li>HTTP</li> |
|
||||
| `disable_redirects` | Boolean value that prevents HTTP checks from following redirects if set to `true`. Default is `false`. | <li>HTTP</li> |
|
||||
| `os_service` | String value that specifies the name of the name of a service to check during an OSService check. | <li>OSService</li> |
|
||||
| `service_id` | String value that specifies the ID of a service instance to associate with an OSService check. That service instance must be on the same node as the check. If not specified, the check verifies the health of the node. | <li>OSService</li> |
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ The DNS has several default configurations, but you can customize how the server
|
|||
### DNS versus native app integration
|
||||
You can use DNS to reach services registered with Consul or modify your application to natively consume the Consul service discovery HTTP APIs.
|
||||
|
||||
We recommend using the DNS because it is less invasive. You do not have to modify your application with Consul to retrieve the service’s connection information. Instead, you can use a DNS fully qualified domain (FQDN) that conforms to Consul's lookup format to retreive the relevant information.
|
||||
We recommend using the DNS because it is less invasive. You do not have to modify your application with Consul to retrieve the service’s connection information. Instead, you can use a DNS fully qualified domain (FQDN) that conforms to Consul's lookup format to retrieve the relevant information.
|
||||
|
||||
Refer to [ Native App Integration](/consul/docs/connect/native) and its [Go package](/consul/docs/connect/native/go) for additional information.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ description: ->
|
|||
This topic describes how to query the Consul DNS to look up nodes and services registered with Consul. Refer to [Enable Dynamic DNS Queries](/consul/docs/services/discovery/dns-dynamic-lookups) for information about using prepared queries.
|
||||
|
||||
## Introduction
|
||||
Node lookups and service lookups are the fundamental types of queries you can perform using the Consul DNS. Node lookups interrogate the catalog for named Consul agents. Service lookups interrogate the catalog for services registered with Consul. Refer to [DNS Usage Overivew](/consul/docs/services/discovery/dns-overview) for additional background information.
|
||||
Node lookups and service lookups are the fundamental types of queries you can perform using the Consul DNS. Node lookups interrogate the catalog for named Consul agents. Service lookups interrogate the catalog for services registered with Consul. Refer to [DNS Usage Overview](/consul/docs/services/discovery/dns-overview) for additional background information.
|
||||
|
||||
## Requirements
|
||||
All versions of Consul support DNS lookup features.
|
||||
|
|
@ -388,4 +388,4 @@ This endpoint finds services within the same datacenter and does not support tag
|
|||
|
||||
### UDP-based DNS queries
|
||||
|
||||
When the DNS query is performed using UDP, Consul truncateß the results without setting the truncate bit. This prevents a redundant lookup over TCP that generates additional load. If the lookup is done over TCP, the results are not truncated.
|
||||
When the DNS query is performed using UDP, Consul truncates the results without setting the truncate bit. This prevents a redundant lookup over TCP that generates additional load. If the lookup is done over TCP, the results are not truncated.
|
||||
|
|
|
|||
|
|
@ -44,6 +44,6 @@ Refer to [`connectInject`](/consul/docs/k8s/connect#installation-and-configurati
|
|||
|
||||
### Multiple services
|
||||
|
||||
You can define common characteristics for services in your mesh, such as the admin partition, namespace, or upstreams, by creating and applying a `service-defaults` configuration entry. You can also define override configurations for specific upstreams or service instances. To use `service-defaults` configuraiton entries, you must enable Consul service mesh in your network.
|
||||
You can define common characteristics for services in your mesh, such as the admin partition, namespace, or upstreams, by creating and applying a `service-defaults` configuration entry. You can also define override configurations for specific upstreams or service instances. To use `service-defaults` configuration entries, you must enable Consul service mesh in your network.
|
||||
|
||||
Refer to [Define Service Defaults](/consul/docs/services/usage/define-services#define-service-defaults) for additional information.
|
||||
|
|
@ -32,7 +32,7 @@ If ACLs are enabled, resources in your network must present a token with `servic
|
|||
|
||||
You must also present a token with `service:write` access to create, update, or delete a service defaults configuration entry.
|
||||
|
||||
Service configurations must also contain and present an ACL token to perform anti-entropy syncs and deregistration operations. Refer to [Modify anti-entropy synchronozation](#modify-anti-entropy-synchronization) for additional information.
|
||||
Service configurations must also contain and present an ACL token to perform anti-entropy syncs and deregistration operations. Refer to [Modify anti-entropy synchronization](#modify-anti-entropy-synchronization) for additional information.
|
||||
|
||||
On Consul Enterprise, you can register services with specific namespaces if the services' ACL tokens are scoped to the namespace. Services registered with a service definition do not inherit the namespace associated with the ACL token specified in the `token` field. The `namespace` and the `token` parameters must be included in the service definition for the service to be registered to the namespace that the ACL token is scoped to.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue