Better Together: Istio Ambient Mesh and Gloo Mesh

The first alpha release of the new sidecar-less ambient mode in Istio is out, and we at Solo are eager to announce that support for Istio Ambient Mesh will be available in Gloo Mesh 2.2. 

At a high level, some of the key features of Istio Ambient Mesh include:

• No sidecar injection. The lifecycle of application pods is separate from the lifecycle of Istio or Istio proxies.
• Creation of ‘ztunnel’, a lightweight mechanism for securing and routing traffic (e.g. through a waypoint when necessary) at the Layer 4 level 
• Creation of waypoint proxies, which implement Layer 7 policies and reporting

As a leader in the service mesh space and with a large customer base with diverse needs and use cases, we are acutely aware of the challenges adopting service mesh in enterprise organizations.  Right now, the Gloo platform supports proxies at both ends of a spectrum:  “as high as you can go” (Gloo Gateway), and “as low as you can go” (Gloo Mesh with classic Istio sidecars pushed down to all pods).  

Istio Ambient Mesh allows Gloo Mesh to leverage patterns in the middle, using intermediate waypoint proxies of coarser scope than pod-level sidecars to achieve the same results. This is especially helpful for meeting the needs of the “early majority” and “late majority” adopters of service mesh, who might want to ease into the service mesh world incrementally without plunging directly into the world of sidecars.  

For existing mesh users with classic sidecars, ambient mode presents an attractive opportunity to decouple application pod lifecycles from Istio. Cost-conscious users may value increased opportunities to reduce resource consumption and costs. The separation between user workloads, the lightweight ztunnel secure overlay layer, and Layer 7 waypoint proxies implies more flexibility to deploy only what you need, and adopt an enhanced security posture at the same time. And as always, you can count on Gloo Mesh and Solo’s experience and expertise to make the most of these new opportunities.

Adapting to a new architecture

The alpha release of Istio Ambient Mesh reflects a set of initial choices that were practical to implement first, by a small team. In particular:

• One ztunnel proxy serves the needs of all pods on a single node
• One waypoint proxy serves the Level 7 needs of a single ServiceAccount

This is not an uncontroversial set of initial choices for the alpha release, but it is a good starting point for exploring the paradigm and understanding how best to leverage it in a way that provides value to customer needs. By adding Gloo Mesh support for Ambient early on even in its alpha phase, we get concrete feedback from real-world customers for how best to support Ambient in Gloo Mesh, and how best to contribute to the evolution of Istio Ambient Mesh upstream.

Even though core Istio APIs have not changed in ambient mode, there is a lot to learn and un-learn when wrapping your head around the ambient architecture. A few new concepts need to be managed, and there are some interesting implications on metrics and reporting. Our engineers have been working hard to adapt to these changes in Gloo Mesh while preserving the same UX and flattening the learning curve for our customers. Two examples are especially notable to share: Adapting the Gloo Mesh UI to ambient metrics, and managing the lifecycle of waypoint proxies.

Gloo Mesh UI with Istio Ambient Mesh Metrics

The Gloo Mesh UI supports Istio Ambient Mesh out of the box to provide the same high-level overview of the mesh network topology customers are used to. It took some effort to get there, and along the way, we discovered some nuances in metrics to adapt to.

As a good illustrative example, in order to draw an edge with metrics associated with it, we need to know the identities of the workloads that are communicating. This is actually a more subtle problem than it looks at first glance when you have a network path composed of ztunnels (which only know about Layer 4) with traffic multiplexed through them, possibly passing through one or two waypoint proxies along the way. This is an engineering challenge inside of Istio itself, but Solo engineers made significant contributions to Istio in order to efficiently propagate key metadata through these hops. The end result of this work is that Ambient Istio Layer 4 metrics have the same semantics as Layer 4 metrics from sidecars, allowing us to leverage previous UI work to draw the graph.  

Request latency is another good example of a relatively simple metric in the sidecar world that needs some engineering underneath the hood in order to stitch together a single figure from different kinds of hops a request can make through ztunnels or waypoint proxies. As a whole, the work we’ve done on metrics likely deserves its own blog, so suffice it to say the engineers at Solo understand the nuances involved, and know what it takes to deliver a consistent experience to the customer regardless of Istio architecture underneath.

Managing Istio waypoint proxies

While the core APIs in Istio haven’t changed (e.g. ServiceEntries, VirtualServices, DestinationRules, etc), where and how these APIs are implemented has changed dramatically.   For example, a VirtualService in ambient mode is implemented in a waypoint proxy for the service that implements a given hostname, rather than on the client-side as was the case with sidecars. Likewise, ServiceEntries in ambient mode are strictly client-side.  

Once you figure out where waypoint proxies go, you need to leverage the Gateway API for instructing Istio to create them. In short, this looks like:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
  name: bookinfo
  annotations:
    istio.io/service-account: bookinfo-productpage
spec:
  gatewayClassName: istio-mesh

This would instruct Istio to create a waypoint proxy to serve the bookinfo-productpage service account.

The problem is that you are responsible for knowing when and where you need waypoint proxies–Istio doesn’t create them implicitly. The Gateway API is user-facing and intentional.  Needing to use it correctly in order to assure that your policy can be implemented by Istio has no direct analog in the sidecar world, and represents a tradeoff of cognitive load for flexibility.  

Thankfully, Gloo Mesh has you covered! We realized early on that managing the lifecycle of waypoint proxies would be a challenging task, one that Gloo Mesh is well positioned to manage.  As a result, we built waypoint lifecycle management into Gloo Mesh for all ambient workloads.    In other words, based on your network policy, Gloo Mesh can deduce when and where you need waypoint proxies, and automatically manage their lifecycle.

The gateway API itself is evolving and has some limitations. We know from experience that Gloo Mesh customers have demanding use cases, and would be interested in tweaking performance and resiliency-related parameters. As a result, we provide an API for enhanced configurability of waypoint deployment, such as scaling and pod affinity parameters.

These are not currently part of the gateway API, but one of the advantages of Gloo Mesh is mitigating risk of evolving standards. However it evolves, Gloo Mesh will do what it takes so that it just works for you.

Where we are today

We’re excited to play an active role in Istio’s evolution, and even more excited to explore new patterns in Gloo Mesh.  The value we see in Gloo Mesh is providing a layer of abstraction that allows an organization to adapt and evolve new paradigms to its own evolving needs, while managing the complexity under the hood.  

We want to make it easy for our customers to explore the value provided by whatever service mesh pattern best suits their needs. Classic sidecars and ambient waypoints both have a role to play in this evolving space, and we are truly proud to stand behind Gloo Mesh as a tool to simplify service mesh adoption. The engineering team at Solo.io has worked hard to manage the nuances of evolving Istio architecture underneath Gloo Mesh’s familiar set of APIs, so that you don’t have to. Gloo Mesh’s underlying APIs have not changed and still provide the same benefits such as multi-tenacy with Workspaces, set up connectivity across services via the RouteTable and applying policies.

Istio Ambient Mesh is still alpha, and you’ll see plenty of improvements and iterations before its General Availability (GA) release in an upcoming version of Istio. We are committed to working with the Istio community to get Ambient over the finish line to production-ready GA. In the meantime, please reach out if you want to explore it for yourself with Gloo Mesh!

See Istio Ambient Mesh with Gloo Mesh in action

To see Istio Ambient Mesh in action with Gloo Mesh, check out this short demo video: