mirror of https://github.com/status-im/consul.git
Merge branch 'stable-website' into website/1.9.0-rc1
This commit is contained in:
Mike Morris
commit
54fcfec78c
|
|
@ -59,7 +59,7 @@ This section addresses some frequently asked questions about Consul's architectu
|
|||
|
||||
### How does eventually-consistent gossip relate to the Raft consensus protocol?
|
||||
|
||||
When you query Consul for information about a service, such as via the [DNS interface](https://www.consul.io/docs/agent/dns.html), the agent will always make an internal RPC request to a Consul server that will query the consistent state store. Even though an agent might learn that another agent is down via gossip, that won't be reflected in service discovery until the current Raft leader server perceives that through gossip and updates the catalog using Raft. You can see an example of where these layers are plumbed together here - https://github.com/hashicorp/consul/blob/v1.0.5/agent/consul/leader.go#L559-L602.
|
||||
When you query Consul for information about a service, such as via the [DNS interface](https://www.consul.io/docs/discovery/dns), the agent will always make an internal RPC request to a Consul server that will query the consistent state store. Even though an agent might learn that another agent is down via gossip, that won't be reflected in service discovery until the current Raft leader server perceives that through gossip and updates the catalog using Raft. You can see an example of where these layers are plumbed together here - https://github.com/hashicorp/consul/blob/v1.0.5/agent/consul/leader.go#L559-L602.
|
||||
|
||||
## Why does a blocking query sometimes return with identical results?
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ The `/query` endpoints create, update, destroy, and execute prepared queries.
|
|||
Prepared queries allow you to register a complex service query and then execute
|
||||
it later via its ID or name to get a set of healthy nodes that provide a given
|
||||
service. This is particularly useful in combination with Consul's
|
||||
[DNS Interface](/docs/agent/dns) as it allows for much richer queries than
|
||||
[DNS Interface](/docs/discovery/dns) as it allows for much richer queries than
|
||||
would be possible given the limited entry points exposed by DNS.
|
||||
|
||||
Check the [Geo Failover tutorial](https://learn.hashicorp.com/tutorials/consul/automate-geo-failover) for details and
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ gateway:
|
|||
- The ingress gateway will route traffic based on the host/authority header,
|
||||
expecting a value matching `<service-name>.ingress.*`, or if using namespaces,
|
||||
`<service-name>.ingress.<namespace>.*`. This matches the [Consul DNS
|
||||
ingress subdomain](/docs/agent/dns#ingress-service-lookups).
|
||||
ingress subdomain](/docs/discovery/dns#ingress-service-lookups).
|
||||
|
||||
A wildcard specifier cannot be set on a listener of protocol `tcp`.
|
||||
|
||||
|
|
|
|||
|
|
@ -1452,7 +1452,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
|
|||
When set to true, in a DNS query for a service, the label between the domain
|
||||
and the `service` label will be treated as a namespace name instead of a datacenter.
|
||||
When set to false, the default, the behavior will be the same as non-Enterprise
|
||||
versions and will assume the label is the datacenter. See: [this section](/docs/agent/dns#namespaced-services)
|
||||
versions and will assume the label is the datacenter. See: [this section](/docs/discovery/dns#namespaced-services)
|
||||
for more details.
|
||||
|
||||
- `domain` Equivalent to the [`-domain` command-line flag](#_domain).
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ to a set of backing
|
|||
[services](/docs/agent/config-entries/ingress-gateway#services).
|
||||
|
||||
To enable easier service discovery, a new Consul [DNS
|
||||
subdomain](/docs/agent/dns#ingress-service-lookups) is provided, on
|
||||
subdomain](/docs/discovery/dns#ingress-service-lookups) is provided, on
|
||||
`<service>.ingress.<domain>`.
|
||||
|
||||
For listeners with a
|
||||
|
|
@ -32,7 +32,7 @@ For listeners with a
|
|||
case, the ingress gateway relies on host/authority headers to decide the
|
||||
service that should receive the traffic. The host used to match traffic
|
||||
defaults to the [Consul DNS ingress
|
||||
subdomain](/docs/agent/dns#ingress-service-lookups), but can be changed using
|
||||
subdomain](/docs/discovery/dns#ingress-service-lookups), but can be changed using
|
||||
the [hosts](/docs/agent/config-entries/ingress-gateway#hosts) field.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ Details on the steps are below:
|
|||
|
||||
- **Service discovery** - This is normal service discovery using Consul,
|
||||
a static IP, or any other mechanism. If you're using Consul DNS, the
|
||||
[`<service>.connect`](/docs/agent/dns#connect-capable-service-lookups)
|
||||
[`<service>.connect`](/docs/discovery/dns#connect-capable-service-lookups)
|
||||
syntax to find Connect-capable endpoints for a service. After service
|
||||
discovery, choose one address from the list of **service addresses**.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ URLs](#configuring-dashboard-urls).
|
|||
It is possible to configure the UI to fetch basic metrics from your metrics
|
||||
provider storage to augment the visualization as displayed below.
|
||||
|
||||
|
||||
|
||||
|
||||
Consul has built-in support for overlaying metrics from a
|
||||
[Prometheus](https://prometheus.io) backend. Alternative metrics providers may
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ switch service definitions for registering proxies.
|
|||
If an application requires dynamic dependencies that are only available
|
||||
at runtime, it must [natively integrate](/docs/connect/native)
|
||||
with Connect. After natively integrating, the HTTP API or
|
||||
[DNS interface](/docs/agent/dns#connect-capable-service-lookups)
|
||||
[DNS interface](/docs/discovery/dns#connect-capable-service-lookups)
|
||||
can be used.
|
||||
|
||||
!> Connect proxies do not currently support dynamic upstreams.
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ default managed proxy and starts a listener for that service:
|
|||
|
||||
The listener is started on random port within the configured Connect
|
||||
port range. It can be discovered using the
|
||||
[DNS interface](/docs/agent/dns#connect-capable-service-lookups)
|
||||
[DNS interface](/docs/discovery/dns#connect-capable-service-lookups)
|
||||
or
|
||||
[Catalog API](#).
|
||||
In most cases, service-to-service communication is established by
|
||||
|
|
|
|||
|
|
@ -355,7 +355,7 @@ services {
|
|||
|
||||
## Service and Tag Names with DNS
|
||||
|
||||
Consul exposes service definitions and tags over the [DNS](/docs/agent/dns)
|
||||
Consul exposes service definitions and tags over the [DNS](/docs/discovery/dns)
|
||||
interface. DNS queries have a strict set of allowed characters and a
|
||||
well-defined format that Consul cannot override. While it is possible to
|
||||
register services or tags with names that don't match the conventions, those
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ description: >-
|
|||
# Consul DNS on Kubernetes
|
||||
|
||||
One of the primary query interfaces to Consul is the
|
||||
[DNS interface](/docs/agent/dns). You can configure Consul DNS in
|
||||
[DNS interface](/docs/discovery/dns). You can configure Consul DNS in
|
||||
Kubernetes using a
|
||||
[stub-domain configuration](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#configure-stub-domain-and-upstream-dns-servers)
|
||||
if using KubeDNS or a [proxy configuration](https://coredns.io/plugins/proxy/) if using CoreDNS.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ automatically installed and configured using the
|
|||
Consul catalog enable Kubernetes services to be accessed by any node that
|
||||
is part of the Consul cluster, including other distinct Kubernetes clusters.
|
||||
For non-Kubernetes nodes, they can access services using the standard
|
||||
[Consul DNS](/docs/agent/dns) or HTTP API.
|
||||
[Consul DNS](/docs/discovery/dns) or HTTP API.
|
||||
|
||||
**Why sync Consul services to Kubernetes?** Syncing Consul services to
|
||||
Kubernetes services enables non-Kubernetes services (such as external to
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ $ curl localhost:8500/v1/catalog/nodes
|
|||
[{"Node":"Armons-MacBook-Air","Address":"127.0.0.1","TaggedAddresses":{"lan":"127.0.0.1","wan":"127.0.0.1"},"CreateIndex":4,"ModifyIndex":110}]
|
||||
```
|
||||
|
||||
In addition to the HTTP API, the [DNS interface](/docs/agent/dns) can
|
||||
In addition to the HTTP API, the [DNS interface](/docs/discovery/dns) can
|
||||
be used to query the node. Note that you have to make sure to point your DNS
|
||||
lookups to the Consul agent's DNS server which runs on port 8600 by default.
|
||||
The format of the DNS entries (such as "Armons-MacBook-Air.node.consul") will
|
||||
|
|
|
|||
Loading…
Reference in New Issue