<p>We run our stack on the Google Cloud Platform (hosted Kubernetes, GKE) and have a Consul cluster running outside of K8s (regular GCE instances).</p>

<p>Several services running in K8s use Consul, mostly for it's CP K/V Store and advanced locking, not so much for service discovery so far.</p>

<p>We recently ran into <strong>some issues</strong> with using the <strong>Consul service discovery from within K8s</strong>. Right now our <strong>apps</strong> talk directly to the Consul Servers to <strong>register and unregister services</strong> they provide.</p>

<p>This is not recommended best-practice, usually Consul clients (i.e. apps using Consul) should talk to the <strong>local</strong> Consul agent. In our setup there are no local Consul agents.</p>

<p><strong>My Question</strong>: Should we run <em>local</em> Consul agents as <em>sidekick</em> containers in each pod?</p>

<p>IMHO this would be a huge waste of ressources, but it would match the Consul best-practies better.</p>

<p>I tried searching on Google, but all posts about Consul and Kubernetes talk about running Consul in K8s, which is not what I want to do.</p>

<p>As the official Consul Helm chart and the documentation suggests the standard approach is to run a DaemonSet of Consul clients and then use a connect-side-car injector to inject sidecars into your node simply by providing an annotation of the pod spec. This should handle all of the boilerplate and will be inline with best practices.</p>

<ul>
<li>Consul: Connect Sidecar; <a href="https://www.consul.io/docs/platform/k8s/connect.html" rel="nofollow noreferrer">https://www.consul.io/docs/platform/k8s/connect.html</a></li>
</ul>
