Chapter 4. Customization and Integration

How do I fit a service mesh into my existing infrastructure, operational practices and observability tooling?

Some service meshes such as Conduit (soon to be Linkerd) are not designed to be customized; rather, they aim to focus on out-of-the-box functionality and ease of deployment. Istio is an example of a service mesh designed with customizability in mind. Its extensibility comes in two primary forms: swappable sidecar proxies and telemetry/authorization adapters. Consul’s Connect is intended to be displaced as needed, as well.

Customizable Sidecars

Within Istio, though Envoy is the default service proxy sidecar, you can choose another service proxy for your sidecar. Although there are multiple service proxies in the ecosystem, outside of Envoy, only two have currently demonstrated integration with Istio: Linkerd and NGINX. Conduit is not currently designed as a general-purpose proxy; instead, it is focused on being lightweight, placing extensibility as a secondary concern by offering extension via gRPC plug-in. Consul uses Connect as the default proxy embedded into the same binary. Operating at Layer 4, Connect isn’t meant to compete on features or performance with dedicated proxy solutions, but enables third-party proxies to integrate to provide the data plane with Consul operating as the control plane. As a control plane, Consul integrates with many data-plane solutions including Envoy, HAProxy, NGINX, and exposes an API for integration with hardware load balancers like those from F5.

Why use another service proxy?

Linkerd
Use this if you’re already running Linkerd and want to begin adopting Istio control APIs like CheckRequest, which is used to get a thumbs-up/thumbs-down before performing an action.
NGINX
Based on your operational expertise and need for battle-tested proxy, you might select NGINX. You might be looking for caching, web application firewall (WAF) or other functionality available in NGINX Plus, as well.
Connect
You might choose to deploy Connect based on ease of deployment and simplicity of needs.
Note

I hear talk of Huawei’s CSE Mesher considering integrating with Istio as an alternative to Envoy, but I consider its likelihood low.

The arrival of choice in service proxies for Istio has generated a lot of excitement. Linkerd’s integration was created early in Istio’s 0.1.6 release. Similarly, the ability to use NGINX as a service proxy through the nginMesh project (see Figure 4-1) was provided early in Istio release cycle.

Note

You might find this article on how to customize an Istio service mesh and its adjoining webcast helpful in further understanding Istio’s extensibility with respect to swappable service proxies.

Without configuration, proxies are without instructions to perform their tasks. Pilot is the head of the ship in an Istio mesh, so to speak, keeping synchronized with the underlying platform by tracking and representing its services to istio-proxy. istio-proxy contains the proxy of choice (e.g. Envoy). Typically, the same istio-proxy Docker image is used by Istio sidecar and Istio ingress gateway, which contains not only the service proxy but also the Istio Pilot agent. The Istio Pilot agent pulls configuration down from Pilot to the service proxy at frequent intervals so that each proxy knows where to route traffic. In this case, nginMesh’s translator agent performs the task of configuring NGINX as the istio-proxy. Pilot is responsible for the life cycle of istio-proxy.

Example of swapping proxies—Istio + nginMesh.
Figure 4-1. Example of swapping proxies—Istio + nginMesh.

Extensible Adapters

Istio’s Mixer control plane component is responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from the sidecar proxy. Mixer categorizes adapters based on the type of data they consume.

Future extensibility might come in the form of secure key stores for Hardware Security Modules (HSMs), HashiCorp Vault integration, and better support for swapping out distributed tracing infrastructure backends.

Istio Mixer is an example of an extension point in a service mesh. Mixer acts as an attribute processing engine, collecting, transforming, and transmitting telemetry.
Figure 4-2. Istio Mixer is an example of an extension point in a service mesh. Mixer acts as an attribute processing engine, collecting, transforming, and transmitting telemetry.

Conclusion

The nginMesh project has drawn much interest in the use of NGINX as Istio’s service proxy, as many organizations have broad and deep operational expertise built around this battle-tested proxy.

Ideally, your security posture evolves to that of a zero-trust environment.

Get The Enterprise Path to Service Mesh Architectures now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.