4 ms·
This is something of a special case. Running Linkerd as a sidecar container — which is the pattern that's increasingly adopted in the Kubernetes world for servi
by lobster_johnson 9y ago
This is something of a special case. Running Linkerd as a sidecar container — which is the pattern that's increasingly adopted in the Kubernetes world for service meshes and proxies — means you're going to run a large, memory-hungry JVM in every single container. Just guessing, but that's likely 300-500MB per container. It just doesn't mesh (heh) well with how Kubernetes is supposed to be run.
It's not surprising that Istio settled on Envoy, which is written in C++.
- geodel 9y agoIt is kind of sad that writing resource efficient software is considered a special case.
- lobster_johnson 9y agoNot really what I meant. It's a "special case" because the sidecar container is a niche where the JVM doesn't work well. That doesn't mean you can't run JVM successfully elsewhere, which of course people do. For example, you may be deploying a bunch of lean Go microservices that, at maximum, consume perhaps 20MB of memory each (peak). You can run 100 instances of said app and only consume 2,000MB, but add a big JVM that weighs, say, 200MB a piece, you now need 22,000MB of memory instead. JVM startup time might be another factor, but I've not measured this.
- williamallthing 9y agoSpot on. FWIW with some effort we can get Linkerd down to ~110mb. For some companies that's acceptable. Still, it's a far cry from the ~3mb footprint that the Conduit proxies current have.