Consul
Join External Services to Consul on Kubernetes
Services running on non-Kubernetes nodes can join a Consul cluster running within Kubernetes.
Auto-join
The recommended way to join a cluster running within Kubernetes is to use the "k8s" cloud auto-join provider.
The auto-join provider dynamically discovers IP addresses to join using
the Kubernetes API. It authenticates with Kubernetes using a standard
kubeconfig
file. Auto-join works with all major hosted Kubernetes offerings
as well as self-hosted installations. The token in the kubeconfig
file
needs to have permissions to list pods in the namespace where Consul servers
are deployed.
The auto-join string below joins a Consul server agent to a cluster using the official Helm chart:
$ consul agent -retry-join 'provider=k8s label_selector="app=consul,component=server"'
Note: This auto-join command only connects on the default gossip port 8301, whether you are joining on the pod network or via host ports. A Consul server that is already a member of the datacenter should be listening on this port for the external service to connect through auto-join.
Auto-join on the Pod network
In the default Consul Helm chart installation, Consul servers are routable through their pod IPs for server RPCs. As a result, any external agents joining the Consul cluster running on Kubernetes need to be able to connect to those pod IPs.
In many hosted Kubernetes environments, you need to explicitly configure your hosting provider to ensure that pod IPs are routable from external VMs. For more information, refer to Azure AKS CNI, AWS EKS CNI and GKE VPC-native clusters.
To join external agents with Consul on Kubernetes deployments installed with default values through the official Helm chart:
Make sure the pod IPs of the servers in Kubernetes are routable from the VM and that the VM can access port 8301 (for gossip) and port 8300 (for server RPC) on those pod IPs.
Make sure that the server pods running in Kubernetes can route to the VM's advertise IP on its gossip port (default 8301).
Make sure you have the
kubeconfig
file for the Kubernetes cluster in$HOME/.kube/config
on the external VM.On the external VM, run:
consul agent \ -advertise="$ADVERTISE_IP" \ -retry-join='provider=k8s label_selector="app=consul,component=server"' \ -bind=0.0.0.0 \ -hcl='leave_on_terminate = true' \ -hcl='ports { grpc = 8502 }' \ -config-dir=$CONFIG_DIR \ -datacenter=$DATACENTER \ -data-dir=$DATA_DIR \
Run
consul members
to check if the join was successful./ $ consul members Node Address Status Type Build Protocol DC Segment consul-consul-server-0 10.138.0.43:9301 alive server 1.9.1 2 dc1 <all> external-agent 10.138.0.38:8301 alive client 1.9.0 2 dc1 <default> gke-external-agent-default-pool-32d15192-grs4 10.138.0.43:8301 alive client 1.9.1 2 dc1 <default> gke-external-agent-default-pool-32d15192-otge 10.138.0.44:8301 alive client 1.9.1 2 dc1 <default> gke-external-agent-default-pool-32d15192-vo7k 10.138.0.42:8301 alive client 1.9.1 2 dc1 <default>
Auto-join through host ports
If your external VMs cannot connect to Kubernetes pod IPs but they can connect to the internal host IPs of the nodes in the Kubernetes cluster, you can join the two by exposing ports on the host IP instead.
Install the official Helm chart with the following values:
client: exposeGossipPorts: true # exposes client gossip ports as hostPorts server: exposeGossipAndRPCPorts: true # exposes the server gossip and RPC ports as hostPorts ports: # Configures the server gossip port serflan: # Note that this needs to be different than 8301, to avoid conflicting with the client gossip hostPort port: 9301
This installation exposes the client gossip ports, the server gossip ports and the server RPC port at
hostIP:hostPort
. Note thathostIP
is the internal IP of the VM that the client/server pods are deployed on.Make sure the IPs of the Kubernetes nodes are routable from the VM and that the VM can access ports 8301 and 9301 (for gossip) and port 8300 (for server RPC) on those node IPs.
Make sure the server pods running in Kubernetes can route to the VM's advertise IP on its gossip port (default 8301).
Make sure you have the
kubeconfig
file for the Kubernetes cluster in$HOME/.kube/config
on the external VM.On the external VM, run:
consul agent \ -advertise="$ADVERTISE_IP" \ -retry-join='provider=k8s host_network=true label_selector="app=consul,component=server"' -bind=0.0.0.0 \ -hcl='leave_on_terminate = true' \ -hcl='ports { grpc = 8502 }' \ -config-dir=$CONFIG_DIR \ -datacenter=$DATACENTER \ -data-dir=$DATA_DIR \
Note the addition of
host_network=true
in the retry-join argument.Run
consul members
to check if the join was successful./ $ consul members Node Address Status Type Build Protocol DC Segment consul-consul-server-0 10.138.0.43:9301 alive server 1.9.1 2 dc1 <all> external-agent 10.138.0.38:8301 alive client 1.9.0 2 dc1 <default> gke-external-agent-default-pool-32d15192-grs4 10.138.0.43:8301 alive client 1.9.1 2 dc1 <default> gke-external-agent-default-pool-32d15192-otge 10.138.0.44:8301 alive client 1.9.1 2 dc1 <default> gke-external-agent-default-pool-32d15192-vo7k 10.138.0.42:8301 alive client 1.9.1 2 dc1 <default>
Manual join
If you are unable to use auto-join, try following the instructions in
either of the auto-join sections, but instead of using a provider
key in the
-retry-join
flag, pass the address of at least one Consul server. Example: -retry-join=$CONSUL_SERVER_IP:$SERVER_SERFLAN_PORT
.
A kubeconfig
file is not required when using manual join.
Instead of hardcoding an IP address, we recommend you set up a DNS entry that resolves to the pod IPs or host IPs that the Consul server pods are running on.