The Future of Kubernetes Networking Technology: Spotlight on Gateway API

The Ingress resource is one of Kubernetes’ many success stories. It has spawned a diverse ecosystem of Ingress controllers that are deployed in hundreds of thousands of clusters in a standardized and consistent manner. This standardization made it easier for users to adopt Kubernetes. However, five years after the introduction of Ingress, signs of fragmentation into various but strikingly similar CRDs and overloaded annotations have emerged. The same portability that made Ingress so widespread also limited its future.

It was at Kubecon 2019 in San Diego when a passionate group of contributors gathered to discuss the evolution of Ingress. The discussion extended into the hotel lobby across the street, and the outcomes were later known as the Gateway API. This discussion was based on some fundamental assumptions:

1. The API standards underlying route matching, traffic management, and service exposure are commoditized and offer little value to their implementers and users as custom APIs.
2. It is possible to represent L4/L7 routing and traffic management through shared core API resources.
3. It is possible to provide extensibility for more complex features without sacrificing the user experience of the core API.

Introduction to the Gateway API

This led to design principles that allow the Gateway API to improve upon Ingress:

• Expressiveness - In addition to HTTP host/path matching and TLS, the Gateway API can express capabilities such as HTTP header manipulation, traffic weighting and mirroring, TCP/UDP routing, and other features that were only possible in Ingress through custom annotations.
• Role-oriented Design - The API resource model reflects the separation of responsibilities common in routing and the Kubernetes service network.
• Extensibility - The resources allow arbitrary configuration attachments at various levels within the API. This enables granular customization at the most appropriate points.
• Flexible Conformance - The Gateway API defines different levels of conformance - core (mandatory support), extended (portable if supported), and custom (no portability guarantee), collectively known as flexible conformance. This promotes a highly portable core API (like Ingress) while still offering flexibility for implementers of Gateway controllers.

With the introduction of the Gateway API, developers and DevOps teams can now benefit from a more flexible and powerful networking technology. ayedo supports you in leveraging these new possibilities and integrating them into your Kubernetes environments.

Source: Kubernetes Blog