A team I worked with inherited a 40-node VM fleet, three Kubernetes clusters, and a mandate to "adopt a service mesh." They picked Istio because that's what the conference talks said. Six months later they were still debugging sidecar injection edge cases on the VM workloads — workloads that Istio had no clean story for in the first place. The mesh project got cancelled. The underlying problem — services couldn't find each other reliably and everything talked in plaintext — was still there.
Here's the thing nobody tells you: service discovery and mutual TLS are orthogonal to orchestration. You can do both without a control plane welded to Kubernetes. Consul treats them that way, which is exactly why it fits the "unholy hybrid" environments most of us actually run.
This guide is for engineers who need a working mesh across VMs, bare metal, and maybe some K8s — and want to know what it takes to run Consul Connect for real. By the end you'll be able to bootstrap a TLS-and-ACL-hardened cluster, register services with honest health checks, enable mTLS with sidecars, and write intentions that survive an audit.
:::note[TL;DR]
- Consul Connect gives you service discovery plus mTLS with intentions as the authz layer — no Kubernetes required.
- Harden from day one: gossip encryption, RPC TLS, and ACL bootstrap before you expose the API. "We'll add ACLs later" is a lie you tell yourself.
- Intentions are identity-based allow rules that work cross-platform; firewalls are still your outer perimeter.
- Transparent proxy mode is powerful and will lock you out of SSH if you don't exclude the lifeline ports.
- Snapshot, restore-drill, and watch Raft — uptime is not the same as health. :::
Prerequisites
- Consul 1.16 or newer (check the official docs for the current release; the CLI and config surface described here are stable across recent 1.x).
- Three hosts for servers with reliable clocks and low-latency networking between them.
- Root or sudo on target hosts for transparent proxy mode.
- Optional but recommended: Vault or cert-manager for cert lifecycle, and S3 (or equivalent) for snapshot storage.
Why You Probably Don't Need Istio
The cargo cult is real: "service mesh" has been quietly redefined to mean "Kubernetes-native service mesh." That framing is a vendor convenience, not a technical truth. Istio and Linkerd are excellent — inside a single, well-behaved K8s cluster. The moment you have workloads Istio can't inject into cleanly (legacy VMs, appliances, cron boxes, that one Java app nobody will touch), you're either excluding them from the mesh or paying a tax in glue code.
Consul's bet is that discovery and mTLS are platform-agnostic primitives. Agents run anywhere a process runs. Servers form a Raft cluster. Sidecars are just Envoy processes. Nothing in that chain requires a scheduler.
Be honest about when Consul is the wrong answer: if you're 100% Kubernetes and happy with Istio or Linkerd, stay there. If you have a small static environment where a config file and a reverse proxy would do, you don't need a mesh at all. Consul's complexity is real; the payoff is cross-platform uniformity. If you don't need that uniformity, don't pay for it.
⚠️ TRUNCATED VERSION
This is an abbreviated cross-post. Full article (all config files, architecture diagrams, images): valtersit.com
🛠️ Partner Tools for Developers
ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.
Top comments (0)