Istio ambient mesh is a new, sidecar-less data plane architecture introduced in the Istio community on 9/7. I am personally proud to be part of the ambient mesh launch after many months of working with our brilliant engineers. About two years ago, I wrote the “Service mesh is still hard” blog and many of the points in that blog are still valid with the sidecar architecture. In this blog, I want to highlight five things in ambient mesh that I am extremely excited about while circling back to some of the points I made in my earlier blog.
Simplified Operation
If you used a sidecar-based approach before, you had to inject the sidecar to your application pod either when initially deploying your application or by restarting your application. When there is any CVE related to the sidecar proxy, you have to restart your application pod to refresh to the newer sidecar proxy that contains the CVE fixes. This restart is required even when you have no change in your application which could add a lot of operational overhead to running your application.
Including an application in ambient is as simple as annotating a namespace with the dataplane-mode:ambient label. Pods will start to be automatically included in ambient as soon as the istio-cni component detects the newly added label and configures the traffic redirect from the application pod to ztunnel. You can keep your applications running while it is being included as part of ambient, and you don’t need to restart your application or inject sidecars to your application at all.
Broader Application Support
Two challenges I highlighted in my earlier blog are:
- Your service may break immediately after a sidecar is injected
- Your service may have odd behavior at the start or stop time
Remember the hours you spent trying to figure out why your application stopped working the moment it had sidecar injected? For me, I would go to the Istio application requirement page, to check if my application didn’t satisfy any requirements on the list. Because the list is not small, from not supporting Kubernetes Jobs, server-send-first protocols, or a list of reserved ports, etc, I usually find my application doesn’t meet the requirements. Further, because sidecars are not official concepts in Kubernetes, there is no standard way to manage how sidecars’ lifecycle relates to application containers at startup or stop time, which becomes even more challenging when the application itself also has its own init container or sidecar.
With HTTP Based Overlay Network (HBONE) introduced as the tunneling mechanism for inter-service mesh communications, ambient mesh is designed to support broader applications by removing many of these application requirements in Istio. For example, you can deploy Kubernetes Jobs or applications that use server-send-first protocols or call pod IPs directly from your applications as your applications are included in ambient mesh. The broader support of applications will reduce your effort and surprises when onboarding your application to the mesh.
Better Incremental Adoption
One of the key innovations with ambient mesh is the two-layer approach that separates the secure overlay layer from the Layer 7 processing layer. The two-layer approach effectively enables you to adopt the mesh incrementally starting with the secure overlay layer and enjoying the benefits brought by the layer such as mTLS with cryptographic identity, simple Layer 4 authorization policy, and telemetry. If you do need L7 traffic management, resiliency, or rich authorization policies, you could enable the L7 processing through waypoint proxies only for the applications that need them.
One challenge I highlighted in my earlier blog is that, “Service owners need to understand nuances of client and server-side configurations”. The ambient layer 7 processing layer effectively moves all source-side processing to the destination side so you only need a waypoint proxy on the destination side. This architecture not only helps reduce an extra L7 processing hop and an xDS client that the Istiod control plane needs to push data to, but also simplifies some of the learning hurdles service mesh users have regarding if a given policy is implemented in the source or destination sidecar and where to debug upon failure. For example, in a traditional sidecar approach, route configurations (either VirtualService or HTTPRoute resources) are implemented on the source sidecar while authorization policy is implemented on the destination sidecar. In ambient mesh, both are implemented on the destination waypoint proxy.
Reduced Infrastructure Cost
The Istio project has gone a long way to reduce infrastructure cost with service or resource visibility and Sidecar configuration, and we designed ambient to further reduce infrastructure cost. The ztunnel is designed to be multi-tenancy that handles zero-trust as the secure overlay layer for all co-located pods in the ambient mesh. The waypoint proxy is designed to handle L7 processing only for a single tenant (which could be either per service account or namespace) on the destination side to avoid outages, noisy neighbors, budgeting and cost attribution issues caused by multi-tenancy L7 processing. Waypoint proxies reduce infrastructure cost by scaling independently outside of the application pod. You can share the waypoint proxy of a single service account across multiple services.
The multi-tenancy nature of ztunnel and single tenancy nature of waypoint proxy enable us to further reduce infrastructure costs beyond what the service visibility and sidecar resource configuration can provide. Not only do we reduce the provisioned CPU and RAM of these data plane resources, but also the data transfer over the network from the Istio control plane to a much fewer number of connected xDS clients. Refer to the What Istio Ambient Mesh Means to Your Wallet blog for more details.
Sidecars continue to be supported and can interoperate with sidecar-less
We expect sidecars will continue to be around, which is why we designed ambient mesh to support both sidecar and sidecar-less data plane architectures so that both types of services interoperate. You might continue to use sidecars simply because you feel comfortable with that approach, you need more granular enforcement than a service account, or you are waiting for ambient mesh to be production ready.
Istio sidecars in ambient mesh already support HBONE. The same HBONE support will land in Istio sidecars in all Istio installation profiles very soon, which paves the path for all existing Istio sidecars to be upgraded to interoperate with sidecar-less services because the sidecars, ztunnels, or waypoint proxies can send and receive HBONE traffic. This is important if you are using sidecar today and may choose to migrate some or all of your workloads to sidecar-less in the future, or you are planning to run some of your applications in the mesh with sidecars and some without sidecars.
What is next?
Istio ambient mesh brings the transparent service mesh to you with simplified operation and broader application support, without compromising security compared with sidecars. A build of Istio which supports ambient mesh is available to download and try in the Istio Experimental repo. Or you can try the free get started with ambient mesh workshop with a lab environment provided for you. As the community works towards making ambient mesh production ready as the default in Istio, we invite you to be part of the journey, with your feedback or contribution to help shape the ambient mesh, in the ambient channel on the Istio Slack or GitHub.
About Lin
Lin is the Director of Open Source at Solo.io and a CNCF ambassador. She is a founding member of the Istio Technical Oversight Committee and Steering Committee. Previously, she was a Senior Technical Staff Member and Master Inventor at IBM for 15+ years. She is the author of the book Istio Explained and has more than 200 patents to her name.
Community guest post from Lin Sun, Director of Open Source at Solo.io and a CNCF ambassador
Source CNCF
