This is not the latest version of Linkerd!
This documentation is for Linkerd 1.x, an older version with some significant differences. You may want to see the Linkerd 2.x (current) documentation instead.

Overview

These tutorials exist to walk you through several sample concepts for practical application of a service mesh. Linkerd can be used on several platforms but, for simplicity, this section uses Kubernetes (via GKE or Minikube) so that you can see how these concepts apply against a real environment.

Introduction

One of the most common questions when getting started with Linkerd is: what exactly is a service mesh? Why is a service mesh a critical component of cloud native apps, when environments like Kubernetes provide primitives like service objects and load balancers?

A service mesh is a layer that manages the communication between apps (or between parts of the same app, e.g. microservices). In traditional apps, this logic is built directly into the application itself: retries and timeouts, monitoring/visibility, tracing, service discovery, etc. are all hard-coded into each application.

However, as application architectures become increasingly segmented into services, moving communications logic out of the application and into the underlying infrastructure becomes increasingly important. Just as applications shouldn’t be writing their own TCP stack, they also shouldn’t be managing their own load balancing logic, or their own service discovery management, or their own retry and timeout logic. (For example, see Oliver Gould’s MesosCon talk for more about the difficulty of coordinating retries and timeouts across multiple services.)

The Linkerd service mesh provides critical features to multi-service applications running at scale:

  • Baseline resilience: retry budgets, deadlines, circuit-breaking.
  • Top-line service metrics: success rates, request volumes, and latencies.
  • Latency and failure tolerance: Failure- and latency-aware load balancing that can route around slow or broken service instances.
  • Distributed tracing a la Zipkin and OpenTracing
  • Service discovery: locate destination instances.
  • Protocol upgrades: wrapping cross-network communication in TLS, or converting HTTP/1.1 to HTTP/2.0.
  • Routing: route requests between different versions of services, failover between clusters, etc.

The tutorials in this series include:

I. Top-line service metrics. What is a service mesh, and how is it used by cloud native apps—apps designed for the cloud? In this tutorial, we’ll show you how to use Linkerd as a service mesh.

II. Pods vs DaemonSets. As a service mesh, Linkerd is designed to be run alongside application code, managing and monitoring inter-service communication

III. TLS by default. In this tutorial, 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.

IV. Continuous deployment. In this tutorial, we’ll show you how to use Linkerd’s routing rules to automatically alter traffic flow through your application.