I’m delighted to present Istio’s most recent release—Istio 1.19. This blog will provide an overview of the updates bundled in this release.
Our previous blog highlighted the Gateway API’s potential to harmonize ingress gateways in Kubernetes and service mesh, opening doors to cross-namespace traffic support. With Istio’s official endorsement, the Gateway API takes center stage. While traditionally applied to north-south traffic (the ingress and egress of the mesh), it now extends its prowess to the realm of east-west traffic, the lifeblood within the mesh.
In Kubernetes, services wear multiple hats, handling tasks from service discovery and DNS to workload selection, routing and load balancing. Yet, control over these functions has been limited, with workload selection being the notable exception. The Gateway API changes the game, putting you in command of service routing. This introduces some overlap with Istio’s VirtualService, as both wield influence over traffic routing. Here’s a glimpse into three scenarios:
This dynamic fusion of the Gateway API with Istio not only refines service networking but also solidifies Istio’s significance in the Kubernetes ecosystem.
At its current experimental stage (as of v0.8.0), the Gateway API for Service Mesh introduces a fresh approach to configuring service mesh support in Kubernetes. It directly links individual route resources (such as HTTPRoute) with Service resources, streamlining the configuration process.
Here are some key takeaways:
Experimental Stage: As of version v0.8.0, the Gateway API for Service Mesh is still experimental. It’s advised not to use it in production environments.
Service and Route Association: Unlike using Gateway and GatewayClass resources, individual route resources are linked directly with Service resources when configuring a service mesh.
Frontend and Backend Aspects of Service: The Service’s frontend encompasses its name and cluster IP, while the backend consists of its collection of endpoint IPs. This distinction facilitates routing within a mesh without introducing redundant resources.
Route Attachment to Service: Routes are attached to a Service to apply configuration to any traffic directed to that Service. The traffic follows the mesh’s default behavior if no Routes are attached.
Namespace Relationships:
Combining Routes: Multiple Routes for the same Service in a single Namespace, whether producer or consumer routes, will be merged according to the Gateway API Route merging rules. This means defining distinct consumer routes for multiple consumers in the same Namespace is impossible.
Request Flow:
Bear in mind that, in the experimental stage, the Gateway API for Service Mesh may undergo further changes and is not recommended for production use.
But wait, there’s more! Our journey doesn’t end here – the support for ingress traffic using the API is rapidly heading toward General Availability, promising even more dynamic developments!
Let’s delve further into additional enhancements in this release.
The Istio team has been tirelessly refining the ambient mesh, an innovative deployment model that offers an alternative to the traditional sidecar approach. If you haven’t explored ambient yet, now’s the perfect time to dive into the introduction blog post.
With this update, we’ve amplified support for ServiceEntry
, WorkloadEntry
, PeerAuthentication
and DNS proxying. Alongside, bug fixes and reliability enhancements ensure a seamless experience.
Remember, the ambient mesh is in its alpha phase for this release. The Istio community eagerly awaits your feedback to propel it toward Beta.
Simplicity is key, especially when working with Virtual Machines and Multicluster setups. In this release, we’ve made the address field optional in the WorkloadEntry
resources. This seemingly small adjustment promises to streamline your workflow significantly.
You can now configure OPTIONAL_MUTUAL
for your Istio ingress gateway’s TLS settings, providing the flexibility of optional client certificate validation. Additionally, you can fine-tune your preferred cipher suites used for non-Istio mTLS traffic via MeshConfig
.
With these updates, Istio 1.19 empowers you with greater control, flexibility and security in managing your service mesh.
Feel free to explore these enhancements and share your experiences with the Istio community. For more details, refer to the official release notes.
Happy meshing!
This blog was initially published at tetrate.io.
Last updated on Dec 3, 2024