---
title: "Service Mesh Deep Dive: Istio vs. Linkerd"
description: "Trying to figure out service mesh? This article compares Istio and Linkerd on Kubernetes, looking at how they handle traffic, security, and more. Find out which one might be the best fit for you."
author: "Mohammad Abu Mattar"
canonical: https://mkabumattar.com/blog/post/service-mesh-istio-vs-linkerd
---

# Service Mesh Deep Dive: Istio vs. Linkerd

So, you're diving into the world of cloud-native stuff, huh? Managing all those **microservices** can get pretty tricky. As you break your apps into smaller, independent pieces, making sure they talk to each other reliably, securely, and in a way you can actually see what's going on becomes super important. That's where a **service mesh** comes in. Think of it as a special layer in your setup that helps your **microservice** apps communicate better. It basically looks after the network traffic between them, making things run smoother and keeping them safe by watching, redirecting, and controlling access when needed. This layer is often built right into an application to manage how requests get to other services.

There are tons of good reasons to use a **service mesh** with **microservices**. One big one is better **observability**. You get really detailed, up-to-the-minute info on what's happening on your network. This includes distributed tracing, which lets you see the whole journey of a request as it hops between services, and real-time metrics and logging, giving you a deep understanding of how your **microservices** are behaving and if they're healthy. Better **security** is another huge plus. A **service mesh** can beef up your security in lots of ways, giving you a central place to set rules that apply everywhere. Things like mutual TLS (mTLS) encryption, authentication, and authorization make sure your services are talking to each other securely. Plus, a **service mesh** gives you really fine control over **traffic management**, with features like smart request routing, load balancing, and support for those cool canary deployments. This means you can really control how requests are handled. Finally, a **service mesh** makes your system more resilient. It adds features for things like circuit breaking, retries, and timeouts, which helps your apps handle problems gracefully and stops one issue from taking down everything else. This also means you don't have to put all that communication logic directly into your apps, which makes them easier to manage and scale.

But, if you're trying to manage communication in a **microservices** setup without a **service mesh**, things can get complicated fast as you add more services. Just keeping an eye on how each service is performing becomes a headache. Trying to coordinate and maintain important stuff like mTLS and access control across lots of services can be a real challenge to do consistently. And in a big **microservices** world, figuring out where a problem started can be a nightmare. Without a dedicated layer, developers might end up putting communication logic directly into each **microservice**, which can lead to inconsistencies and more work overall.

The main thing a **service mesh** does is take away the complicated parts of network communication from your individual **microservices**. By putting things like security, observability, and traffic management in one central place, it makes everything more consistent, cuts down on duplicated effort, and makes it easier to run a large number of connected services. As you have more and more **microservices**, the benefits of having a **service mesh** really start to shine. While you might be able to handle basic stuff like retries or some security in each service when you only have a few, trying to manage all that across a growing number of services can get crazy complicated. That's when a **service mesh** becomes the much better way to handle communication between your services.

## **Diving Deep into Istio:**

### **What is Istio and What Problems Does It Solve?**

**Istio** is a really popular open-source **service mesh** that plays well with your existing distributed applications. Its main goal is to give you a consistent and complete way to connect, secure, control, and see what's happening with your **microservices**. It came about from a collaboration between Google, IBM, and Lyft and it's become a key tool for managing deployments, making things more reliable, and boosting **security** in Kubernetes environments.

The big problems **Istio** tries to solve are all about the complexities of managing **traffic management**, **security**, and **observability** when you've got a lot of **microservices**. Without something like **Istio**, making sure you're applying the same rules across different ways of communicating and different environments can be really tough. Plus, doing advanced deployment stuff like canary releases, A/B testing, and even intentionally causing problems to test your system often takes a lot of manual work and can be inconsistent across different services. **Istio** steps in to make all this easier, giving you one place to manage these important parts of running **microservices**. It lets you enforce things like authentication, encryption, and other crucial rules consistently across all your applications, no matter what technology they're using. And **Istio** makes it simpler to do those sophisticated release workflows, giving you the tools to manage traffic flow and make sure your deployments go smoothly and are well-controlled.

### **How Does Istio Work Under the Hood? (Architecture Explained)**

The way **Istio** is put together is based on a clear separation of concerns. It's divided into two main parts: a data plane and a control plane.

_Istio's control plane and data plane_

The **data plane** is made up of a bunch of smart proxies, specifically Envoy proxies, that are deployed as sidecars right alongside each **microservice** instance. These Envoy proxies act like go-betweens, intercepting all the network communication coming in and going out of their associated **microservice**. Envoy, which is a really fast proxy written in C++, is responsible for handling all the network traffic. It's the only part of **Istio** that actually touches the data plane traffic directly. Putting these proxies in as sidecars is a smart move because it lets **Istio** gather a ton of information about how traffic is behaving. This info is then used to enforce the rules you've set up and collect valuable data about what's happening.

The **control plane** in **Istio**, which is now mostly handled by a single component called Istiod, has the important job of managing and configuring these Envoy proxies so that traffic gets routed intelligently. Istiod comes as one single package and includes everything needed for service discovery, managing configurations, and handling certificates. It uses the Envoy API (called xDS) to talk to the sidecar proxies, sending them the configurations they need to control how they behave. Before, the control plane had separate parts like Pilot (for traffic management), Citadel (for security), and Galley (for configuration management), but they've all been brought together into Istiod to make things simpler.

Choosing Envoy as the data plane proxy gives **Istio** a really powerful and well-known proxy that has a big and active community behind it. Envoy's many features are a big reason why **Istio** is so capable when it comes to traffic management, security, and observability. However, it's worth noting that because Envoy does so much, it can also use more resources compared to proxies that are more specialized. This trade-off between having lots of features and being resource-efficient is something to think about when you're comparing **Istio** to other **service mesh** options.

### **How Does Istio Handle Traffic in Your Microservices? (Traffic Management Features)**

**Istio** gives you a great set of **traffic management** features that let you control how traffic and API calls flow between your **microservices** without having to change any of your application code. This is a really powerful capability, and it's all managed through a few key configuration tools:

Virtual Services are super important for defining how incoming requests get routed to specific services within your **service mesh**. They hide the underlying service instances, which lets you set up sophisticated routing rules based on things like the content of the request, headers, or even where the request came from. This is how you can do things like percentage-based traffic splitting for canary deployments and A/B testing, where you send a small part of your user traffic to a new version of a service while most users still use the old, stable version.

Destination Rules, on the other hand, are about setting up policies that apply to traffic that's going to specific services. With these rules, you can define how load balancing should work (like round-robin or sending requests to the service with the fewest current connections), manage connection pooling to make better use of resources, and set up circuit breakers to make your system more resilient by preventing one failing service from taking down others.

Gateways are essential for managing traffic as it comes into and goes out of your **service mesh**. They act as entry points, letting you configure things like ports, virtual host routing, TLS settings for secure communication, and even automatically redirecting HTTP connections to HTTPS to make sure everything is secure.

Finally, Service Entries give you a way to include services that are running outside of your **mesh**. This is really useful when you need to manage traffic to external APIs or older systems, letting you apply **Istio**'s **traffic management** rules to these external dependencies as well.

The comprehensive set of **traffic management** tools that **Istio** offers gives you a lot of control over how traffic moves within your **mesh** and how it interacts with services outside of it. This means you can do complex deployment strategies, like gradually rolling out new features with canary deployments or running controlled experiments with A/B testing. Plus, being able to route requests based on specific criteria like headers or paths lets you do some pretty sophisticated traffic steering. To make your applications more resilient, **Istio** makes it easier to set up retries and timeouts to handle temporary issues, as well as circuit breakers to stop overloaded services from affecting the whole system. And **Istio** even supports traffic mirroring, which lets you duplicate live traffic to a test or monitoring service without affecting the main flow of requests. This gives you valuable insights into how a service handles certain requests. While all these features are great for applications with complicated routing needs, they also mean that **Istio** can be a bit complex to configure.

### **Keeping Your Services Secure with Istio**

**Istio** really focuses on **security**, giving you a strong framework with features like strong identity, powerful policy enforcement, transparent TLS encryption, and complete authentication, authorization, and audit (AAA) tools to keep your **microservices** and their data safe.

A key part of **Istio**'s **security** approach is that it automatically enforces mutual TLS (mTLS) for all communication between services by default. This makes sure that all communication within your **service mesh** is both encrypted and mutually authenticated, creating a secure foundation for how your services interact. **Istio** gives you two main ways to handle authentication: transport authentication, which uses mTLS to verify the identity of the client making a direct connection, and origin authentication, which uses JSON Web Tokens (JWT) to verify the identity of the original end-user or device making the request.

The mTLS is invisible to your application code. The app just makes a plain call to localhost; the sidecars handle the handshake, identity check, and encryption between pods. This holds for both Istio and Linkerd:

_How a request gets encrypted between sidecars_

To make things even more secure, **Istio** offers comprehensive authorization policies that let you control who can access your services based on the verified identity of the client. You can set up these policies to have really fine-grained access control, making sure only authorized services can talk to each other. The management of the cryptographic keys and certificates, which is crucial for mTLS, is handled by Citadel (now part of Istiod). Citadel automates the process of creating, distributing, and rotating these certificates, which makes it much easier to manage secure communication within your **mesh**.

**Istio**'s overall goal with **security** is to create a zero-trust network environment. This security model works on the idea of "never trust, always verify," making sure every communication request is authenticated and authorized, no matter where it comes from inside or outside your cluster. By putting these strong **security** features at the infrastructure level, **Istio** lets developers focus on their application's main purpose without having to worry about implementing complex security measures in each individual **microservice**. This simplifies security management and makes sure you have a consistent security approach across your whole **microservices** setup.

### **Understanding Your System: Observability with Istio**

One of the big strengths of **Istio** is its complete **observability** features, which give you detailed insights into how all the service communications within your **mesh** are behaving. This rich data helps you troubleshoot problems, maintain your applications, and make them run better without needing to add any extra code to your services.

**Istio** generates three main types of data to give you this full picture: metrics, distributed traces, and access logs. Metrics are collected based on the four key things you usually want to monitor: latency, traffic, errors, and saturation. **Istio** uses the Envoy proxies to gather these important performance indicators and works well with popular monitoring systems like Prometheus and visualization tools like Grafana. Distributed tracing lets you follow individual requests as they go through the different **microservices** in your system. This gives you an end-to-end view of how requests flow and how your services depend on each other, which helps you understand complex interactions and find performance bottlenecks. **Istio** supports working with distributed tracing backends like Jaeger, Zipkin, and OpenTelemetry. Finally, **Istio** can create detailed access logs for all the traffic that goes into and out of the services within your **mesh**. These logs give you a complete record of each request, including information about where it came from and where it went, letting you audit how your services are behaving at a very detailed level.

The **observability** features in **Istio** provide a ton of data that's really important for understanding the health, performance, and overall behavior of your **microservices** within the **mesh**. This helps your teams proactively find potential issues, quickly figure out what's going wrong when there's a problem, and make informed decisions to improve the performance of your distributed systems. The fact that it works so well with widely used open-source tools for metrics, tracing, and logging makes **Istio**'s **observability** features even more valuable, letting teams use their existing monitoring setup and knowledge.

## **Exploring Linkerd:**

### **What is Linkerd and Why is it Popular?**

**Linkerd** is a lightweight and straightforward **service mesh** that's specifically designed for Kubernetes. Created by Buoyant **Linkerd** has become a CNCF graduated project, which means it's mature and widely used in the cloud-native world. It's popular because it's simple, performs really well, and is easy to use.

One of the main reasons people like **Linkerd** is that it doesn't require as much overhead to run compared to other **service mesh** options. It has a faster and lighter data plane, which means lower latency and it doesn't use up as many resources. Plus, **Linkerd** really focuses on **security**, with automatic mutual TLS (mTLS) turned on by default, so you get secure communication between your services right out of the box. This "security by default" approach, along with how easy it is to install and set up, makes **Linkerd** a great choice for organizations that want to get into **service meshes** without a lot of complexity. Its Kubernetes-native design means it works seamlessly with the most popular platform for managing containers.

### **Linkerd's Architecture: Simplicity and Performance**

**Linkerd**'s architecture is all about being simple, with a Control Plane and a Data Plane.

_Linkerd's control plane and data plane_

The **data plane** in **Linkerd** is built on top of really lightweight micro-proxies called Linkerd2-proxy. These proxies, which are written in the memory-safe language Rust, are deployed as sidecar containers right next to each service instance within the same Kubernetes pod. Unlike general-purpose proxies, Linkerd2-proxy is specifically designed and optimized for the **service mesh** use case, focusing on performance and using very few resources. These proxies transparently handle all the TCP traffic going to and from their associated services.

The **control plane** of **Linkerd** runs within a dedicated Kubernetes namespace. It's designed to be modular and simple. Some of the key parts of the control plane include the Destination service, which handles service discovery, policy management, and getting service profiles; the Identity service, which acts like a TLS Certificate Authority, issuing certificates for mTLS; and the Proxy Injector, which automatically adds the Linkerd2-proxy sidecar to your pods.

**Linkerd**'s design is based on three main ideas: keep it simple, use minimal resources, and "just works". This focus on simplicity and performance, especially by using a proxy built specifically for the job in Rust, is what makes **Linkerd** different from other **service mesh** options that use more general-purpose proxies like Envoy. This focused approach helps **Linkerd** achieve its goals of using fewer resources and potentially performing better in certain situations.

### **Managing Traffic Efficiently with Linkerd**

**Linkerd** offers a set of essential **traffic management** features that are designed to be efficient and easy to use. While it might not have as many features as some other **service mesh** solutions, **Linkerd** provides the core functionalities you'll need for most common scenarios.

Some of the key **traffic management** capabilities in **Linkerd** include Layer 7 load balancing for HTTP and gRPC traffic, which automatically spreads requests across all the available service endpoints. It also offers Layer 4 load balancing for other TCP-based traffic. To make your applications more reliable, **Linkerd** provides features for retries and timeouts for HTTP and gRPC requests, which helps the system handle temporary failures gracefully. For doing progressive deployments, **Linkerd** supports Traffic Split, which lets you do canary releases and blue/green deployments by gradually shifting a portion of your traffic to different versions of a service. Dynamic request routing lets you route individual HTTP requests based on their specific properties. Plus, **Linkerd** gives you visibility and control over traffic leaving your Kubernetes cluster through the EgressNetwork Custom Resource Definition (CRD). To protect your services from getting overwhelmed, **Linkerd** offers rate limiting capabilities. Finally, Service Profiles let you configure retries, timeouts, and collect metrics for specific routes, giving you more granular control over **traffic management**.

While **Linkerd** provides a solid set of basic **traffic management** features, it's worth noting that some comparisons suggest **Istio** might offer a more comprehensive and feature-rich set of capabilities in this area. For organizations with basic to intermediate **traffic management** needs, **Linkerd**'s efficient and straightforward features are often enough. However, if you have more complex scenarios that require advanced routing rules or very fine-grained control, **Istio**'s broader feature set might be more appealing. **Linkerd** works well with existing ingress controllers, using their capabilities to manage external traffic coming into your cluster.

### **Securing Communications with Linkerd**

**Linkerd** really focuses on **security**, with automatic mutual TLS (mTLS) turned on by default for all TCP traffic between pods that are part of the **mesh**. This feature works right out of the box, making sure all communication within your **service mesh** is automatically encrypted and mutually authenticated. This gives you a secure way for your services to talk to each other without needing to do any manual setup.

To make things even more secure, **Linkerd** offers authorization policies that let you control what kind of traffic is allowed to your meshed pods. With these policies, you can restrict communication to specific services or even particular HTTP routes within a service. The Identity service in **Linkerd**'s control plane acts as the main TLS Certificate Authority, responsible for creating and managing the certificates used for mTLS. This automated certificate management makes it easier to maintain secure communication within your **mesh**.

One of the things that makes **Linkerd** stand out in terms of **security** is that it uses the Rust programming language for its data plane proxy, Linkerd2-proxy. Rust's memory safety features help prevent many common memory-related security problems that can affect proxies written in languages like C++. This design choice contributes to **Linkerd**'s reputation as a **service mesh** that puts security first. The automatic mTLS and the secure foundation provided by Rust make **Linkerd** a really attractive option for teams that want to easily secure their **microservices** with minimal setup.

### **Getting Visibility into Your Services with Linkerd**

**Linkerd** provides a complete set of **observability** tools that are designed to automatically measure and report on how your applications are behaving within the **service mesh**. These features require very little, if any, configuration, making it easy for developers and operators to get insights into their distributed systems.

**Linkerd** automatically records top-level metrics, often called "golden metrics," for HTTP, HTTP/2, and gRPC traffic. These metrics include things like how many requests are happening, the success rate, and how long requests are taking, giving you a good overview of your service health and performance. Plus, **Linkerd** also captures TCP-level metrics for other types of traffic. You can see these metrics at different levels of detail, including per service, per pair of services communicating, and even per route when you use Service Profiles.

To help you see and understand this data, **Linkerd** offers a built-in dashboard and command-line interface (CLI) tools. The dashboard gives you a user-friendly visual representation of your **mesh**'s health and performance, while the CLI lets you quickly check metrics and the overall status of your services. What's more, **Linkerd** works seamlessly with popular open-source monitoring and visualization tools like Prometheus and Grafana through its Viz extension. This means you can use your existing monitoring setup with **Linkerd**. For a more detailed, real-time look at individual requests, **Linkerd** provides a feature called the "tap API" that lets you sample requests on demand. This allows operators to watch the live traffic flowing between services, which is really helpful for debugging and troubleshooting. The focus on automatic and easily accessible **observability** data in **Linkerd** makes it easier to understand and effectively manage your **microservices** within the **mesh**.

## **Istio vs. Linkerd: A Detailed Comparison:**

_Istio vs. Linkerd at a glance_

| **Feature**        | **Istio**                             | **Linkerd**                              |
| ------------------ | ------------------------------------- | ---------------------------------------- |
| Architecture       | Feature-rich, Envoy proxy             | Simple, Linkerd2-proxy (Rust)            |
| Performance        | Good, getting better                  | Excellent, low latency, low resource use |
| Traffic Management | Lots of options, very flexible        | Essential features, efficient            |
| Security           | Comprehensive, very detailed          | Strong, automatic mTLS by default        |
| Observability      | Rich metrics, tracing, logging        | Key metrics, tracing, logging            |
| Ease of Use        | More complex, but improving           | Simple, easy to install and set up       |
| Multi-Cluster      | Robust support                        | Good support                             |
| VM Support         | Yes                                   | No (Kubernetes only)                     |
| Community          | Large, lots of different contributors | Growing, focused on simplicity           |

**Istio** and **Linkerd** take different paths when it comes to building a **service mesh**. **Istio** goes for a "everything but the kitchen sink" approach, giving you a wide range of features and lots of ways to customize things, all built on top of the powerful Envoy proxy. This power comes with a bit of a trade-off: it can be more complex and use more resources. It's designed to work on different platforms, not just Kubernetes, but also virtual machines.

On the other hand, **Linkerd** keeps things minimal, focusing on simplicity, performance, and being easy to use. Its lightweight design, using the purpose-built Linkerd2-proxy written in Rust, generally leads to lower latency and uses significantly fewer resources, especially in the data plane. While **Istio**'s performance has gotten better in recent versions, **Linkerd** often shows better efficiency when resources are tight.

When it comes to features, **Istio** offers a broader and more advanced set of capabilities for **traffic management**, including support for virtual machines and more detailed control over routing and policy enforcement. Both provide strong **security** with mTLS, but **Istio** gives you more options for managing policies and integrating with other systems. For **observability**, both give you lots of data through metrics, tracing, and logging, and they both work with common platforms.

**Linkerd** really shines when it comes to being easy to use and install. It has a simpler setup process and a lower learning curve, especially if you're new to **service meshes**. While **Istio** has been working on making things easier, it's still more complex because it has so many features.

**Istio** has a larger and more established community with contributions from big tech companies, which means there's a wider ecosystem and more readily available support. **Linkerd** has a growing and active community that's known for its focus on simplicity and direct interaction.

Choosing between **Istio** and **Linkerd** often comes down to what's more important to you: having a comprehensive set of features or having something that's easier to run. If your organization has complex needs and dedicated resources, **Istio**'s extensive feature set might be the way to go. But if you're prioritizing performance, ease of use, and a less complicated way to get started with **service meshes**, especially if you're mostly working with Kubernetes, then **Linkerd** is a really good option.

## **Frequently Asked Questions (FAQ) about Service Mesh, Istio, and Linkerd**

> **What's the main job of a service mesh?**

A service mesh acts like a dedicated helper for your microservices, managing and securing how they talk to each other. It makes things more reliable, secure, and easier to see what's going on.

> **How does a service mesh make my application more secure?**

It sets up security rules, handles who can talk to whom, and encrypts communication, making sure your services are talking to each other safely.

> **What are the big differences between Istio and Linkerd?**

Generally, Linkerd is lighter, faster, and simpler to use, while Istio has more features and works on more platforms.

> **How does a service mesh affect how well my application runs?**

By making communication between services more efficient, a service mesh can actually make your application run faster and better overall. However, it can also add a little bit of extra work because of the sidecar proxies.

> **Can I only use a service mesh with Kubernetes?**

No, while some are designed just for Kubernetes (like Linkerd), others like Istio can be used in other environments too.

> **Do all service meshes use a sidecar?**

Not necessarily. Using a sidecar proxy is a common way to do it, but there are also newer approaches that don't use sidecars.

> **What's the difference between a service mesh and an API Gateway?**

An API Gateway usually manages traffic coming into your application from the outside (north-south), while a service mesh focuses on traffic between your microservices inside your system (east-west). They often work together.

> **What are some real-world examples of using Istio?**

Companies use it to make their e-commerce sites more reliable when there's a lot of traffic, to secure communication between microservices in financial services, and to safely roll out new features in SaaS applications.

> **What are some real-world examples of using Linkerd?**

People use it to improve how well their microservices run and to see what's going on (like loveholidays), to manage traffic efficiently, and to provide security with mTLS for different kinds of organizations.

> **Is it worth learning about service mesh?**

Definitely, especially if you're dealing with a lot of microservices and need better control over how they interact.

> **Why are some companies switching from Istio to Linkerd?**

Often it's because Istio can be complex and require a lot of resources to run, so companies are looking for Linkerd's simplicity and lower resource usage as an easier alternative.

> **What are some of the challenges of using a service mesh?**

Some challenges include the initial complexity of setting it up, the learning curve, the possibility of a slight performance hit, and the work it takes to manage the service mesh itself.

## **Making the Right Choice: When to Use Istio vs. Linkerd**

Deciding between **Istio** and **Linkerd** really depends on what your organization needs and what your priorities are.

Think about using **Istio** if you need a lot of features to handle complicated **traffic management** and **security** situations. If you're using virtual machines along with Kubernetes, **Istio**'s ability to work on different platforms makes it a good choice. But keep in mind that it can be more complex, so you'll want to make sure you have a team that knows how to manage it well. **Istio** is often a favorite for big, enterprise-level setups with advanced needs.

On the other hand, **Linkerd** is a great option when keeping things simple, having good performance, and being easy to use are most important. If you're mainly working with Kubernetes and you need a lightweight **service mesh** that automatically gives you mTLS and essential **observability** and **traffic management** features without a lot of extra work, **Linkerd** is a strong contender. It's especially good for smaller teams or organizations that are new to **service meshes** and want something less complicated to start with, particularly if performance and low resource usage are critical.

The best way to decide is to think about how familiar your team is with cloud-native technologies and carefully consider what your **microservices** setup really needs. Starting with the simpler **Linkerd** can be a good move if you're new to **service meshes**, while **Istio** might be something to look at for more advanced needs when you have the resources to manage it.

## **Conclusion: Key Takeaways and Future Trends in Service Mesh**

To wrap things up, both **Istio** and **Linkerd** are powerful **service mesh** tools, and each has its own strengths and weaknesses. **Istio** offers a feature-rich and highly customizable platform that's good for complex enterprise environments, while **Linkerd** provides a simpler, faster, and easier-to-manage solution, especially for Kubernetes.

**Service meshes** have become really important for dealing with the complexities of modern **microservices** setups, giving you essential **security**, **observability**, and **traffic management** capabilities. As the cloud-native world keeps changing, there are a few trends shaping the future of **service mesh** technology. Efforts to create standards like the Service Mesh Interface (SMI) are aiming to make different **mesh** implementations work better together. The development of architectures that don't use sidecars promises to reduce the extra work that comes with traditional **service meshes**. And there's a constant push to improve the performance and make it easier to adopt and run **service meshes** so more people can use them.

## **References**

1. [What is a Service Mesh? - VMware Glossary](https://www.vmware.com/topics/service-mesh)
2. [What is service mesh and why do we need it? - Dynatrace](https://www.dynatrace.com/news/blog/what-is-a-service-mesh/)
3. [What is Service Mesh? - AWS](https://aws.amazon.com/what-is/service-mesh/)
4. [Istio - Service Mesh to provide Traffic Control, Security and Observability for Kubernetes - NTT Data](https://www.nttdata.com/global/en/insights/focus/2024/istio-service-mesh-to-provide-traffic-control)
5. [Istio / Traffic Management](https://istio.io/latest/docs/concepts/traffic-management/)
6. [Security - Istio](https://istio.io/latest/docs/concepts/security/)
7. [Istio / Observability](https://istio.io/latest/docs/concepts/observability/)
8. [Introduction to the Linkerd Service Mesh | CNCF](https://www.cncf.io/blog/2023/04/06/introduction-to-the-linkerd-service-mesh/)
9. [Linkerd Architecture: Components and Design Principles - Solo.io](https://www.solo.io/topics/linkerd/linkerd-architecture)
10. [Linkerd: The only service mesh designed for human beings](https://linkerd.io/)
11. [Linkerd vs Istio, a 2024 service mesh comparison - Buoyant.io](https://buoyant.io/linkerd-vs-istio)
12. [Service Mesh Comparison: Istio vs. Linkerd - EaseCloud](https://easecloud.io/blog/kubernetes/istio-vs-linkerd-service-mesh-comparison/)
13. [Istio vs Linkerd: The Best Service Mesh for 2023 - IMESH](https://imesh.ai/blog/istio-vs-linkerd-the-best-service-mesh-for-2023/)
14. [Service Mesh Review: Linkerd, Kuma, Istio & Consul | mkdev](https://mkdev.me/posts/the-best-service-mesh-linkerd-vs-kuma-vs-istio-vs-consul-connect-comparison-cilium-and-osm-on-top)
15. [Frequently Asked Questions - Linkerd](https://linkerd.io/faq/)