status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

docs: clarify that clients and servers need to talk over LAN if outside k8s (#7156)

This commit is contained in:
Iryna Shustava 2020-01-29 19:09:38 -08:00 committed by GitHub
parent 1c1ce32ac9
commit 7b549b0b5e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 7 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
website/source/docs/platform/k8s/clients-outside-kubernetes.html.md
View File

@ -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"' $ 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 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 a named port to specify the port for the auto-join to return. This enables
different pods to have different exposed ports. different pods to have different exposed ports.
## Networking ## 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 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 -> **Consul Enterprise customers** may use
[network segments](/docs/enterprise/network-segments/index.html) to [network segments](/docs/enterprise/network-segments/index.html) to
enable non-fully-connected topologies. However, out-of-cluster nodes must still enable non-fully-connected topologies. However, out-of-cluster nodes must still
be able to communicate with the server pod or host IP addresses. 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.

6
website/source/docs/platform/k8s/servers-outside-kubernetes.html.md
View File

@ -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 agents. We then opt-in to the client agents by setting `client.enabled` to
`true`. `true`.
Next, `client.exposeGossipPorts` can be set to true or false depending on if 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 you want the clients to be exposed on the Kubernetes internal node IPs (`true`) or
their pod IPs (`false`). their pod IPs (`false`).
Finally, `client.join` is set to an array of valid 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 -> **Networking:** Note that for the Kubernetes nodes to join an existing
cluster, the nodes (and specifically the agent pods) must be able to connect 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 If this isn't possible, consider running a separate Consul cluster inside Kubernetes
and federating it with your cluster outside Kubernetes. and federating it with your cluster outside Kubernetes.
You may also consider adopting Consul Enterprise for You may also consider adopting Consul Enterprise for