8 ms·

Connecting Kubernetes services with linkerd

67 points by dankohn1 10y ago

alpb 10y ago
Great article, I've been able to learn more about why a cluster setup could utilize linkerd. However this statement confused me a little: However, Finagle is written in Scala, which Gould concedes is "not for everyone". linkerd is written in Scala [1] and linkerd is written in Rust [2]. If he is optimizing for other people’s contributions, is this really the best way to go? [1] https://github.com/linkerd/linkerd https://github.com/linkerd/linkerd [2] https://github.com/linkerd/linkerd-tcp https://github.com/linkerd/linkerd-tcp
- kevinbowman 10y ago
  Maybe it means at runtime, as opposed to at contribution-time?
- daenney 10y ago
  > linkerd is written in Scala [1] and linkerd is written in Rust [2] Though your links are correct your statement isn't. Linkerd is written in Scala, but the Rust bit is linkerd-tcp, a TCP loadbalancer, which linkerd (the Scala one) doesn't handle as that covers HTTP and gRPC with optionally encrypting connections between linkers using TLS. > If he is optimizing for other people’s contributions, is this really the best way to go? But is he optimising for other people's contributions? Using a C/Rust for something like a TCP proxy makes a lot more sense to me than having a JVM do that. And if he perceives Scala as "not for everyone", maybe adding Rust means he might get more contributions to those components? I think that statement actually refers to Finagle itself being written in Scala, so if you want to use it you have to at least hoist your own apps on the JVM and integrate Finagle in them. Finagle is essentially client-side and requires integration into your app tightly coupling the two. By spinning it out as a standalone component that acts as a proxy, like linkerd is doing, Scala doesn't get in the way and what Finagle offers can be used with a mesh of microservices written in a myriad of languages.
  - alpb 10y ago
    Sorry, not typing -tcp on linkerd-tcp was completely a typo on my end. > I think that statement actually refers to Finagle itself being written in Scala, so if you want to use it you have to at least hoist your own apps on the JVM and integrate Finagle in them. Finagle is essentially client-side and requires integration into your app tightly coupling the two. Thanks, this is the answer I have been looking for.
  - olix0r 10y ago
    Yep! That is exactly what I meant by that ;)
cookiecaper 10y ago
I appreciate the sentiment behind linkerd et al but I think we are really over-complicating things and tying ourselves into knots by going head-first into this world. I can't help but think we're going to regret it in a few years. The complexity introduced not only by Docker, but also k8s and all of the other things competing for a spot in the middle of your cluster, is immense and widely underestimated. Your applications need to be aware and adapted to the k8s model of automatic pod termination, no hard storage, etc. Google has had over 10 years with the best computer scientists money can buy to perfect their stack. Most companies don't. For most companies, k8s/linkerd/Docker deployments are a case of overengineering run frighteningly amok. There are many-a-snafu lying down this path. I'm very worried about how casually everyone is willing to jump aboard. One particular worry: most Dockerfiles are built on opaque images registered with an image registry, and many of the publishers are not well-known. If you want Ruby, the habit is to go find someone's "pre-configured" alpine-ruby image (for instance). These are frequently distributed by complete strangers. Building "from scratch" off the base image distributed by the distro itself is considered "the old way", at least among those I've worked with. My understanding is that most public image repositories are unmoderated. The moment a widely-used image gets pwned, there is going to be panic. Source: been converting entire company to Docker/k8s
- kinghajj 10y ago
  > Building "from scratch" off the base image distributed by the distro itself is considered "the old way" Then I don't want to be new. I started using a few of the Docker Hub images (mostly `openjdk`), but I've transitioned completely to building all runtime images off of `debian:jessie`. And even that image I may want to remove eventually, just so that our CI system isn't affected by Docker Hub outages.
- rubiquity 10y ago
  Yes, it's insane. I can only attribute it to that I don't work on problem of any scale (amount of apps, servers, deployments per day, etc.) and all of these people do. Who really wants to spend their time and effort running a Kubernetes master and nodes, 3+ Consul/etcd nodes, and now some fancy load balancers? The ratio of companies that would benefit from that to the number of companies working on products in the space is way out of wack.
jimktrains2 10y ago
> Facilities that linkerd provides to assist with this include service discovery, load balancing, encryption, tracing and logging, handling retries, expiration and timeouts, back-offs, dynamic routing, and metrics. Why not use SRV records and TLS? Retries, expiration, timeouts, and back-offs can all be placed into the networking library, and are, commonly. Also, regarding https://linkerd.io/ https://linkerd.io/, what's with landing pages having almost no useful information on them. "linker∙d is a transparent proxy that adds service discovery, routing, failure handling, and visibility to modern software applications" what's that even mean? > Fast, lightweight, and performant > Handles tens of thousands of requests per second per instance with minimal latency overhead. Scales horizontally with ease. Well, since you're calling yourself "transparent" I would hope it'd be fast! > Any language, any environment > Runs as a transparent proxy alongside existing applications, integrates with existing infrastructure. So, it's just proxying and retrying things and doing tls for me? Why isn't this better handled in the library I'm using to make the call in the first place? > Latency-aware load-balancing > Balances request traffic using real-time performance, reducing tail latencies across your application. Sounds like it requires a lot of cross-talk on my network, eating up bandwidth. That doesn't sound lightweight. > Runtime traffic routing > Provides dynamic, scoped, logical routing rules, enabling blue-green deployments, staging, canarying, failover, and more. OK, some of that does sound useful, but some of it still feels like something the caller should handle. > Drop-in service discovery > Integrates with most service discovery systems, decoupling applications from specific implementations. What's this mean? Why not just use SRV records? > Production-tested and proven at scale > Powers the production infrastructure of banks, artificial intelligence companies, social networks, government labs, and more. I know why this is here, but it feels like _everyone_ claims the same thing, so, to me, it just becomes noise. > "linkerd allows you to drop in a transparent layer of application resilience and provides the operational affordances critical for modern, cloud native environments." > —Oliver Gould, CTO, Buoyant This sounds doesn't make sense to me, you can't "drop in" resiliency. It needs to be built. The whole thing just feels like it's all marketing and doesn't tell me exactly what problems it's solving for me as a developer. ------------ Maybe I'm just an old fogie, or being dense, but I still don't see how this solves any problems I can't and aren't already solving.
- cookiecaper 10y ago
Artemis2 10y ago
Lyft has a tech similar to linkerd called Envoy: https://github.com/lyft/envoy https://github.com/lyft/envoy. It is a bit lower level than linkerd (based on APIs rather than already integrated with common services) and written in C++. I'm working on an adapter which should offer a better integration with Kubernetes. The end goal is to have envoy be able to replace our Ingress controllers. Not having to run the JVM on every machine is also nice.
- stock_toaster 10y ago
  > Not having to run the JVM on every machine is also nice. Personally, Envoy compiling to a binary makes it much more likely that I would experiment with it than with linkerd. I have hesitated trying out linkerd because we don't run anything JVM based in any of our stack, and we aren't currently excited about introducing any. I am definitely going to take a look at Envoy. Thanks for referencing it!
- zweizeichen 10y ago
  Folks at Lyft/IBM/Google are building a service mesh partly based on Envoy over here: https://istio.io https://istio.io
webo 10y ago
The content of the article does not have anything to do with the title. There is not mention of how linkerd and k8s work together.

67 points by dankohn1 10y ago

alpb 10y ago

Great article, I've been able to learn more about why a cluster setup could utilize linkerd. However this statement confused me a little: However, Finagle is written in Scala, which Gould concedes is "not for everyone". linkerd is written in Scala [1] and linkerd is written in Rust [2]. If he is optimizing for other people’s contributions, is this really the best way to go? [1] https://github.com/linkerd/linkerd https://github.com/linkerd/linkerd [2] https://github.com/linkerd/linkerd-tcp https://github.com/linkerd/linkerd-tcp

kevinbowman 10y ago
Maybe it means at runtime, as opposed to at contribution-time?
daenney 10y ago
> linkerd is written in Scala [1] and linkerd is written in Rust [2] Though your links are correct your statement isn't. Linkerd is written in Scala, but the Rust bit is linkerd-tcp, a TCP loadbalancer, which linkerd (the Scala one) doesn't handle as that covers HTTP and gRPC with optionally encrypting connections between linkers using TLS. > If he is optimizing for other people’s contributions, is this really the best way to go? But is he optimising for other people's contributions? Using a C/Rust for something like a TCP proxy makes a lot more sense to me than having a JVM do that. And if he perceives Scala as "not for everyone", maybe adding Rust means he might get more contributions to those components? I think that statement actually refers to Finagle itself being written in Scala, so if you want to use it you have to at least hoist your own apps on the JVM and integrate Finagle in them. Finagle is essentially client-side and requires integration into your app tightly coupling the two. By spinning it out as a standalone component that acts as a proxy, like linkerd is doing, Scala doesn't get in the way and what Finagle offers can be used with a mesh of microservices written in a myriad of languages.
- alpb 10y ago
  Sorry, not typing -tcp on linkerd-tcp was completely a typo on my end. > I think that statement actually refers to Finagle itself being written in Scala, so if you want to use it you have to at least hoist your own apps on the JVM and integrate Finagle in them. Finagle is essentially client-side and requires integration into your app tightly coupling the two. Thanks, this is the answer I have been looking for.
- olix0r 10y ago
  Yep! That is exactly what I meant by that ;)

cookiecaper 10y ago

I appreciate the sentiment behind linkerd et al but I think we are really over-complicating things and tying ourselves into knots by going head-first into this world. I can't help but think we're going to regret it in a few years. The complexity introduced not only by Docker, but also k8s and all of the other things competing for a spot in the middle of your cluster, is immense and widely underestimated. Your applications need to be aware and adapted to the k8s model of automatic pod termination, no hard storage, etc. Google has had over 10 years with the best computer scientists money can buy to perfect their stack. Most companies don't. For most companies, k8s/linkerd/Docker deployments are a case of overengineering run frighteningly amok. There are many-a-snafu lying down this path. I'm very worried about how casually everyone is willing to jump aboard. One particular worry: most Dockerfiles are built on opaque images registered with an image registry, and many of the publishers are not well-known. If you want Ruby, the habit is to go find someone's "pre-configured" alpine-ruby image (for instance). These are frequently distributed by complete strangers. Building "from scratch" off the base image distributed by the distro itself is considered "the old way", at least among those I've worked with. My understanding is that most public image repositories are unmoderated. The moment a widely-used image gets pwned, there is going to be panic. Source: been converting entire company to Docker/k8s

kinghajj 10y ago
> Building "from scratch" off the base image distributed by the distro itself is considered "the old way" Then I don't want to be new. I started using a few of the Docker Hub images (mostly `openjdk`), but I've transitioned completely to building all runtime images off of `debian:jessie`. And even that image I may want to remove eventually, just so that our CI system isn't affected by Docker Hub outages.
rubiquity 10y ago
Yes, it's insane. I can only attribute it to that I don't work on problem of any scale (amount of apps, servers, deployments per day, etc.) and all of these people do. Who really wants to spend their time and effort running a Kubernetes master and nodes, 3+ Consul/etcd nodes, and now some fancy load balancers? The ratio of companies that would benefit from that to the number of companies working on products in the space is way out of wack.

jimktrains2 10y ago

> Facilities that linkerd provides to assist with this include service discovery, load balancing, encryption, tracing and logging, handling retries, expiration and timeouts, back-offs, dynamic routing, and metrics. Why not use SRV records and TLS? Retries, expiration, timeouts, and back-offs can all be placed into the networking library, and are, commonly. Also, regarding https://linkerd.io/ https://linkerd.io/, what's with landing pages having almost no useful information on them. "linker∙d is a transparent proxy that adds service discovery, routing, failure handling, and visibility to modern software applications" what's that even mean? > Fast, lightweight, and performant > Handles tens of thousands of requests per second per instance with minimal latency overhead. Scales horizontally with ease. Well, since you're calling yourself "transparent" I would hope it'd be fast! > Any language, any environment > Runs as a transparent proxy alongside existing applications, integrates with existing infrastructure. So, it's just proxying and retrying things and doing tls for me? Why isn't this better handled in the library I'm using to make the call in the first place? > Latency-aware load-balancing > Balances request traffic using real-time performance, reducing tail latencies across your application. Sounds like it requires a lot of cross-talk on my network, eating up bandwidth. That doesn't sound lightweight. > Runtime traffic routing > Provides dynamic, scoped, logical routing rules, enabling blue-green deployments, staging, canarying, failover, and more. OK, some of that does sound useful, but some of it still feels like something the caller should handle. > Drop-in service discovery > Integrates with most service discovery systems, decoupling applications from specific implementations. What's this mean? Why not just use SRV records? > Production-tested and proven at scale > Powers the production infrastructure of banks, artificial intelligence companies, social networks, government labs, and more. I know why this is here, but it feels like _everyone_ claims the same thing, so, to me, it just becomes noise. > "linkerd allows you to drop in a transparent layer of application resilience and provides the operational affordances critical for modern, cloud native environments." > —Oliver Gould, CTO, Buoyant This sounds doesn't make sense to me, you can't "drop in" resiliency. It needs to be built. The whole thing just feels like it's all marketing and doesn't tell me exactly what problems it's solving for me as a developer. ------------ Maybe I'm just an old fogie, or being dense, but I still don't see how this solves any problems I can't and aren't already solving.

cookiecaper 10y ago

Artemis2 10y ago

Lyft has a tech similar to linkerd called Envoy: https://github.com/lyft/envoy https://github.com/lyft/envoy. It is a bit lower level than linkerd (based on APIs rather than already integrated with common services) and written in C++. I'm working on an adapter which should offer a better integration with Kubernetes. The end goal is to have envoy be able to replace our Ingress controllers. Not having to run the JVM on every machine is also nice.

stock_toaster 10y ago
> Not having to run the JVM on every machine is also nice. Personally, Envoy compiling to a binary makes it much more likely that I would experiment with it than with linkerd. I have hesitated trying out linkerd because we don't run anything JVM based in any of our stack, and we aren't currently excited about introducing any. I am definitely going to take a look at Envoy. Thanks for referencing it!
zweizeichen 10y ago
Folks at Lyft/IBM/Google are building a service mesh partly based on Envoy over here: https://istio.io https://istio.io

webo 10y ago

The content of the article does not have anything to do with the title. There is not mention of how linkerd and k8s work together.