We’re happy to announce that we’ve released linkerd 0.8.4! With this release, two important notes. First, Kubernetes and Consul support are now officially production-grade features—high time coming, since they’re actually already used widely in production. Second, this release features some significant improvements to linkerd’s HTTP/2 and gRPC support, especially around backpressure and request cancelation.
In this post we’ll show you how to use a service mesh of linkerd instances to handle ingress traffic on Kubernetes, distributing traffic across every instance in the mesh. We’ll also walk through an example that showcases linkerd’s advanced routing capabilities by creating a dogfood environment that routes certain requests to a newer version of the underlying application, e.g. for internal, pre-release testing.
Linkerd is a service mesh for cloud-native applications. What does this mean? What is a service mesh, and when do you need one? And what’s the difference between a service mesh, an “enterprise service bus”, and other forms of communication management (e.g. “stick everything into queues”)?
Beyond service discovery, top-line metrics, and TLS, linkerd also has a powerful routing language, called dtabs, that can be used to alter the ways that requests—even individual requests—flow through the application topology. In this article, we’ll show you how to use linkerd as a service mesh to do blue-green deployments of new code as the final step of a CI/CD pipeline.
In this article, we’ll show you how to use linkerd as a service mesh to add TLS to all service-to-service HTTP calls, without modifying any application code.
In our recent post about linkerd on Kubernetes, A Service Mesh for Kubernetes, Part I: Top-line Service Metrics, observant readers noticed that linkerd was installed using DaemonSets rather than as a sidecar process. In this post, we’ll explain why (and how!) we do this.
In our previous post, linkerd as a service mesh for Kubernetes, we showed you how to use linkerd on Kubernetes for drop-in service discovery and monitoring. In this post, we’ll show you how to get the same features on DC/OS, and discuss how this compares with DNS-based solutions like Mesos-DNS.
What is a service mesh, and how is it used by cloud native apps—apps designed for the cloud? In this article, we’ll show you how to use linkerd as a service mesh on Kubernetes, and how it can capture and report top-level service metrics such as success rates, request volumes, and latencies without requiring changes to application code.
In this post, we’ll describe how we reduced the memory footprint of linkerd, our JVM-based service mesh for cloud-native applications, by almost 80%—from 500mb to 105mb—by tuning the JVM’s runtime parameters. We’ll describe why we went through this painful exercise, and the various things that did—and didn’t—help us get there.
Version 0.6.0 of linkerd and namerd were released today! We wanted to take the opportunity in this release to bring more consistency and uniformity to our config files. Unfortunately, this means making non-backwards compatible changes. In this post, we describe how to update your config files to work with 0.6.0.