Comparing Service Meshes: Istio, Linkerd and Consul Connect
The use of microservice-based architectures has skyrocketed in the past few years, highlighting their ability to make applications more scalable, portable, and resilient than their monolithic predecessors. But the volatile and ephemeral environments that microservices encourage can make networking inherently problematic.
It can be difficult to establish trust between microservices, slowing down operations. Canary deployments, the idea of rolling out releases to a subset of users or servers, can be complicated. Likewise, rollbacks, attribute-based routing, end-to-end encryption, metrics collection, and rate limiting can all be difficult. There are still challenges with microservices that must be ironed out. These are operations that application developers don’t want to think about but still depend on.
Service meshes have arisen as the solution to the networking problems that microservices present. A service mesh is the substrate between different microservices that makes their connectivity possible. This networking is then supplemented with a host of other features, such as service discovery, authentication and authorization, monitoring, tracing, and traffic shaping. Service meshes can be a critical part of microservice-based architectures, and their ecosystem is growing and thriving as a result.
I presented ‘A Comparison of Service Mesh Options’ at the recent North American Open Source Networking Days that took place on October 31st, 2018 in Ottawa. I focused on Istio, Linkerd, and Consul Connect, three service meshes that I believe are among the most interesting. This blog post is based on that discussion.
Istio was open sourced by Google, IBM, and Lyft in May, 2017. Having been one of the earlier service meshes, it’s very rich in features. Istio is designed to connect, secure, and monitor microservices. Its features include automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic. It offers fine-grained control of traffic behaviour, offering rich routing rules, retries, failovers, and fault injection. Istio has a pluggable policy layer and configuration API that supports access controls, rate limits, and quotas. Automatic metrics, logs, and traces of all traffic within a cluster are provided, and this includes cluster ingresses and egresses. Istio has strong identity-based authentication and authorization policies. It enables secure service-to-service communication
Istio uses Envoy, a high-performing proxy developed in C++. Envoy proxies are deployed in the sidecar pattern, which prevents communication between microservices from altering the application code. Containers do not know when proxies have been attached to them, but receive visibility because of them. Envoy proxies provide dynamic service discovery, load balancing, TLS termination, HTTP/2 and gRPC proxies, circuit breakers, health checks, staged rollouts with %-based traffic split, fault injection, and rich metrics. Envoy has graduated as a CNCF project and will continue to evolve.
Istio’s control plane sits above the proxies and is comprised of three components. Pilot is the core component used for traffic management and configures all Envoy proxy instances. Mixer, a platform-independent component, enforces access control and usage policies across the service mesh. It also collects and analyzes telemetry reports. Citadel, which used to be called Istio-Auth, is the service mesh’s Certificate Authority and Policy enforcer. It provides service-to-service and end-user authentication with built-in identity and credential management. Citadel can be used to upgrade unencrypted traffic in the service mesh and enforce policies based on service identity rather than network controls.
There are a few more components that are an integral part of Istio. Gateway, its load balancer, operates at the edge of the service mesh and receives incoming and outgoing HTTP/TCP connections. VirtualServices define sets of traffic routing rules to apply when hosts are addressed. Each routing rule defines matching criteria for traffic of specific protocols that, when matched, are sent to a named destination service defined in the registry. DestinationRules define policies that apply to traffic intended for services that have already been routed by specifying configuration for load balancing, connection pool size, and outlier settings that detect and evict unhealthy hosts from the load balancing pool.
Linkerd began as a network proxy (v 1.0) for enabling service meshes. It merged with Conduit in September, 2018 to form Linkerd 2.0, which was recently made generally available. This version update transformed the project from a cluster-wide service mesh to a composable service sidecar. Linkerd is designed to be a lightweight service mesh that can be placed on top of any existing platform. It has very simple installation and CLI tools and doesn’t require a platform admin to be used. Linkerd doesn’t offer a rich array of features, but is simple. It is an easy service mesh that can be ideal for organizations that aren’t operating vast amounts of microservices and need to implement service meshes quickly and with minimal effort.
Linkerd’s proxy is small and lightweight and written in Rust. It is deployed in a sidecar pattern and can do end-to-end encryption and automatic proxy injection but lacks complex routing and tracing capabilities. Within the control plane, the Controller consists of multiple containers (including public-api, proxy-api, destination, tap) that provide most functionalities. The Web Deployment is the dashboard. Linkerd uses Prometheus, to expose and store metrics. A Prometheus instance has been configured to work specifically with data generated and deployed within the Linkerd service mesh. The Grafana dashboard renders and displays dashboards that can be reached from the Linkerd dashboard itself.
To install, inject, and inspect Linkerd’s service mesh, use the commands below:
Consul Connect provides secure service-to-service communication with automatic TLS encryption and identity-based authorization. It emphasises service discovery and service identity management. Like Istio, it uses the Envoy proxy and the sidecar pattern.
Consul Connect is an extension of Consul, a highly available and distributed service discovery and KV store. Consul Connect adds service mesh capabilities and was created in July, 2018 by HashiCorp. As an extension of Consul, Consul Connect can synchronize Kubernetes and Consul services. Likewise, Consul Connect offers integrations with Vault for certificate and secret management, further extending the service discovery provided by Consul.
Consul Connect has interesting and unique capabilities when implementing multi-cluster workloads or when working with a heterogeneous infrastructure. Connect is able to replicate intentions, a security policy implementation, between different clusters in order federate trust and ensure the persistence of the security model. These features are especially useful when workloads span multiple kubernetes clusters, or when building DR and failover scenarios.
Istio, Linkerd, and Consul Connect all have their benefits that may or may not match your technology stack’s requirements. Istio is the most advanced service mesh available, but can be complex and difficult to manage. Linkerd offers a service mesh that is more straightforward but less flexible. Consul Connect offers integrations with other HashiCorp solutions, namely Consul and Vault. As the service mesh ecosystem continues to grow, we can expect to see more features and solutions become generally available in the future.
To learn more about implementing service mesh solutions as part of a wider DevOps practice, sign up for one our DevOps workshops, and be sure to check out my talk on Comparing Service Mesh Solutions at the Linux Foundation’s North American Open Networking Summit, April 3-5.
Read our white paper, ‘A Checklist for your Cloud Migration Strategy’ to learn how to analyze your networking and other parts of your technology stack before embarking into the cloud.