Explore other options for running the consul agent in Kubernetes
Currently we run a standard client configuration of consul in our Kubernetes clusters. We are seeing some awkward behavior related to service discover for our rails applications: gitlab-org/gitlab#271575 (closed)
Utilize this issue to explore other methods of running Consul. There are two primary items identified, though more may be available:
- Instead of using a Service endpoint, could we switch to using the
hostNetwork
- Determine if we can leverage consul's ability to inject its knowledge into Kubernetes, which should provide us with the ability to leverage kube-dns for lookups instead of consul
- sidecar?
- removing the client from Kubernetes and using the consul cluster itself?
- ...
All options need to be vetted and explored to determine security implications, configuration management and rotation into this service without an outage, etc.