Introducing ingress2gateway; Simplifying Upgrades to Gateway API

In the dynamic realm of Kubernetes, networking is crucial for effective service exposure. The Ingress API, familiar to many Kubernetes users, is key for managing external access to services within the cluster. Despite its usefulness, Ingress has limitations, which can become bottlenecks as applications grow in complexity and Kubernetes clusters face increased demands.

Here are some limitations:

Insufficient common denominator
Inadequate permission model
Lack of protocol diversity

Gateway API

The Gateway API enhances traffic management in Kubernetes. Approaching GA (General Availability) release, it standardizes Kubernetes API for ingress traffic, offering extended functionality and flexibility. Focused on modular resources, it supports diverse routing configurations. Transitioning from Ingress API, Gateway API excels in flexibility and power, built on core principles: role-oriented, portable, expressive, and extensible.

A role-oriented approach

The Gateway API employs a role-oriented strategy, aligning with traditional roles within organizations configuring Kubernetes service networking. This approach facilitates collaboration among infrastructure engineers, cluster operators, and application developers in addressing various aspects of the Gateway API. Infrastructure engineers deploy GatewayClasses, serving as templates for Gateways, defining behavior for robust service networking. Cluster operators then utilize these GatewayClasses to deploy gateways, bridging external traffic to Kubernetes-aware destinations. Gateways define load balancer configurations, while Route resources managed by application developers handle protocol-specific rules for mapping requests to Kubernetes Services. HTTPRoutes, for instance, are used for multiplexing HTTP or terminated HTTPS connections, allowing for inspection and modification of HTTP streams, such as routing based on HTTP headers.

Portability

With over 20 API implementations, the Gateway API aims for greater portability across various clusters and environments, minimizing reliance on non-portable annotations. This enhances consistency and ease of management across multiple clusters compared to Ingress. The Gateway API pledges support for the latest five Kubernetes minor versions, currently accommodating Kubernetes 1.24+.

Expressiveness

The Gateway API offers standardized Kubernetes support for various features including header-based matching, traffic splitting, weight-based routing, request mirroring, and others. In contrast, Ingress requires custom provider-specific annotations for these functionalities.

Extensibility

The Gateway API prioritizes extensibility, allowing users to link custom resources within its framework for tailored configurations without complicating the main structure. This enables precise adjustments, particularly valuable in complex cloud-native environments. Unlike Ingress, the Gateway API offers a standardized extension pattern and a broader set of features, enhancing expressiveness and adaptability.

Upgrading to Gateway

Migrating from Ingress to Gateway API might appear daunting, but Kubernetes recently introduced a tool to streamline this process. The ingress2gateway tool facilitates migration by converting your current Ingress resources into Gateway API resources. To begin using Gateway API and ingress2gateway, simply click the link provided below.