Ambient mesh is an experimental new deployment model recently introduced to Istio. It splits the duties currently performed by the Envoy sidecar into two separate components: a node-level component for encryption (called “ztunnel”) and an L7 Envoy instance deployed per service for all other processing (called “waypoint”). The ambient mesh model is an attempt to gain some efficiencies in potentially improved lifecycle and resource management. You can learn more about what ambient mesh is and how it differs from the Sidecar pattern here.
In September 2022, Istio became a CNCF incubation project and launched the new Ambient Mesh. With CNCF’s strong community and marketing resources, and Ambient Mesh further lowering the barrier to trying Istio, the five year old open source project has been revitalized.
If you don’t know about service mesh and Istio, or are curious about the future of Istio, this eBook—The Current State and Future of the Istio Service Mesh will give you the answers. The following is an excerpt from the book. In my view, the future of Istio lies in being the infrastructure for zero-trust network and hybrid cloud.
Istio 1.14 was released in June of this year, and one of the most notable features of this release is support for SPIRE, which is one of the implementations of SPIFFE, a CNCF incubation project. This article explains what SPIRE means for zero-trust architectures and why you would need SPIRE for authentication in Istio.
In my last blog, I gave you a detailed overview of the traffic in the Istio data plane, but the data plane does not exist in isolation. This article will show you the ports and their usages for each component of both the control plane and data plane in Istio, which will help you understand the relationship between these flows and troubleshoot them.
Istio uses iptables for traffic hijacking, and there is one rule chain named ISTIO_OUTPUT which contains the following rules.
Istio is one of the three core technologies in the container-based cloud native stack. The other two are Kubernetes and Knative, and both of them already support the arm64 architecture. Envoy, Istio’s data plane has supported arm64 as early as version 1.16 (October 2020 ). With the release of Istio 1.15, the control plane supports arm64 as well. You don’t need to build the arm image manually, it works out of the box.
As the service mesh architecture concept gains traction and the scenarios for its applications emerge, there is no shortage of discussions about it in the community. I have worked on service mesh with the community for 4 years now, and will summarize the development of service mesh in 2021 from this perspective. Since Istio is the most popular service mesh, this article will focus on the technical and ecological aspects of Istio.
It’s been more than four years since Istio launched in May 2017, and while the project has had a strong following on GitHub and 10+ releases, its growing open-source ecosystem is still in its infancy.
You can use Istio to do multi-cluster management, API Gateway, and manage applications on Kubernetes or virtual machines. In my last blog, I talked about how service mesh is an integral part of cloud native applications. However, building infrastructure can be a big deal. There is no shortage of debate in the community about the practicability of service mesh and Istio– here’s a list of common questions and concerns, and how to address them.
- Is anyone using Istio in production?
- What is the impact on application performance due to the many resources consumed by injecting sidecar into the pod?
- Istio supports a limited number of protocols; is it scalable?
- Will Istio be manageable? – Or is it too complex, old services too costly to migrate, and the learning curve too steep?
I will answer each of these questions below.