mirror of https://github.com/status-im/consul.git
docs: clarify that clients and servers need to talk over LAN if outside k8s (#7156)
This commit is contained in:
parent
1c1ce32ac9
commit
7b549b0b5e
|
@ -29,23 +29,19 @@ started using the [official Helm chart](/docs/platform/k8s/helm.html):
|
|||
$ consul agent -retry-join 'provider=k8s label_selector="app=consul,component=server"'
|
||||
```
|
||||
|
||||
By default, Consul will join the default Gossip port. Pods may set an
|
||||
By default, Consul will join the default gossip port. Pods may set an
|
||||
annotation `consul.hashicorp.com/auto-join-port` to an integer value or
|
||||
a named port to specify the port for the auto-join to return. This enables
|
||||
different pods to have different exposed ports.
|
||||
|
||||
## Networking
|
||||
|
||||
Consul typically requires a fully connected network. Therefore,
|
||||
Consul typically requires a fully connected network.
|
||||
Because the Consul Helm chart currently doesn't allow exposing servers' gossip ports via a `hostPort`,
|
||||
nodes outside of Kubernetes joining a cluster running within Kubernetes must be able to communicate
|
||||
to pod IPs or Kubernetes node IPs via the network.
|
||||
to pod IPs via the network. Note that the auto-join provider discussed above will use pod IPs by default.
|
||||
|
||||
-> **Consul Enterprise customers** may use
|
||||
[network segments](/docs/enterprise/network-segments/index.html) to
|
||||
enable non-fully-connected topologies. However, out-of-cluster nodes must still
|
||||
be able to communicate with the server pod or host IP addresses.
|
||||
|
||||
The auto-join provider discussed above will use pod IPs by default. The
|
||||
`host_network=true` setting may be set to use host IPs, however all the ports
|
||||
Consul requires must be exposed via a `hostPort`. If no ports are exposed via
|
||||
`hostPort`, the pod will not be discovered.
|
||||
|
|
|
@ -19,8 +19,8 @@ so that each component is opt-in. This allows us to _only_ setup the client
|
|||
agents. We then opt-in to the client agents by setting `client.enabled` to
|
||||
`true`.
|
||||
|
||||
Next, `client.exposeGossipPorts` can be set to true or false depending on if
|
||||
you want the clients to be exposed on the Kubernetes node IPs (`true`) or
|
||||
Next, `client.exposeGossipPorts` can be set to `true` or `false` depending on if
|
||||
you want the clients to be exposed on the Kubernetes internal node IPs (`true`) or
|
||||
their pod IPs (`false`).
|
||||
|
||||
Finally, `client.join` is set to an array of valid
|
||||
|
@ -46,7 +46,7 @@ client:
|
|||
|
||||
-> **Networking:** Note that for the Kubernetes nodes to join an existing
|
||||
cluster, the nodes (and specifically the agent pods) must be able to connect
|
||||
to all other server and client agents inside and _outside_ of Kubernetes.
|
||||
to all other server and client agents inside and _outside_ of Kubernetes over [LAN](https://www.consul.io/docs/glossary.html#lan-gossip).
|
||||
If this isn't possible, consider running a separate Consul cluster inside Kubernetes
|
||||
and federating it with your cluster outside Kubernetes.
|
||||
You may also consider adopting Consul Enterprise for
|
||||
|
|
Loading…
Reference in New Issue