2.0 KiB
| layout | page_title | sidebar_current | description |
|---|---|---|---|
| docs | Consul Servers Outside of Kubernetes - Kubernetes | docs-platform-k8s-run-servers-outside | Running Consul servers outside of Kubernetes |
Consul Servers Outside of Kubernetes
If you have a Consul cluster already running, you can configure your Consul clients inside Kubernetes to join this existing cluster.
The below config.yaml file shows how to configure the Helm chart to install
Consul clients that will join an existing cluster.
The global.enabled value first disables all chart components by default
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 internal node IPs (true) or
their pod IPs (false).
Finally, client.join is set to an array of valid
-retry-join values. In the
example above, a fake cloud auto-join
value is specified. This should be set to resolve to the proper addresses of
your existing Consul cluster.
# config.yaml
global:
enabled: false
client:
enabled: true
# Set this to true to expose the Consul clients using the Kubernetes node
# IPs. If false, the pod IPs must be routable from the external servers.
exposeGossipPorts: true
join:
- "provider=my-cloud config=val ..."
-> 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 over LAN. 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 network segments.