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.
Today, the Envoy community announced an exciting new project: Envoy Gateway. The project unites industry leaders to streamline the benefits of application gateways powered by Envoy. This approach allows Envoy Gateway to immediately establish a solid foundation for rapid innovation. The project will provide a suite of services to manage an Envoy Proxy fleet, drive adoption through ease of use, and support a multitude of use cases through well-defined extension mechanisms.
Istio uses iptables for traffic hijacking, and there is one rule chain named ISTIO_OUTPUT which contains the following rules.
The purpose of this lab is to explore the current options available to export Istio known observability mechanisms to Azure Monitor, including concerns like:
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.
At the joint NIST-Tetrate conference this year on ZTA and DevSecOps for Cloud Native Applications, Tetrate founding engineer Zack Butcher offered a deep dive into new publications in the NIST SP 800-204 series that sets the standards on security for the use of microservices architecture for the US Government. In this article, we’ll provide a brief overview of Zack’s talk, with a link to a full recording for all the details.
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.
