An Istio Egress gateway is just another envoy instance similar to the Ingress but with the purpose to control outbound traffic. Istio uses ingress and egress gateways to configure load balancers executing at the edge of a service mesh. An ingress gateway allows you to define entry points into the mesh that all incoming traffic flows through. Egress gateway is a symmetrical concept; it defines exit points from the mesh. Egress gateways allow you to apply Istio features, for example, monitoring and route rules, to traffic exiting the mesh.
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 Observability on Azure Monitor
The purpose of this lab is to explore the current options available to export Istio known observability mechanisms to Azure Monitor, including concerns like:
- Service mesh console
- Centralized Dashboards
- Distributed tracing
What is a Wasm Plugin?
A Wasm plugin lets you easily extend the functionality of your service mesh by adding custom code to the data path. Plugins can be written in the language of your choice. At present, there are Proxy-Wasm SDKs for AssemblyScript (TypeScript-ish), C++, Rust, Zig, and Go.
In this blog post we describe how to use a Wasm plugin to validate a request payload. This is an important use case for Wasm with Istio and an example of the many ways in which you can extend Istio using Wasm. You may be interested in reading our blog posts on using Wasm with Istio and viewing the recording of our free workshop on using Wasm in Istio and Envoy.
“All problems in computer science can be solved by another level of indirection.” – David Wheeler
Service mesh is an architectural construct designed to ease software development and delivery in a microservices environment. Making service mesh work at scale requires some new thinking and the introduction of a few new abstractions.
Here at Tetrate, we have been working on service mesh – its opportunities and its challenges – as long as anyone around. This work is based on our founders’ and key employees’ existing and ongoing roles as founders and maintainers of the open source projects that are most widely used in service mesh implementations: the Envoy proxy, Istio service mesh software, and the Skywalking observability project.
To complement the open source projects, and to create a complete solution, we created Tetrate Service Bridge (TSB). TSB adds a highly functional management plane to service mesh implementations, collaborating with Istio as the control plane and Envoy as the data proxy.
Today, I am happy to announce that the Istio project is announcing its intention to join the Cloud Native Computing Foundation (CNCF). I am very excited for this next step of the Istio project as it will further Tetrate’s mission, which is also my personal mission, to make Istio the industry standard project for service mesh.
My cofounders and I created Tetrate for this cause, and I have been dedicated to it since we conceived of the idea of Istio five years ago in the corridors at Google. Since a large number of organizations rely on Istio as infrastructure for their cloud native journey, CNCF is a natural home for the project to co-exist alongside other CNCF projects such as Kubernetes, Envoy, gRPC, and more.
Game of Thrones fans know the Iron Bank as a lender to governments, businesses, and individuals across the known world. But Iron Bank is also the repository for digitally signed container images that are accredited for use across the US Department of Defense. Iron Bank software is accessible to anyone who registers on the Iron Bank repository.
Iron Bank software must comply with relevant Federal Information Processing Standards (FIPS). Now, a FIPS-compliant version of Istio, provided and supported by Tetrate, has been accepted by the DoD and added to Iron Bank. This version of Istio is supported by the Tetrate support service, Tetrate Istio Subscription. Istio is now easily available for rapid deployment across the DoD and beyond.
The DoD is the largest organization in the world, by headcount (more than 2 million employees, civilian and military) and by budget (more than $700B per year.) About 100,000 of those 2 million employees are involved in software development and delivery. So the use of service mesh and Istio, along with Zarf (see below) and disconnected systems, by the DoD will have a large impact across the US government and beyond.
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.