
A Service Mesh for Kubernetes, Part I: Top-Line Service Metrics - aberoham
https://blog.buoyant.io/2016/10/04/a-service-mesh-for-kubernetes-part-i-top-line-service-metrics/
======
lobster_johnson
I'm curious how managable this in practice.

On the one hand, Linkerd brings some real technical solutions to the table
that Kubernetes can't solve right now — K8s' L4 load-balancing can only load-
balance entire connections, not requests. For that reason, K8s can't do
anything to assist you with timeouts, retries, rate-limiting, tracing or
metrics collection. I like the idea of a semi-transparent middleman that
handles these things for you and lets your applications be small and simple.

On the other, this setup replaces a core K8s concept with its own, less proven
components. As I understand it, Linkerd's daemon replaces service lookup
entirely; it will talk to the API server to get service endpoints, which means
it needs to invent its own logic to keep up to date with changing pod
configurations. It had better be solid stuff!

To reduce surface area, I wonder if running one Linkerd per pod in a sidecar
container is a viable option, or would that be crazy?

As an aside, can anyone explain why the example needs to start "kubectl proxy"
in a sidecar container? Kubernetes already has a perfectly good way for apps
to talk to the API server through a service account [1]. Seems iffy to me.

[1] [http://kubernetes.io/docs/user-guide/accessing-the-
cluster/#...](http://kubernetes.io/docs/user-guide/accessing-the-
cluster/#accessing-the-api-from-a-pod)

~~~
williamallthing
Great point about the need for production worthiness. FWIW the load balancing
pool management, etc., in linkerd is straight from Finagle, which is probably
_more_ proven than Kubernetes, if anything (powers Twitter, Pinterest,
SoundCloud, etc.) Some K8s-specific bits are fresher code, but even those have
been tested at non-trivial scale, e.g.
[https://monzo.com/blog/2016/09/19/building-a-modern-bank-
bac...](https://monzo.com/blog/2016/09/19/building-a-modern-bank-backend/)

------
whalesalad
Still trying to get the laymans explanation of linkerd. Is it a drop-in
replacement for making service-to-service HTTP calls? AFAIK it's a standalone
proxy-like version of Finagle.

~~~
skMed
Right, if I want to rely on Finagle's RPC capabilities, e.g. load balancing,
routing, tracing, etc, then my microservice must be JVM based and use the
Finagle library. This is a standalone proxy deployed as a 'sidecar' app
alongside my service. This allows me to implement the microservice in any
language I want and get some of the features listed previously.

Of course you now have another moving part in your system :)

------
justinsaccount
See also: Envoy

[https://lyft.github.io/envoy/](https://lyft.github.io/envoy/)

[https://news.ycombinator.com/item?id=12497926](https://news.ycombinator.com/item?id=12497926)

------
tamalsaha001
I thought Kubernetes itself does service discovery and load balancing. Why
would I want another layer/proxy to the involved?

~~~
williamallthing
Request-level versus connection-level load balancing. See e.g.
[https://blog.buoyant.io/2016/03/16/beyond-round-robin-
load-b...](https://blog.buoyant.io/2016/03/16/beyond-round-robin-load-
balancing-for-latency/)

