Last update:
A few months ago my colleague asked me what I think about integrating Linkerd to our new application running on Kubernetes. My first thought was, heck, isn't Kubernetes service and ingress enough? You can do much stuff with it. Having a service mesh seemed like overhead to me. You often have some API which is available only on the internal network. However, this is not the case anymore with modern applications. The API is probably exposed to the Internet as well and gets much traffic. You want more control of the traffic that goes to this API. Maybe you want to support more API versions, do canary deployments, and you want to watch and keep track of each request that comes in. It is where service mesh comes into play. It doesn't matter if you want to use Linkerd or Istio principals are almost the same.
Why Service Mesh?
Service mesh is not something that came up with Kubernetes. However, it is easier to integrate service mesh into your environment thanks to Kubernetes. Two logical components create service mesh. We already have pods which are designed to have many containers. Sidecar is the perfect example which extends and enhances the primary container in a pod. With service mesh, the sidecar is service proxy or data plane.
Service mesh is a critical component of cloud-native.
To better understand the service mesh, you need to understand terms proxy and reverse proxy. Proxy, in a nutshell, receives the traffic and forwards it to somewhere else. Reverse proxy receives the traffic from many clients and then forwards that traffic to lots of services. In this case, all the clients talk to one proxy instance. Think of data plane as a reverse proxy. Ingress is also reverse proxy used to expose the services in Kubernetes. Ingress can terminate SSL, provides name-based routing and that is pretty much it. The same thing is with Kubernetes services. What if you want to make some more complicated routing?
Here are a few other things that service mash is capable of:
- Load balancing
- Fine-grained traffic policies
- Service discovery
- Service monitoring
- Tracing
- Routing
- Secure service to service communication
Other then sidecar proxies all service mesh solutions have some controller which defines how sidecar containers should work. Service mesh control plane is the central place to manage the service mesh and service proxies. The service mesh control plane records network information, so it is a network monitoring tool also.
So, why service mesh? The answer is simple. You can do all the above without making changes to your code. It saves time and money. Also, most important, you will not skip some testing because it is too complicated, to begin with. You can even simulate different scenarios on how the service will react to failures with features like Istio fault injection.
Linkerd2 and Istio
In the beginning, I mentioned two great solutions to create a service mesh on Kubernetes. In the future, they might be many others. Each product tries to solve problems in its way. They might be overlapping in some areas of course.
Buoyant, the company that created Linkerd also created Conduit service mesh. Recently Conduit has been merged into the Linkerd project as Linkerd2. The buoyant team created Linkerd service mesh as a more generic solution. It is written in Java, which means it can be heavy. Remember, each pod gets one more container, a sidecar. Linkerd2 is designed for Kubernetes. It is written in Go - control plane, and Rust - a native service proxy, to be ultra-lightweight, fast and secure. You can define retries and timeouts, have instrumentation, and encryption (TLS), as well as allowing and denying requests according to the relevant policy. Also, it comes with a nice dashboard:
Alternatively, if you prefer terminal linkerd CLI is also available.
Linkerd2 getting started guide is excellent, so please try it yourself. To learn more about it, please check the official documents.
Istio currently supports Kubernetes and Nomad, with more to come in the feature. Istio is a multi-platform solution. It manages traffic flow across microservices, enforce policies and aggregate telemetry data. Istio is also written in Go to be lightweight but unlike Linkerd2 it employes Envoy to do the service proxy. To see how everything fits together check Istio architecture diagram:
What I like about Istio is the support for auto sidecar injection. The chances are that you already use Helm to deploy applications, so injecting the sidecar manually into Kubernetes config files is not an option.
To install Istio on Kubernetes check quick start guide. For all other information about Istio, please check the official documents.
Both products are open source too. Whichever service mesh better suits your needs, they are both pretty much easy to try. You will not spend more than 5 minutes to get things running. I encourage you to try both and then decide. Istio at this point can do a lot more than Linkerd2, and it has a stable release.
Summary
I hope I gave you a nice introduction to service mesh. This post wasn't meant to be a comparison between Linkerd2 and Istio. I listed some of its features so you can get the idea of what service mesh brings to the table in the Kubernetes world. Stay tuned for the next one.