2019-12-19 02:02:26 +00:00
|
|
|
---
|
2020-04-07 18:55:19 +00:00
|
|
|
layout: docs
|
|
|
|
|
page_title: Consul Servers Outside of Kubernetes - Kubernetes
|
2020-04-07 23:56:08 +00:00
|
|
|
sidebar_title: 'Consul Servers Outside Kubernetes'
|
2020-04-07 18:55:19 +00:00
|
|
|
sidebar_current: docs-platform-k8s-run-servers-outside
|
|
|
|
|
description: Running Consul servers outside of Kubernetes
|
2019-12-19 02:02:26 +00:00
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# 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`.
|
|
|
|
|
|
2020-01-30 03:09:38 +00:00
|
|
|
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
|
2019-12-19 02:02:26 +00:00
|
|
|
their pod IPs (`false`).
|
|
|
|
|
|
|
|
|
|
Finally, `client.join` is set to an array of valid
|
|
|
|
|
[`-retry-join` values](/docs/agent/options.html#retry-join). In the
|
|
|
|
|
example above, a fake [cloud auto-join](/docs/agent/cloud-auto-join.html)
|
|
|
|
|
value is specified. This should be set to resolve to the proper addresses of
|
|
|
|
|
your existing Consul cluster.
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
# 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:
|
2020-04-06 20:27:35 +00:00
|
|
|
- 'provider=my-cloud config=val ...'
|
2019-12-19 02:02:26 +00:00
|
|
|
```
|
|
|
|
|
|
|
|
|
|
-> **Networking:** Note that for the Kubernetes nodes to join an existing
|
|
|
|
|
cluster, the nodes (and specifically the agent pods) must be able to connect
|
2020-01-30 03:09:38 +00:00
|
|
|
to all other server and client agents inside and _outside_ of Kubernetes over [LAN](https://www.consul.io/docs/glossary.html#lan-gossip).
|
2019-12-19 02:02:26 +00:00
|
|
|
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](/docs/enterprise/network-segments/index.html).
|
