Battle of the Kubernetes service meshes: Istio vs. Consul

The arrival of service meshes has made the job of facilitating (and regulating) communications between microservices a lot easier. Before Consul or Istio appeared in the Kubernetes ecosystem, running microservices in production wasn’t half as simple as deployment. While Kubernetes does a great job of abstracting infrastructure so that there is uniformity in deployment, uniformity during runtime still left a lot to be desired.

This is not only due to the ephemeral nature of containers, but also the fact that if not managed properly, these interprocess communications can get out of hand pretty quick. Additionally, the sheer scale and volume at which these services usually operate make the task of manually keeping track of them both daunting and unsustainable. That’s where service mesh technology steps in and abstracts away the complexities involved with controlling and monitoring traffic between microservices.

With a service mesh in place, microservices that usually rely on the network now have their own private intercom system to discover and communicate with each other.

The champion

Istio, which is one of the most widely used service meshes and is backed by Google, IBM, Lyft, Red Hat, Pivotal, and Cisco, provides Layer 7 features for both traffic routing and telemetry. Similar to how an SDN functions, Istio is split into a data plane and control plane where the data plane is made up of proxy sidecars and the control plane is further split into three components. Access policies can be configured for both Layer 7 and Layer 4 properties.

Istio vs. Consul

While the first component called Pilot helps users configure the data plane, the second component called Mixer that collects metrics and responds to queries from the data plane will soon be rewritten in C++ and directly embedded in Envoy to save on processing time. The third component called Citadel facilitates zero-trust environments based on service identity.

Signature moves

Istio differentiates itself from the crowd by giving users specific “intelligent” insights that would otherwise be humanly impossible. A good example is information related to how a percentage-based traffic split will affect users. While calculating all the possible permutations and combinations manually would be taxing, to say the least, Istio goes about it quite effortlessly.

Additionally, Istio is all about visibility and transparency, allowing you to actually understand the complexities of intra-service relationships. It’s platform-agnostic, so users can seamlessly manage traffic between microservices across an assortment of platforms. This is especially useful in multi-cloud or hybrid cloud setups that span across on-prem facilities and public clouds alike. It also ships with all Envoy’s built-in features like service discovery, load balancing, TLS termination, subset routing, gRPC proxies and health checks, as well as its own traffic management, security, observability, and integration capabilities.

The challenger

It’s common knowledge that the more components or “moving parts” your service mesh are made up of, the longer the processing time incurred and the lower the overall performance. While Istio integrated its Mixer component with Envoy to ease up on the resource requirements and improve performance, Consul takes things even further by including both the data and control plane in a single binary.

It accomplishes this by using an “agent-based” model where each node runs a client with a local cache that’s constantly updated by the server. This not only mitigates the need for any external communication but also allows for quick and effective changes to be made at the edge. It’s also an extremely simplistic and portable design, making it a true “full-mesh” service where APIs respond a lot quicker and where there are no centralized planes that could cause bottlenecks and adversely affect performance.

Freedom to plug

istio consul

Consul comes with a pluggable data plane that supports third-party proxies like Envoy. It also gives you the option, however, to use the built-in proxy that’s easier to use but comes with a significant performance trade-off. Different proxies are better at different applications and the ability to choose gives users the flexibility to deploy the proxy best suited to the task. This also expands capabilities quite a bit as you now essentially have a single binary that not only runs your service mesh but also integrates with powerful tools like Jenkins, Grafana, and Telegraf.

If third-party proxy support isn’t enough in terms of flexibility, applications can also “natively” integrate with the Connect protocol. Consul Connect is another “built-in” feature and uses Transport Layer Security (TLS) to provides service-to-service encryption, as well as authorization. The advantage of doing this is that while the performance overhead is negligible, all “Connect-native” applications can interact with other “Connect-capable” services, irrespective of whether they’re using a proxy or are also Connect-native.

The big fight

While Consul is a tempting option since it’s extremely lightweight and streamlined, a couple of drawbacks are the fact that it enforces authorization and identity only to Layer 4 though it does plan on adding Layer 7 features in the future. The pluggable data layer kind of makes up for this drawback though and users can use a proxy that supports the required Layer 7 features. Also, while both services support TLS, only Istio supports native certificate management. This means unlike in Consul where it’s all managed for you, Istio lets you manually change or revoke certificates in case they’re compromised.

Istio, being the more popular of the two, comes with a much bigger community and a wealth of experience encapsulated in it. On the other hand, however, the fact that there’s no central control plane in Consul allows users to make quick changes at the edge without having to go through a central service like Mixer in Istio. Consul also lets you do interesting things like keep half your microservices in Kubernetes and the other half in virtual machines. This is why in terms of sheer versatility and relevance in terms of what enterprise customers really need right now, Consul is a pretty good bet. It’s basic architectural design also makes it a lot more scalable than the other service meshes available right now. It also has the advantage that no additional systems need to be installed to use Consul. This architecture enables Consul to be easily installed on any platform, including directly on bare metal.

Service meshes sound a lot like SDNs with their data and control planes, but the big difference is that they’re designed for volatile, ephemeral environments and geared towards “intelligent” networking with a host of supporting features. Both Istio and Consul have their pros and cons but the truth is that they’re both equally important when you look at the Kubernetes ecosystem as the big picture. The point is to have a solution for everyone so if you’re looking for a feature-rich experience with loads of support, walkthroughs and other people with the same problems as you, Istio is the way to go. If resources are your priority, however, Consul is the way to go, or at least until someone comes up with a “flyweight” mesh that runs on nothing and uses no resources.

Featured image: Shutterstock / TechGenix photo illustration

About The Author

1 thought on “Battle of the Kubernetes service meshes: Istio vs. Consul”

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top