As part of our Linkerd 1.0 release last month, we snuck in something that a few people have picked up on—Linkerd’s service mesh API. With the 1.0 release happily out of the way, we thought we’d take a moment to explain what this API does and what it means for the future of Linkerd. We’ll also show off one of the upcoming features of this API—dynamic control over Linkerd’s per-service communications policy.
Today, we’re thrilled to announce Linkerd version 1.0. A little more than one year from our initial launch, Linkerd is part of the Cloud Native Computing Foundation and has a thriving community of contributors and users. Adopters range from startups like Monzo, which is disrupting the UK banking industry, to high scale Internet companies like Paypal, Ticketmaster, and Credit Karma, to companies that have been in business for hundreds of years like Houghton Mifflin Harcourt.
tl;dr: A service mesh is a dedicated infrastructure layer for making service-to-service communication safe, fast, and reliable. If you’re building a cloud native application, you need a service mesh!
Over the past year, the service mesh has emerged as a critical component of the cloud native stack. High-traffic companies like Paypal, Lyft, Ticketmaster, and Credit Karma have all added a service mesh to their production applications, and this January, Linkerd, the open source service mesh for cloud native applications, became an official project of the Cloud Native Computing Foundation. But what is a service mesh, exactly? And why is it suddenly relevant?
As of Linkerd 0.8.5, released earlier this year, Linkerd supports gRPC and HTTP/2! These powerful protocols can provide significant benefits to applications that make use of them. In this post, we’ll demonstrate how to use Linkerd with gRPC, allowing applications that speak gRPC to take full advantage of Linkerd’s load balancing, service discovery, circuit breaking, and distributed tracing logic.
Linkerd is designed to make service-to-service communication internal to an application safe, fast and reliable. However, those same goals are also applicable at the edge. In this post, we’ll demonstrate a new feature of Linkerd which allows it to act as a Kubernetes ingress controller, and show how it can handle ingress traffic both with and without TLS.
Yesterday, at Kubecon EU, I announced an exciting new project in the Linkerd family: Linkerd-tcp. Linkerd-tcp is a lightweight, service-discovery-aware, TLS-ing TCP load balancer that integrates directly with the existing Linkerd service mesh ecosystem. It’s small, fast, and secure—and, like Linkerd itself, integrates with a wide variety of service discovery and orchestration systems including Kubernetes, DC/OS, and Consul.
Linkerd’s role as a service mesh makes it a great source of data around system performance and runtime behavior. This is especially true in polyglot or heterogeneous environments, where instrumenting each language or framework can be quite difficult. Rather than instrumenting each of your apps directly, the service mesh can provide a uniform, standard layer of application tracing and metrics data, which can be collected by systems like Zipkin and Prometheus.
We’re happy to announce that, one year after version 0.1.0 was released, Linkerd has processed over 100 billion production requests in companies around the world. Happy birthday, Linkerd! Let’s take a look at all that we’ve accomplished over the past year.
Today we’re happy to release Linkerd 0.9.0, our best release yet! This release is jam packed with internal efficiency upgrades and major improvements to the admin dashboard. We also took this opportunity to make some backwards incompatible changes to simplify Linkerd configuration. See the bottom of this post for a detailed guide on what changes you’ll need to make to your config to upgrade from 0.8.* to 0.9.0.
You can download Linkerd 0.9.0 from github or find images on dockerhub. To learn about all the great stuff included in 0.9.0, read on!
Alex Leong
Oliver Gould
William Morgan
Risha Mars
Sarah Brown
Kevin Lingerfelt