Consul in Kubernetes — Pushing to Production
Consul cluster in Kubernetes, Making it Production Ready
Introduction
HashiCorp Consul is used as K/V store in my Kubernetes clusters. The system architecture looks like below, as described in my previous articles about Traefik as Ingress Controller and highly available Vault cluster.
As the storage back-end, the performance, stability and availability of Consul is very important to for the Traefik cluster and Vault cluster being highly available.
In this article I describe my recent approaches to make the Consul cluster in Kubernetes as production-ready as possible. I have 3 goals:
- In daily operation, Consul shall be stable without leader loss.
- In Consul cluster rolling update, Consul shall not cause disruption to Traefik and Vault.
- In case of whole cluster reboot, Consul/Traefik/Vault shall not have service interruption.
As Consul is so powerful and complex, I will only limit to scenario of single data-center in Kubernetes, used as K/V store. This means I won’t deploy everything about Consul on the cluster, but only the ‘server’ part out of ‘client/server/connect/mesh/catalog’.
