Taming the Traffic: Select... Spencer Hance, Arko Dasgupta, Christine Kim, Kate Osborn & Mike Morris

Taming the Traffic: Selecting the Perfect Gateway API Implementation for You

Speakers: Spencer Hance, Software Engineer, Google; Arko Dasgupta, Maintainer, Envoy Gateway project & Engineer, Tetrate; Christine Kim, Open Source Developer Experience, Isovalent; Kate Osborne, Software Engineer, Enro; Mike Morris, Product Manager, Microsoft

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=QzE6vSgcyT0

Overview

This panel discussion, "Taming the Traffic: Selecting the Perfect Gateway API Implementation for You," addresses a critical challenge faced by organizations adopting Kubernetes: navigating the rapidly expanding ecosystem of Gateway API implementations. With nearly 30 implementations available today, choosing the right one can be daunting. The panel, composed of maintainers and contributors from leading companies deeply involved in the Gateway API (Enro, Isovalent/Cilium, Microsoft/Istio, Google/GKE, Tetrate/Envoy Gateway), aims not to declare a single "best" solution, but rather to provide a comprehensive framework and context for users to make informed decisions tailored to their specific needs.

The talk highlights the limitations of the older Kubernetes Ingress API, particularly its lack of advanced routing capabilities and reliance on non-standard, often insecure annotations, making a strong case for the Gateway API as its modern, more robust successor. By offering structured, validated, and role-oriented APIs, the Gateway API promises greater expressiveness, reduced vendor lock-in, and enhanced security. This session is invaluable for anyone considering migration from Ingress, evaluating different Gateway API solutions, or simply seeking a deeper understanding of the API's evolving capabilities and operational considerations in a production environment.

The discussion covers a spectrum of topics, from the foundational advantages of the Gateway API over Ingress to practical advice on evaluating implementations, managing day-two operations, and understanding the delicate balance between standardization and vendor-specific flexibility. The speakers emphasize community collaboration, the API's expanding scope beyond traditional north-south traffic, and exciting upcoming features that continue to solidify its position as the future of traffic management in Kubernetes.

Background

▶ Watch: Introduction: The challenge of choosing a Gateway API implementation. (0:00)

The evolution of traffic management within Kubernetes has seen significant advancements, driven primarily by the limitations of the Ingress API. As Kate Osborne articulated, while Ingress is simple and easy to use for basic routing, it quickly falls short when more advanced capabilities are required. Features such as traffic splitting, request mirroring, and header manipulation are not natively supported by the core Ingress specification. This often forces users to rely on annotations – simple string-to-string key-value pairs – to extend functionality.

However, these annotations introduce several critical drawbacks. They are unstructured, meaning they lack a formal schema for validation. This absence of schema validation means that misconfigurations might only be caught at runtime by the specific Ingress controller, potentially leading to errors or, more critically, security vulnerabilities if not robustly handled. Furthermore, annotations are not standardized across implementations. As Kate explained, switching from an NGINX-based Ingress controller to an Envoy-based one would require a complete re-mapping of annotations, leading to significant effort and vendor lock-in.

The Gateway API was developed to address these fundamental shortcomings. It provides first-class APIs for advanced routing features, embedding them directly into its resources. This makes them structured, schema-validated, and crucially, standard across all implementations. Spencer Hance elaborated on the benefits, emphasizing reduced vendor lock-in as the core API surface covers most features, allowing users to move between implementations with minimal changes. He also highlighted the role-oriented architecture of the Gateway API, which clearly delineates responsibilities: the infrastructure provider owns the GatewayClass, the cluster operator manages the Gateway, and the application owner/developer is responsible for HTTPRoute and Services. This separation, when combined with RBAC (Role-Based Access Control), enhances security and operational clarity. Finally, Spencer pointed out the active development and strong community involvement in the Gateway API, making it a future-proof choice for long-term maintenance and growth compared to the largely static Ingress API.

Key Findings

▶ Watch: Ingress limitations vs. Gateway API's expressive, standard features. (2:50)

The panel presented several key findings and recommendations for navigating the Gateway API landscape:

1. Systematic Decision-Making Process: Arko Dasgupta outlined a three-step approach to select an implementation from the nearly 30 available options:

• Step 1: Feature Parity (Spreadsheet Time): Users should list all their use cases and map them against the capabilities of various implementations. Valuable resources for this include the Gateway API conformance report page (maintained by Christine Kim and Matea) and the Ingress table on the learnk8s.io page. This step also involves considering migration costs and purchase costs. The goal is to narrow down the choices to 5-7 implementations.
• Step 2: Data Plane Differentiators: Further narrow down options (to approximately 3) by evaluating the underlying data plane or proxy technology. For example, Envoy proxy is known for its rich observability and extensibility, while NGINX excels at serving static assets.
• Step 3: Proof of Concept (PoC) Time: The final step involves hands-on testing of the narrowed-down implementations. This includes validating feature functionality, logging operational experiences to measure operational cost, and running specific traffic and scale tests relevant to the user's environment.

1. Expanded Scope Beyond North-South Traffic: Mike Morris emphasized that Gateway API is not limited to traditional north-south traffic management (external to cluster). It also supports east-west traffic (service mesh traffic). This means the choice of a north-south gateway might be influenced by the chosen service mesh. For instance, Istio has a built-in ingress gateway with Gateway API support, offering seamless integration and mTLS. Linkerd, while not having its own ingress, integrates well with other gateways. Cloud provider-specific Gateway API implementations can offer better integration with services like DNS and certificate management.

1. Day 2 Operations are Critical: Spencer Hance and Christine Kim highlighted the importance of day 2 operations (ongoing maintenance and management). A significant factor is CRD (Custom Resource Definition) management. Because Gateway API CRDs are developed outside the core Kubernetes tree, their installation, version upgrades, and management can be complex, especially when running multiple implementations. Cloud provider-managed Gateway API implementations can alleviate this burden. Observability is also crucial, with many implementations leveraging Envoy's extensive metrics. Tools like Cilium's Hubble provide deep visibility into north-south traffic and metrics.

1. Balancing Standardization and Flexibility: The panel agreed that the primary goal is conformant behavior for common features, but flexibility is also essential. Arko Dasgupta and Kate Osborne explained that implementations need the freedom to build on top of the API to solve user-specific problems, especially for proprietary configurations (e.g., NGINX-specific settings that don't apply to Envoy). Extension mechanisms like policies are standardized in how they attach to Gateway API resources, even if their underlying behavior is implementation-specific. This also allows implementers to deliver features faster (e.g., OAuth) before a standardized specification is available.

1. Collaboration Despite Competition: Speakers underscored that all implementers benefit from a good user experience with the Gateway API. Arko Dasgupta noted that the API's evolution from Ingress provides a richer experience, fostering a collaborative environment. Mike Morris shared a compelling story of a user from box.com, Eric Bishop, who brought a need for budgeted retries (a feature common in Envoy and Linkerd) to the Gateway API community. This led to a collaborative effort involving Istio, Linkerd, and Google, resulting in a Gateway API Enhancement Proposal (GEP) for inclusion in the upcoming 1.3 release and demonstrating how competing solutions can work together to enrich the common specification.

1. Exciting Upcoming Features: The Gateway API is continuously evolving. Notable upcoming features include:

• Endgate: A new project focused on improving user experience and providing a seamless migration path from Ingress to Gateway API.
• Inference Extension: A specialized extension for serving Machine Learning (ML) inference workloads on Kubernetes, with significant involvement from Google and ByteDance.
• OAuth (Authentication and Authorization): Efforts to standardize common authentication and authorization use cases, such as JWTs (JSON Web Tokens) and OIDC (OpenID Connect), directly within the Gateway API spec.
• TCP and UDP Route Types: Enhancements to support non-HTTP traffic, allowing advanced routing features like traffic splitting for protocols like PostgreSQL, without necessarily replacing Service Type=LoadBalancer but offering more granular control.

Technical Deep Dive

▶ Watch: Gateway API benefits: less vendor lock-in, role-oriented architecture. (5:00)

The Gateway API represents a profound architectural shift from its predecessor, the Ingress API, offering enhanced capabilities and a more robust framework for traffic management in Kubernetes. The technical underpinnings of this evolution are critical for understanding its advantages.

At its core, the Ingress API was designed for simplicity, providing basic HTTP routing. However, as Spencer Hance and Kate Osborne explained, this simplicity quickly became a limitation for advanced use cases. When features like traffic splitting for A/B testing or canary deployments, request mirroring for shadow traffic, or fine-grained header manipulation were required, Ingress relied heavily on annotations. These annotations, while seemingly convenient, were merely string-to-string key-value pairs. Technically, they lacked schema validation, meaning the Kubernetes API server would accept any annotation, leaving the burden of validation to the specific Ingress controller at runtime. This could lead to subtle configuration errors or, in worst-case scenarios, introduce security vulnerabilities due to unchecked input. Furthermore, their non-standard nature meant that each Ingress controller (e.g., NGINX Ingress Controller, Traefik, HAProxy Ingress) had its own set of proprietary annotations, leading to significant vendor lock-in and complex migration paths.

The Gateway API fundamentally re-architects this approach. It introduces a set of Custom Resource Definitions (CRDs) that are first-class citizens in Kubernetes, designed with expressiveness in mind. Instead of annotations, advanced routing features are built directly into the API resources, such as HTTPRoute, TCPRoute, TLSRoute, and UDPRoute. These resources are structured and schema-validated, ensuring that configurations are syntactically and semantically correct at the API server level, reducing the risk of runtime errors and enhancing security. The standardization across implementations means that a user can define an HTTPRoute for traffic splitting, and that definition will be understood and applied consistently by any conformant Gateway API implementation, whether it's backed by NGINX, Envoy, or a cloud load balancer.

A key technical differentiator is the role-oriented architecture championed by the Gateway API. This paradigm establishes clear separation of concerns:

• The Infrastructure Provider (e.g., a cloud vendor or an internal platform team) defines GatewayClass resources, which describe the capabilities and provisioning model of a specific type of gateway.
• The Cluster Operator provisions and manages Gateway resources, which represent the actual load balancers or proxies within the cluster. This allows them to define the entry points for traffic, including listeners for different protocols and ports.
• The Application Owner/Developer then defines HTTPRoute (or other route types) and Service resources, linking their application's traffic routing rules to a specific Gateway. This empowers application teams to manage their own routing without needing direct access to or knowledge of the underlying infrastructure. This delegation, when combined with Kubernetes RBAC, significantly improves security posture by enforcing least privilege and preventing unauthorized configuration changes.

Many Gateway API implementations, as Spencer Hance and Arko Dasgupta noted, leverage Envoy Proxy as their underlying data plane. Envoy is a high-performance, open-source edge and service proxy designed for cloud-native applications. Its architecture provides extensive features for traffic management, load balancing, observability, and extensibility. This makes it a popular choice for building sophisticated Gateway API controllers, offering rich metrics and insights into traffic flow. For example, Envoy Gateway is a specific project that implements the Gateway API using Envoy, and enterprise offerings like Tetrate's TEG build upon this foundation. Other implementations might use NGINX, as seen with Enro's Kubernetes operator, leveraging NGINX's strengths, particularly for static content serving.

The Gateway API also provides extension mechanisms to balance standardization with vendor-specific needs. Kate Osborne explained how policies can be used. While the core Gateway API standardizes common behaviors, certain proprietary configurations (e.g., NGINX-specific tuning parameters) cannot be universally standardized. Policies allow implementers to define custom CRDs that attach to standard Gateway API resources (like Gateway or HTTPRoute), enabling users to configure these vendor-specific settings while still adhering to a standardized attachment model. This ensures that the mechanism for extension is consistent, even if the extended behavior is implementation-specific. Filters are another extension point, allowing for specific processing steps within a route definition, such as request transformations or authentication checks.

Crucially, the Gateway API extends its reach beyond just north-south traffic (traffic entering the cluster from external sources) to east-west traffic (traffic flowing between services within the cluster). This capability is particularly relevant for service meshes like Istio and Linkerd. Mike Morris highlighted that Istio, for example, is increasingly adopting Gateway API as its primary configuration interface for traffic routing, especially in its ambient mode. This allows a unified control plane for both external ingress and internal service-to-service communication. The concept of Reference Grant, which Mike also championed, is a technical mechanism that enables secure cross-namespace references between Gateway API resources. It acts as an explicit contract, allowing a resource in one namespace (e.g., an HTTPRoute) to securely reference a Service in another namespace, which is fundamental for delegating control safely and maintaining security boundaries in multi-tenant or complex environments.

Upcoming technical advancements further underscore the API's ambition. The work on TCPRoute and UDPRoute types, as mentioned by Christine Kim and Spencer Hance, aims to bring the advanced routing capabilities of Gateway API to non-HTTP protocols. While these might not immediately replace Kubernetes Service Type=LoadBalancer for all scenarios, they provide the ability to apply features like traffic splitting and fine-grained routing to database connections (e.g., PostgreSQL) or other custom TCP/UDP services, which was previously challenging. The Inference Extension is another specialized development, demonstrating the API's adaptability to specific workload types like ML inference serving, highlighting its modular and extensible design.

Finally, effective day 2 operations rely heavily on the status fields of Gateway API resources. Spencer Hance recommended using gateway.status and resource.status for debugging, alongside tools like gatewayctl, which provides enhanced introspection into the Gateway API configuration and its operational state. This emphasis on robust status reporting is a direct response to the lack of clear feedback mechanisms often found in Ingress configurations, making troubleshooting significantly more transparent and efficient.

Demo / Proof of Concept

▶ Watch: How to choose among 30 Gateway API implementations. (6:40)

This panel discussion did not include a live demonstration or a specific proof of concept. As an expert panel, the focus was on sharing insights, best practices, and strategic considerations for selecting and operating Gateway API implementations based on their extensive experience.

Defensive Implications

▶ Watch: Step 1: Evaluate feature parity using conformance reports. (7:10)

The adoption of Gateway API carries significant defensive implications for Kubernetes environments, addressing several security shortcomings inherent in the older Ingress API.

Firstly, the Gateway API's move away from unstructured annotations directly enhances security. As Kate Osborne pointed out, Ingress annotations are not validated by schema, leaving potential security vulnerabilities if an implementation's runtime validation is not robust. Malicious or malformed annotations could lead to unintended configurations or even exploit parsing vulnerabilities. In contrast, Gateway API resources are structured and schema-validated at the API server level. This pre-validation reduces the attack surface by ensuring that only syntactically and semantically correct configurations are applied, preventing many common misconfiguration-related security issues.

Secondly, the role-oriented architecture of the Gateway API fosters a more secure operational model. By clearly separating the responsibilities of the infrastructure provider, cluster operator, and application owner, and enforcing these separations with RBAC, the Gateway API promotes the principle of least privilege. For instance, an application developer can manage their HTTPRoute without needing elevated permissions to modify the underlying Gateway or GatewayClass, which are typically managed by platform teams. This prevents unauthorized users from altering critical infrastructure components and reduces the blast radius of any compromised application credential.

The concept of Reference Grant, highlighted by Mike Morris, is a direct security feature. It provides an explicit contract for secure cross-namespace delegation. In multi-tenant clusters or environments with services spanning multiple namespaces, ReferenceGrant ensures that one resource (e.g., an HTTPRoute in an application namespace) can only reference a resource (e.g., a Service in a shared services namespace) if explicitly permitted. This prevents unauthorized routing to services, mitigating potential data exfiltration or denial-of-service attacks across namespace boundaries.

While policy attachment offers valuable flexibility, it also introduces a defensive consideration: policy visibility. As Mike Morris and Kate Osborne noted, understanding which resources are affected by a policy can be challenging. From a defensive standpoint, it's crucial for security auditors and operators to have clear visibility into the inheritance and application of policies to ensure they don't inadvertently create security gaps or bypass intended controls. Comprehensive observability and auditing tools are essential here.

Finally, the ongoing work on OAuth, authentication, and authorization within the Gateway API spec directly addresses critical application security concerns. Standardizing how JWTs and OIDC are handled at the gateway level means that authentication and authorization policies can be consistently applied and enforced across different implementations. This offloads complex security logic from individual applications to the gateway, reducing the likelihood of implementation errors and providing a centralized point of control for access management, which is a significant defensive advantage.

Key Takeaways

• Gateway API is the Future of Kubernetes Traffic Management: It fundamentally improves upon the Ingress API by offering expressive, standardized, schema-validated, and role-oriented APIs, significantly reducing vendor lock-in and enhancing security for advanced routing needs.
• Strategic Selection is Crucial: Given nearly 30 implementations, a structured decision-making process involving feature parity analysis, data plane evaluation, and hands-on PoCs is essential for choosing the right solution for specific organizational requirements.
• Comprehensive Scope and Integration: Gateway API supports both north-south and east-west traffic, enabling seamless integration with service meshes (like Istio and Linkerd) and cloud provider services (DNS, certificate management) for a unified traffic control plane.
• Day 2 Operations Demand Attention: Effective management of CRDs (installation, upgrades) and robust observability (metrics, logging, tools like Cilium Hubble) are paramount for the long-term operational success and stability of Gateway API deployments.
• Balance of Standardization and Flexibility: The Gateway API community actively collaborates to standardize common features while providing flexible extension mechanisms (e.g., policies, filters) that allow vendors to innovate and deliver unique features faster, fostering both interoperability and differentiation.
• Continuous Evolution with Exciting Features: The API is rapidly evolving with upcoming advancements like Endgate for Ingress migration, an Inference extension for ML workloads, standardized OAuth/AuthN/AuthZ, and advanced TCP/UDP route types, promising an even more powerful and versatile platform.

About the Speaker(s)

The panel comprised a diverse group of experts deeply involved in the development and implementation of the Gateway API and related cloud-native networking technologies:

• Kate Osborne is a software engineer currently working at Enro, where she contributes to their Kubernetes operator, which is an implementation of the Gateway API. Prior to joining Enro, Kate gained valuable experience working on the NGINX Gateway API implementation.
• Christine Kim focuses on open source developer experience at Isovalent, the company behind Cilium. She has been actively involved with the Gateway API community for some time, contributing to its development and adoption.
• Mike Morris serves as a product manager at Microsoft, working on their open upstream open source networking team. His primary areas of focus include the Gateway API and Istio, a popular service mesh.
• Spencer Hance is a software engineer at Google, where he has been working on GKE Gateway for several years. Before his work on GKE Gateway, Spencer was involved with GKE Ingress, providing him with a comprehensive understanding of Kubernetes traffic management solutions.
• Arko Dasgupta is a maintainer on the Envoy Gateway project, which is a subproject within Envoy that implements the Gateway API to manage north-south traffic. He is also a reviewer and contributor to the broader Gateway API project and works as an engineer at Tetrate, contributing to TEG, an enterprise offering of Envoy Gateway.