Consul on Kubernetes

Preparing your Kubernetes environment to successfully deploy and run Consul is an important first step in your production deployment process. This solution will help you prepare your AWS Elastic Kubernetes Service (EKS). Since Consul servers are responsible for maintaining the datacenter state, server sizing is critical for overall performance, efficiency, and health of the Consul datacenter.

There are many possible configurations for running Consul on Kubernetes.

1. Consul servers deployed outside of Kubernetes and clients (catalog sync/consul-dataplane) inside kubernetes (this is the recommended pattern).
2. Consul servers (control plane) and clients (catalog sync/consul-dataplane) can be entirely within Kubernetes (not recommended).

Kubernetes deployment architecture

As a pre-requisite, ensure consul servers are up and running on VM as per recommendation above.

The below values.yaml file shows how to configure the Helm chart to install Consul so that it joins that existing Consul server cluster.

global:
  enabled: false
 
externalServers:
  enabled: true
  hosts: [<consul server DNS, IP or exec= string>]
  k8sAuthMethodHost: 'https://kubernetes.example.com:443'

Service discovery with Consul on Kubernetes requires Catalog Sync, refer to the operating guide for detailed implementation of Catalog Sync. Here is the architecture diagram for this use-case.

For service mesh use-case, with the introduction of Consul Dataplane, Consul installation on Kubernetes is simplified by removing the Consul Client agents. This requires the Helm installation and rest of the consul-k8s components installed on Kubernetes to talk to Consul Servers directly on various ports. Before starting the installation, ensure that the Consul Servers are configured to have the gRPC port enabled 8502/tcp using the ports.grpc = 8502 configuration option. Here is the architecture diagram for this use-case.

Component compatibility