Announcing Tetrate Agent Operations Director for GenAI Runtime Visibility and Governance

Learn more
< Back

What’s New in Istio 1.19: Gateway API and Beyond

Istio 1.20 signifies a notable advancement in the capabilities of the Istio service mesh, offering a better experience for operators and developers. T

What%E2%80%99s%20New%20in%20Istio%201.19%3A%20Gateway%20API%20and%20Beyond

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.

Gateway API: Revolutionizing Service Mesh

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:

  1. Internal Kubernetes Requests: Without Istio, all internal traffic in Kubernetes takes the service route.
  2. North-South Traffic: By applying the Gateway API to the Ingress gateway, incoming traffic to Kubernetes follows xRoute (currently supporting HTTPRoute, TCPRoute and gRPCRoute) to services.
  3. East-West Traffic: Inside Istio, as traffic enters the data plane, xRoute of the Gateway API takes charge. It guides the traffic to either the original or a new destination service.
Figure 1: Traffic routing.

This dynamic fusion of the Gateway API with Istio not only refines service networking but also solidifies Istio’s significance in the Kubernetes ecosystem.

Gateway API for Service Mesh: A Deeper Dive

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:

  • Same Namespace: A Route in the same Namespace as its Service, known as a producer route, is typically created by the workload creator to define acceptable usage. It affects all requests from any client of the workload across any Namespace.
  • Different Namespaces: A Route in a different Namespace than its Service, termed a consumer route, refines how a consumer of a given workload makes requests. This Route only influences requests from workloads in the same Namespace as the Route.
Figure 2: Producer Route and Consumer Route.

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:

  • A client workload initiates a request for a specific Service in a Namespace.
  • The mesh data plane intercepts the request and identifies the target Service.
  • Based on associated Routes, the request is allowed, rejected, or forwarded to the appropriate workload based on matching rules.

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.

Ambient Mesh Enhancements

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.

Simplified Virtual Machine and Multicluster Experiences

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.

Elevated Security Configurations

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!

Product background Product background for tablets
New to service mesh?

Get up to speed with free online courses at Tetrate Academy and quickly learn Istio and Envoy.

Learn more
Using Kubernetes?

Tetrate Enterprise Gateway for Envoy (TEG) is the easiest way to get started with Envoy Gateway for production use cases. Get the power of Envoy Proxy in an easy-to-consume package managed via the Kubernetes Gateway API.

Learn more
Getting started with Istio?

Tetrate Istio Subscription (TIS) is the most reliable path to production, providing a complete solution for running Istio and Envoy securely in mission-critical environments. It includes:

  • Tetrate Istio Distro – A 100% upstream distribution of Istio and Envoy.
  • Compliance-ready – FIPS-verified and FedRAMP-ready for high-security needs.
  • Enterprise-grade support – The ONLY enterprise support for 100% upstream Istio, ensuring no vendor lock-in.
  • Learn more
    Need global visibility for Istio?

    TIS+ is a hosted Day 2 operations solution for Istio designed to streamline workflows for platform and support teams. It offers:

  • A global service dashboard
  • Multi-cluster visibility
  • Service topology visualization
  • Workspace-based access control
  • Learn more
    Decorative CTA background pattern background background
    Tetrate logo in the CTA section Tetrate logo in the CTA section for mobile

    Ready to enhance your
    network

    with more
    intelligence?