Shulou(Shulou.com)06/02 Report--

Translation | Song Song

Original text | https://medium.com/solo-io/linkerd-or-istio-6fcd2aad6e42

This week I started writing a post comparing Istio and Linked and told myself: I'm going to use a table to compare the features of the two, which will be great, people will love it, and the world will be happy for a few seconds. I promised myself that this would be a fair comparison without any bias. Although the comparison table still exists, I shifted the end of the article: the goal is no longer which is better, but which is better for you, your application, and your organization.

For some time in my career, I worked as a pre-sales architect for a company, and I remember many times when we were asked to fill out product comparison forms. I often need to use creativity to make sure the product looks good and avoid the unpleasant "unsupported" boxes in the table at almost all costs. Consider working in good faith, but sometimes you have to do it.

From the evaluator's point of view, I understand that their purpose is to make a fair comparison, and to this extent, the comparison table seems to be a reliable way. We know that the success of a project can predict career development, and we all like that. But the problem is: if the ultimate goal of the evaluation is the product comparison table, rather than the high-quality software that makes the enterprise more competitive, then the evaluation will end up with some "table" work.

Product comparison is not the ultimate goal, but to know which use cases are best for you by comparison. So let's make an in-depth study of Service Mesh through seven aspects, mainly the following aspects:

Traffic management

Safety

Installation / configuration

Supported environment

Monitor and control

Policy management

Performance

I will express my personal views on each of the above seven aspects, and I hope my views will help you make decisions that are closer to simplicity.

Traffic management

It is important to emphasize that the difference between Istio and Linkerd is that the data plane uses two different proxy technologies.

Istio uses Envoy as its proxy. Envoy was written by C++ and was originally built by Lyft to facilitate traffic management of micro-services in a non-Kubernetes way. Many companies have extended Envoy to Kubernetes's ingress technology.

Linkerd (v2) uses a dedicated service grid proxy called Linkerd-proxy. This agent is written in Rust, and along with this agent, many low-level proxy (network client and server) functions are implemented in another project also written by rust called Tower. Tower relies on Tokio,Tokio, which is an event-driven non-blocking IZP O library written by Rust. If you like statistics as much as I do, Rust has been the most popular language of Stack-overflow for four years in a row (2016, 2017, 2018, 2019).

Istio is built on top of Envoy, so it has an advantage in traffic management, and Envoy already includes important IMHO functions, such as subset routing. Users can still use Linkerd to implement canary / blue-green / Amurb publishing, but they must rely on separate Kubernetes services and cluster ingress technologies that can distribute traffic, such as Gloo (gloo.solo.io).

The Linkerd team publicly announced at a recent community meeting that they plan to implement more advanced L7 traffic management capabilities in future releases.

Safety

With regard to security, I am considering the ability to protect communication channels. Both Istio and Linkerd provide reasonable security protection.

Both Istio and Linkerd rely on external root certificates, so both guarantee secure communication. It sounds like a good weekend project, don't you think?

Installation and configuration

Given that Istio can be installed on many different platforms, the installation instructions may vary greatly. At the time of writing this article, I was impressed by some of the checks that required pre-installation features for Linkerd installation. Many times when I installed some Linkerd features in a shared Kubernetes cluster, I didn't know if I had the necessary permissions. For Linkerd,pre-check (or check-pre), check that you have permission to create the resources needed to create Kubernetes during installation.

Environment support and deployment model

This is a straightforward question about whether to choose a kubernetes or a non-Kubernetes installation. Linkerd2 is built based on kubernetes, at least for now, while Istio has received contributions from other companies hoping that istio will run in a non-kubernetes environment.

Considering multi-cluster deployment, objectively speaking, the explanation for it can be tricky. Technically, services on multiple different clusters (with different control planes) that share root CA certificates can communicate effectively.

Istio extends the above concept because it supports multiple clusters in different situations:

A single control plane can satisfy the network connection between different clusters and the IP addressing between pod.

Kubernetes API servers on multiple clusters can be accessed by using cluster border gateways (egress and ingress) with a single control plane.

In both cases, the cluster containing the control plane will become the SPOF (single point of failure) managed by mesh. In our world where a single cluster can be deployed on multiple available zones under the same region, this will no longer be a problem, but it still cannot be completely ignored.

Monitor and control

It can be said that the administrative console of Istio is a missing part. Kiali Observability Console does address some of the needs of some administrators for service mesh.

Kiali (kappa λ) is a Greek word for telescope, and it is clear from Kiali's website that it is intended to be a monitoring console, not just a Service Mesh management console.

The Linkerd console is not complete, but the community's decision to build a management dashboard is an advantage.

Linkerd failed to provide request tracking. If you want to view the request trace span in a non-intrusive manner, you must wait for Linkerd to implement this functionality. Istio takes advantage of the fact that Envoy supports the addition of tracking headers.

Users should be reminded that the application needs to be ready to forward the trace headers, and if not, the agent can generate a new trace IDS, which may inadvertently split a single request into multiple request spans and lose the necessary relevance between requests. Most development frameworks have the option to forward headers without requiring users to write a lot of code.

Policy management

Fans of Istio, please rejoice! Istio's policy management capabilities are impressive.

The project builds an extensible policy management mechanism that allows other technologies to integrate with Istio in many ways, see the "template" list below and some integration providers. You can think of "template" as an integration.

To highlight other policy types, Istio can also be applied to rating and limiting and provides out-of-the-box support for principal authentication. Linkerd users rely on the cluster ingress controller to provide rating and limiting.

For principal authentication, I have always thought that it should be delegated to the application. Remember the myth of # 4 distributed computing: the network is secure. Have a zero trust policy for this.

Istio's impressive policy management capabilities come at a price. Given its breadth, managing a wide range of options adds to already expensive operating costs.

The policy management component of Istio (Mixer) also adds significant performance, which we will discuss in more detail below.

Performance

Where is the comparison chart? Fortunately, just recently, I published two great blogs comparing the performance of Istio and Linkerd, and I quote some of these conclusions below:

For this combined workload, Istio's Envoy agent uses 50% more CPU than Linkerd. The control plane of Linkerd uses a small portion of Istio, especially when considering the "core" component.

-- Michael Kipper  -  Benchmarking Istio & Linkerd CPU (https://medium.com/@ihcsim/linkerd-2-0-and-istio-performance-benchmark-df290101c2bb)

And...

In this lab, both the Linkerd2-meshed and Istio-meshed settings experienced higher latency and lower throughput than the baseline settings. The delay in the Istio-meshed setting is higher than the delay observed in the Linkerd2-meshed setting. The Linkerd2-Meshed setting can handle higher HTTP and GRPC ping throughput than the Istio-Meshed setting.

-- Ivan Sim  -  Linkerd 2.0 and Istio Performance Benchmark (https://medium.com/@ihcsim/linkerd-2-0-and-istio-performance-benchmark-df290101c2bb)

Recognizing the increased processing time of Mixer, the Istio team is currently working on rewriting Mixer components: "Mixer will be rewritten with C++ and embedded directly into Envoy. There will no longer be any stand-alone Mixer services. This will improve performance and reduce operational complexity."

-Source Mixer V2 Design Document (https://docs.google.com/document/d/1QKmtem5jU_2F3Lh6SqLp0IuPb80_70J7aJEYu4_gS-s/edit)

Summary

Yes, Istio has more features than Linkerd2.3. This is good, and more features mean an enhanced ability to handle more complex and marginal use cases. This is not magical, and more features usually mean more configuration, potential resource utilization, and increased operating costs, so here are three suggestions:

If you don't know what 80% of the most common workloads look like, it will be difficult to choose a service grid. If you don't know these numbers, your business may not be ready to use the service grid. If you're just exploring, it's a different story.

If you plan to solve all possible current and future cases (often called comparison spreadsheet), then you will have a bad time. You are likely to get too much, which is true for any software you buy.

Blindly choosing one technology or another will make your life very bad. The hype can be strong, but remember, you're not hype about the business (unless you're really hype).

Try Istio and Linkerd! Solo SuperGloo is the easiest way.

I use SuperGloo because it is very simple to start two service grids quickly, and I hardly need to make any effort. We don't use it in production, but it's very suitable for such tasks. Each grid is actually two commands.

-- Michael Kipper  -  Benchmarking Istio & Linkerd CPU  -  Shopify (https://medium.com/@michael_87395/benchmarking-istio-linkerd-cpu-c36287e32781)

At Solo.io (https://www.solo.io/), we hope to facilitate your journey to service grid adoption. Solo SuperGloo our service Mesh orchestrator can install and manage popular service grid technologies with intuitive and simple commands. As pointed out above in Michael, installing Istio or Linkerd becomes an one-line activity. SuperGloo is more than that, it provides an abstraction on top of different service grid technologies, allowing consistent and repeatable operations on multiple grids. SuperGloo is completely open source, you can try it right now (https://supergloo.solo.io/).

This article is originally translated and published by Boyun Research Institute. Please indicate the source when reproduced.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.