Kubernetes Gateway API

Gateway API is an official Kubernetes project designed for L4 and L7 routing. It serves as the next generation of Kubernetes Ingress, Load Balancing, and Service Mesh APIs. It is designed to be generic, expressive, and role-oriented, supporting both North-South (Ingress) and East-West (Mesh) traffic using a shared configuration model.

Key design goals include:

• Role-oriented: Resources model organizational roles to balance distributed flexibility with centralized control.
• Portable: A universal specification supported by many implementations.
• Expressive: Supports advanced capabilities like header-based matching and traffic weighting natively.
• Extensible: Allows custom resources to be linked at various layers of the API.

The proposal for matching source and destination addresses on L4 APIs (GEP-735) has been Declined.

While an implementation existed in main prior to v0.5.0, it was removed because:

• It operated too much like WAF/firewall functionality, which is outside the project scope.
• There were no implementations championing the specific use case.

If you require this functionality, the maintainers suggest starting a new GitHub discussion or submitting a new PR with your specific use case and context.

The SEO Resilience Toolkit is a suite of tools designed to make the Gateway API documentation resilient to refactoring, file moves, and renames. It uses a Stable ID approach where every Markdown file is assigned a unique, permanent id in its frontmatter. This allows the system to track files even if their filenames or directory structures change.

Core components include:

• mkdocs_utils.py: The core engine for ID generation, frontmatter parsing, and link conversion.
• mkdocs_linking.py: A CLI wrapper for manual maintenance tasks.
• mkdocs_main.py: An MkDocs macros plugin providing the internal_link macro.

Sunbeam Proxy v0.2.0 implements the Kubernetes Gateway API v1.5.1 control plane and data plane. The following conformance profiles are exercised in the reports:

• GATEWAY-HTTP
• GATEWAY-GRPC
• GATEWAY-TLS

Note on support:

• Service mesh profiles: Not supported (skipped).
• TCPRoute & UDPRoute: Fully supported, but no conformance tests are currently available for them.

The proposal GEP-1282, which aimed to provide a structured way to describe backend capabilities (such as TLS details, Websocket support, or protocol disambiguation) within the Gateway API, has been Declined.

Reasons for Decline

• The scope was considered too large with too many cross-cutting concerns.
• For specific use cases involving TLS Backend Properties, this proposal is superseded by GEP-1897.

A TLSRoute is a specialized route type in the Gateway API that uses the Server Name Indication (SNI) attribute from a TLS handshake to determine the destination backend.

Unlike HTTPRoute which operates at Layer 7 (HTTP), TLSRoute is designed for non-HTTP TLS traffic or scenarios where end-to-end encryption is required.

Use cases include:

• Non-HTTP TLS services: Routing traffic for services like Kafka or Postgres that use TLS but are not HTTP-based.
• Direct Client-Certificate Authentication: When backends require direct client-side certificates (e.g., for OAuth).
• Traffic Convergence: Using a single LoadBalancer/IP to host multiple TLS services on the same port by differentiating them via SNI hostnames, reducing costs and complexity compared to using multiple TCPRoute or LoadBalancer services.

A GEP is intended for significant API changes and design decisions. The following are considered out of scope for the GEP process:

• Bug fixes
• Small changes (e.g., API validation, documentation updates, or minor fixups).

Note: Reviewers may determine that a change initially considered "small" actually requires a formal GEP.

GEP-1619 defines the concepts, terminology, and API specifications for Session Persistence within the Gateway API. It aims to establish a common language between implementations and provide a standardized way to configure how sessions are maintained across requests.

Key distinctions:

• Session Persistence: The mechanism used to ensure a client's requests are routed to the same backend for the duration of a session.
• Session Affinity: A related but distinct concept that this GEP intentionally does not define (it is reserved for a separate GEP).

Current Status: Experimental.