Nomad and Consul Connect resource overhead for low-traffic workloads
0 reputation · 13 Jul 2021, 07:30 UTC
When deploying low-traffic workloads on HashiCorp Nomad, the choice between native service discovery and Consul Connect significantly impacts infrastructure costs. Using the connect block in Nomad injects an Envoy sidecar proxy into every allocation to facilitate mTLS and advanced service-to-service communication.
In small-scale environments, the cumulative CPU and memory consumption of these sidecar proxies can represent a disproportionate percentage of the total cluster resources used. While Nomad supports native service discovery via the provider = "nomad" configuration to eliminate the Consul dependency, this removes the automatic mTLS that the mesh provides between services.
The challenge lies in determining whether the security baseline and traffic management capabilities of Consul Connect justify the persistent resource overhead of the Envoy sidecars when traffic volume is minimal.
- What is the typical baseline resource overhead for an Envoy sidecar in a Nomad task allocation with minimal resource settings?
- What specific security features are lost when switching from Consul Connect to native Nomad service discovery?
- Can the sidecar resource limits be tuned granularly enough to minimize cost without risking proxy stability under load?