Open anitsh opened 3 years ago
anitsh
commented
3 years ago By the end of this chapter, you should be able to:
anitsh
commented
3 years ago Linkerd has only one real dependency, which is Kubernetes. Thus, any discussion of Linkerd should probably start with a discussion of Kubernetes.
Of course, this class is not intended as an introduction to Kubernetes. We assume you are familiar with the basics of container orchestration, what Kubernetes is, and how it works. However, there is one important aspect of Kubernetes that is very relevant to Linkerd: that Kubernetes is, to quote Kelsey Hightower, a "platform for building platforms". In other words, rather than taking the approach of building the ultimate PaaS that does everything for everyone, Kubernetes purposefully restricts its scope. This intentional restriction in scope is a critical part of understanding why Linkerd (and any service mesh) can exist: Linkerd adds functionality that is intentionally out-of-scope for Kubernetes.
For example, Linkerd can provide mutual TLS (mTLS) between the services in a multi-service application. By default, the pods in a Kubernetes cluster communicate with each other in plaintext (unless, of course, the application itself does something different). This is not a failing of Kubernetes: it is because Kubernetes does not have an opinion on whether the traffic should be encrypted. Linkerd's ability to provide mTLS so that the traffic between services is encrypted is thus a natural extension of what Kubernetes provides. Other examples of service mesh functionality that are complementary to Kubernetes include load balancing for the gRPC protocol, request retries and timeouts between pods, "golden metrics" instrumentation, and so on.
In summary: the intentionally-limited scope of Kubernetes is one of the things that allows a flourishing ecosystem around Kubernetes itself, and is a fundamental reason why service meshes like Linkerd exist and provide value.
anitsh
commented
3 years ago In addition to Kubernetes, one project that is often mentioned in service mesh discussions is Envoy. Envoy is a "layer 7" proxy written in C++ and designed for use with distributed systems. Envoy was originally designed by engineers at Lyft, and was later donated to the CNCF. In the same way that NGINX improved on the functionality offered by the Apache web server, Envoy adds features like service discovery, dynamic configuration, and observability for cloud native applications and distributed application architectures.
Envoy's featureset means that Envoy is often called a "service proxy". Despite this, note that Envoy is not a service mesh: it is a powerful, general-purpose proxy that can be used in a variety of ways, including as part of a service mesh, but also as a Kubernetes ingress controller, as a cluster egress proxy, and so on.
Envoy is a popular choice as the data plane proxy component in many service meshes projects, including Istio (which we'll cover shortly). However, Linkerd does not use Envoy. Instead, Linkerd uses a proxy called simply linkerd2-proxy. Linkerd2-proxy is written in Rust and, in contrast to Envoy's general-purpose nature, is tightly coupled with the components in the Linkerd control plane. This is part of what gives Linkerd its performance and low resource consumption. We'll cover the Linkerd proxy in great detail in the next chapter.
In summary: Envoy is a service proxy, but not a service mesh; and Linkerd does not use Envoy, but is often paired with Envoy, e.g. in the form of an ingress proxy.
anitsh
commented
3 years ago No discussion of the service mesh would be complete without a mention of Istio, the service mesh made popular through the efforts of Google and built jointly with IBM. Like Linkerd, the Istio architecture consists of a control plane and a data plane. Unlike Linkerd, the Istio project uses Envoy as its data plane proxy, and is not a CNCF project. While Envoy itself is a CNCF project. Istio has sought governance under the Open Usage Commons organization created by Google.
From the project perspective, generally speaking, Istio and Linkerd have similar goals but are very different projects. One way of looking at it is: Istio is focused on features, even at the expense of complexity; Linkerd is focused on simplicity, even at the expense of features. There's much more that can be said about the comparison between these two projects, but we'd encourage you to draw your own conclusions: install both and see which best suits your needs, and which will impose the lowest operational burden on you and your teammates.
Beyond Istio, there are many other service mesh projects. Sometimes it feels like a new service mesh project comes out every month! We won't cover them in this course, but the CNCF Landscape includes a service mesh category which captures most or all of the projects in this ecosystem.
anitsh
commented
3 years ago The Service Mesh Interface Specification is a relatively new open source project which is part of the CNCF. The goal of the project is to define a standard set of interfaces that all service mesh projects can use to implement the most common service mesh use cases. Those use cases include things like:
Traffic policy Apply policies like identity and transport encryption across services. Traffic telemetry Capture key metrics like error rate and latency between services. Traffic management Shift traffic between different services. Linkerd implements (some of) the current SMI spec. For example, later in this course, we'll see how to use the TrafficSplit SMI API in Linkerd to provide traffic management functionality for canary and blue green deployments.
anitsh
commented
3 years ago In this chapter, we took a high-level look at some of the technologies and projects in the broader service mesh ecosystem. As part of the core knowledge for this course, we briefly touched on Kubernetes, Envoy, and Istio, and saw how Linkerd related to each of them. Any of these topics could be covered in much more detail, but that is outside the scope of this course.
Chapter Overview
To help better understand Linkerd, it's very helpful to know about the ecosystem in which Linkerd exists. In this chapter, we're going to take a look at several technologies and projects that make up this ecosystem, and examine how Linkerd relates to them.
This chapter will start with a brief look at Kubernetes. Then, we'll take a look at some other projects in the service mesh and service proxy landscape. Finally, we'll dive into the Service Mesh Interface Specification (SMI) project to learn how the service mesh community is working to define a set of standards across service mesh projects.