Integrating Consul with Kubernetes

Transcript

Hi, I'm Jake Lundberg with the solutions engineering group at HashiCorp. I'm here to talk to you today about integrating Consul with Kubernetes. For those of you who have been paying attention to the application environment lately, Kubernetes is a wildly popular application scheduler.

Holding true to HashiCorp's ethos of workflows, not technology, it should be no surprise that Consul also integrates very easily with Kubernetes. Consul allows for bridging Kubernetes and non-Kubernetes resources or—if people are running Kubernetes-only applications—for using Consul as a [service mesh]((https://www.hashicorp.com/resources/what-is-a-service-mesh) within Kubernetes.

Let's discuss some of the various components that are created when integrating Consul with Kubernetes. The easiest way of integrating Consul with Kubernetes is to use a helm chart. The chart allows for very granular configurations of server and clients, as well as mesh proxies and other objects like certificates and ConfigMaps.

Design decisions when deploying servers

Some of the design decisions that you should think about when deploying Consul and Kubernetes include whether to run the server inside or outside of Kubernetes.

Much of this decision comes down to the type of services that you'd be running, so if you're running on Kubernetes servers and integrating them with Kubernetes-based services, it's probably easiest to install the server nodes outside of Kubernetes. If you're only going to be running services inside of Kubernetes, it makes sense then—of course—to run those servers inside of your Kubernetes environment.

Running servers inside Kubernetes

There are a few objects that are created when running servers inside of Kubernetes. The first of which is a StatefulSet which configures either three or five Consul servers inside of your Kubernetes run nodes.

The second of which is a ConfigMap, which is used to configure the actual servers themselves—and lastly, is a service so you can allow for discovering and accessing these servers.

When running servers inside of Kubernetes, you're going to get a few Kubernetes resources such as DaemonSet in which each client runs on one of the worker nodes inside of Kubernetes. You'll also get a ConfigMap, which does the configurations for any of the client configurations inside Consul.

Lastly, we do not install a service for the client nodes. We expose a hostPort which allows localhost communication following best practices for communications with those client nodes.

One nice thing about the Kubernetes Consul integration is that Consul allows for bi-directional service syncs with the Kubernetes services. Your applications can choose whether to use Kubernetes-native service names or Consul service names.

One benefit of this is the capability of integrating non-Kubernetes services with the Consul services that are running inside of your Kubernetes cluster. Service names can be looked up solely using Consul service names—if that's the best deployment pattern for your applications.

Service mesh sidecars are configured using annotations within your Kubernetes configuration files. This uses mutating admission webhooks to inject Consul sidecars into your pods automatically and allows communication, again, both within your Kubernetes clusters, as well as spanning outside of your Kubernetes clusters as well.