Hands on with Linkerd 2.0 (opens in new tab)

(kubernetes.io)

139 pointspyronicide7y ago37 comments

37 comments

28 comments · 7 top-level

Thaxll7y ago· 5 in thread

I'm testing Istio at the moment and I feel those comments to be very inaccurate:

"Traditional service meshes are an all-or-nothing proposition that add a significant layer of complexity to your stack. That’s not great."

Istio is like k8 it's very modular and you setup what you need.

"Traditional service meshes are designed to meet the needs of platform owners, and they dramatically underserve a more important audience: the service owners."

Not sure what it means, Istio is all about observability ect...

williamallthing7y ago

Those quotes aren't from the article. I'll address them anyways since they're from a different article which I wrote:

>> "Traditional service meshes are an all-or-nothing proposition that add a significant layer of complexity to your stack. That’s not great."

> Istio is like k8 it's very modular and you setup what you need.

Istio is a very different beast from Linkerd. But out of curiosity, I just tried the latest Istio release on my laptop (1.0.2 on Docker for Mac K8s). The simplest configuration I found installs 50 (!) CRDs, 13 deployments, and is currently sitting at ~600mb of memory without any traffic. Perhaps by "modular" you mean you can add more modules on top of that?

(By contrast, Linkerd 2.0 installs 0 CRDs, 4 services, and is sitting at 250mb including 50mb full Grafana UI. It also does a lot less... but that's the point.)

That's the control plane. Let's not get started on the data plane.

>> "Traditional service meshes are designed to meet the needs of platform owners, and they dramatically underserve a more important audience: the service owners."

> Not sure what it means, Istio is all about observability ect...

This is all in the article. You can install Linkerd as a service owner on a single service. You'll get metrics, debugging, and more. It's lightweight and small enough for this installation make sense.

Try it. You might just like it :)

brazzledazzle7y ago

Are they talking about Istio? It seems way too new to call it “traditional”.

presspot7y ago

Buoyant invented the service mesh concept and added that term to our vernacular as a way to describe Linkerd 1.x and similar systems. Istio was built using the same pattern as Linkerd 1.0. Those are "traditional", albeit in internet years not real years.

Linkerd 2.0 takes a fundamentally different approach. It's tiny, fast, lightweight and designed to add value as a service sidecar (installed on a single service) without any "mesh". If multiple service owners install Linkerd 2.0, it self-morphs into a mesh configuration and provides all of the value of a service mesh. This creates an installation and deployment pattern that is very practical and bottoms-up, delivering value to the individual service (and service owner) but also supporting a higher-level abstraction of a mesh at the platform level. This is a fundamental innovation and, hence, a new model for service mesh patterns versus the original, er, traditional model.

williamallthing7y ago

The article this quote is pulled from [1] is primarily referring to Linkerd 1.x, but Istio follows the same patterns.

[1] https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/

barbecue_sauce7y ago

What would be an example of a "traditional" service mesh then?

2 more replies

jazoom7y ago· 4 in thread

This looks great but I'll hold off using it until it gets automatic sidecar injection.

The CLI YAML-adulterer doesn't fit into my flow very well.

clux7y ago

Honestly I'd much rather have some configurable yaml than some obscure app in the middle of your cluster that reads CRDs when what you're doing is just adding a side car.

At least this way you can tell if your local yaml is applied or not without a complicated diffing algorithm that compensates for an in-cluster modifier.

jazoom7y ago

I would too, except, have you seen what your YAML looks like after all the Linkerd additions? There's a reason they don't even mention in the docs exactly what it changes.

williamallthing7y ago

There's a PR open! https://github.com/linkerd/linkerd2/pull/1423

jazoom7y ago

Yup. That's the one I'm waiting for. I'm subscribed to notifications.

stock_toaster7y ago· 4 in thread

Doesn't seem like it is designed to work outside of k8s anymore?

Anyone know of a service mesh that is intended to run in a more standalone fashion? (itsio also integrates very strongly to k8s)

fosk7y ago

Marco, CTO of Kong here. This is exactly what Kong has been doing for a while and with the newly announced Kong 1.0 release [1] (2 days ago) we also support Service Mesh with a lightweight runtime that has been running in production since 3.5 years across multiple platforms, hybrid container orchestration platforms and even hybrid baremetal/cloud deployments.

GA for Kong 1.0 will include Service Mesh (we have RC1 now, and RC2 coming soon).

[1] - https://konghq.com/blog/announcing-kong-1-0/

stock_toaster7y ago

Thanks, I’ll certainly take a look!

williamallthing7y ago

Just a question of starting point. Linkerd 1.x has been running for years on multiple platforms, and we'll get there with the 2.x line as well.

stock_toaster7y ago

Ah. The docs read like k8s was the only concern.

I’ll keep an eye on it for possible future day where it supports bare OS.

1 more reply

sitkack7y ago· 4 in thread

For those that care, the core of linkerd 2.0 is in Rust

https://github.com/linkerd/linkerd2-proxy

carllerche7y ago

Also, a lot of the work on Tokio [1], Tower [2], and the Rust HTTP/2.0 implementation [3] is being driven by linkerd 2.0 (and sponsored by Buoyant).

[1]: http://github.com/tokio-rs/tokio [2]: http://github.com/tower-rs/tower [3]: https://github.com/carllerche/h2

Thaxll7y ago

Why do you call that core, only the sidecar is written in Rust all the rest is Go I think.

otterley7y ago

Do you know why they migrated from Scala?

jazoom7y ago

A JVM attached as a sidecar to each pod is a waste of resources.

Garbage collection isn't great for a high performance proxy.

2 more replies

Bramcko167y ago· 3 in thread

So what's the difference between this and istio?

eikenberry7y ago

There was a blog post just a few days ago comparing them (along with Linkerd and Consul Connect). Maybe it will help.

https://kubedex.com/istio-vs-linkerd-vs-linkerd2-vs-consul/

SushiMon7y ago

The post is long but it was really written from the POV of an infrastructure owner (DevOps) and not from the POV of a service owner/developer which is actually the target for Linkerd 2.0. FWIW - the post says it takes 5 mins to install Istio. I find that very, very hard to believe.

2 more replies

williamallthing7y ago

Linkerd person here. The two projects have very different goals. I wrote some more about this on the Linkerd blog: https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/

wyldfire7y ago· 1 in thread

linkerd is not a linker? All I can think of is Dr. Nick: "Inflammable means flammable?! What a country!"

overcast7y ago

Inflammable is everywhere in India, I honestly hadn't seen that word used to describe flammable things!

erik_seaberg7y ago

I get why I want metrics from an RPC service, but not why I want them behind a process boundary. How do custom metrics (items processed/filtered per request, experiment vs control SR) work?

j / k navigate · click thread line to collapse

37 comments

28 comments · 7 top-level

Thaxll7y ago· 5 in thread

I'm testing Istio at the moment and I feel those comments to be very inaccurate:

"Traditional service meshes are an all-or-nothing proposition that add a significant layer of complexity to your stack. That’s not great."

Istio is like k8 it's very modular and you setup what you need.

"Traditional service meshes are designed to meet the needs of platform owners, and they dramatically underserve a more important audience: the service owners."

Not sure what it means, Istio is all about observability ect...

williamallthing7y ago

Those quotes aren't from the article. I'll address them anyways since they're from a different article which I wrote:

>> "Traditional service meshes are an all-or-nothing proposition that add a significant layer of complexity to your stack. That’s not great."

> Istio is like k8 it's very modular and you setup what you need.

(By contrast, Linkerd 2.0 installs 0 CRDs, 4 services, and is sitting at 250mb including 50mb full Grafana UI. It also does a lot less... but that's the point.)

That's the control plane. Let's not get started on the data plane.

>> "Traditional service meshes are designed to meet the needs of platform owners, and they dramatically underserve a more important audience: the service owners."

> Not sure what it means, Istio is all about observability ect...

Try it. You might just like it :)

brazzledazzle7y ago

Are they talking about Istio? It seems way too new to call it “traditional”.

presspot7y ago

williamallthing7y ago

The article this quote is pulled from [1] is primarily referring to Linkerd 1.x, but Istio follows the same patterns.

[1] https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/

barbecue_sauce7y ago

What would be an example of a "traditional" service mesh then?

2 more replies

jazoom7y ago· 4 in thread

This looks great but I'll hold off using it until it gets automatic sidecar injection.

The CLI YAML-adulterer doesn't fit into my flow very well.

clux7y ago

Honestly I'd much rather have some configurable yaml than some obscure app in the middle of your cluster that reads CRDs when what you're doing is just adding a side car.

At least this way you can tell if your local yaml is applied or not without a complicated diffing algorithm that compensates for an in-cluster modifier.

jazoom7y ago

I would too, except, have you seen what your YAML looks like after all the Linkerd additions? There's a reason they don't even mention in the docs exactly what it changes.

williamallthing7y ago

There's a PR open! https://github.com/linkerd/linkerd2/pull/1423

jazoom7y ago

Yup. That's the one I'm waiting for. I'm subscribed to notifications.

stock_toaster7y ago· 4 in thread

Doesn't seem like it is designed to work outside of k8s anymore?

Anyone know of a service mesh that is intended to run in a more standalone fashion? (itsio also integrates very strongly to k8s)

fosk7y ago

GA for Kong 1.0 will include Service Mesh (we have RC1 now, and RC2 coming soon).

[1] - https://konghq.com/blog/announcing-kong-1-0/

stock_toaster7y ago

Thanks, I’ll certainly take a look!

williamallthing7y ago

Just a question of starting point. Linkerd 1.x has been running for years on multiple platforms, and we'll get there with the 2.x line as well.

stock_toaster7y ago

Ah. The docs read like k8s was the only concern.

I’ll keep an eye on it for possible future day where it supports bare OS.

1 more reply

sitkack7y ago· 4 in thread

For those that care, the core of linkerd 2.0 is in Rust

https://github.com/linkerd/linkerd2-proxy

carllerche7y ago

Also, a lot of the work on Tokio [1], Tower [2], and the Rust HTTP/2.0 implementation [3] is being driven by linkerd 2.0 (and sponsored by Buoyant).

[1]: http://github.com/tokio-rs/tokio [2]: http://github.com/tower-rs/tower [3]: https://github.com/carllerche/h2

Thaxll7y ago

Why do you call that core, only the sidecar is written in Rust all the rest is Go I think.

otterley7y ago

Do you know why they migrated from Scala?

jazoom7y ago

A JVM attached as a sidecar to each pod is a waste of resources.

Garbage collection isn't great for a high performance proxy.

2 more replies

Bramcko167y ago· 3 in thread

So what's the difference between this and istio?

eikenberry7y ago

There was a blog post just a few days ago comparing them (along with Linkerd and Consul Connect). Maybe it will help.

https://kubedex.com/istio-vs-linkerd-vs-linkerd2-vs-consul/

SushiMon7y ago

2 more replies

williamallthing7y ago

Linkerd person here. The two projects have very different goals. I wrote some more about this on the Linkerd blog: https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/

wyldfire7y ago· 1 in thread

linkerd is not a linker? All I can think of is Dr. Nick: "Inflammable means flammable?! What a country!"

overcast7y ago

Inflammable is everywhere in India, I honestly hadn't seen that word used to describe flammable things!

erik_seaberg7y ago

I get why I want metrics from an RPC service, but not why I want them behind a process boundary. How do custom metrics (items processed/filtered per request, experiment vs control SR) work?

j / k navigate · click thread line to collapse