From 7b549b0b5eede0884a58b4fdf95d3a49df26a570 Mon Sep 17 00:00:00 2001 From: Iryna Shustava Date: Wed, 29 Jan 2020 19:09:38 -0800 Subject: [PATCH] docs: clarify that clients and servers need to talk over LAN if outside k8s (#7156) --- .../platform/k8s/clients-outside-kubernetes.html.md | 12 ++++-------- .../platform/k8s/servers-outside-kubernetes.html.md | 6 +++--- 2 files changed, 7 insertions(+), 11 deletions(-) diff --git a/website/source/docs/platform/k8s/clients-outside-kubernetes.html.md b/website/source/docs/platform/k8s/clients-outside-kubernetes.html.md index afcde6b7dd..3ef6366b99 100644 --- a/website/source/docs/platform/k8s/clients-outside-kubernetes.html.md +++ b/website/source/docs/platform/k8s/clients-outside-kubernetes.html.md @@ -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. diff --git a/website/source/docs/platform/k8s/servers-outside-kubernetes.html.md b/website/source/docs/platform/k8s/servers-outside-kubernetes.html.md index 0608bfd9ed..9531b95c30 100644 --- a/website/source/docs/platform/k8s/servers-outside-kubernetes.html.md +++ b/website/source/docs/platform/k8s/servers-outside-kubernetes.html.md @@ -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