The Kubernetes networking landscape is shifting. The traditional Kubernetes Ingress approach is being complemented and, in some cases, replaced by a more powerful, flexible, and extensible standard: the Kubernetes Gateway API.
Kubernetes has become the go-to platform for orchestrating and managing containerized applications. A key aspect of Kubernetes that's crucial for the functionality of these applications? Networking.
But navigating the complexities of Kubernetes networking can often lead to roadblocks with Ingress, which is today's standard for managing outside traffic to cluster services, especially in complex environments where it can only do what's needed through custom annotations and the addition of Custom Resource Definitions (CRDs).
The Kubernetes Gateway API offers a promising leap forward. It provides a role-based, adaptable framework that aligns with organizational roles that use Kubernetes service networking and brings a new approach to managing Kubernetes traffic.
In this blog, we'll look at the limitations of Ingress and why the Gateway API could be the next big thing.
We'll also review the Kubernetes Gateway API key concepts and features, compare it to Ingress, and discuss how HAProxy Kubernetes Ingress Controller supports the Gateway API alongside other methods.
A Quick Overview of Kubernetes Ingress & CRDs
Exposing your Kubernetes applications is traditionally achieved through Kubernetes Ingress and Custom Resource Definitions (CRDs).
Ingress defines how to direct outside traffic to services inside a cluster, acting as an entry point for HTTP and HTTPS traffic. CRDs, on the other hand, extend the Kubernetes API, allowing you to create new types of resources that behave like standard Kubernetes objects, making them suitable for advanced and domain-specific configurations.
Ingress Limitations & Why the Gateway API
Ingress and Custom Resource Definitions (CRDs) each exhibit inevitable trade-offs.
Traditional Kubernetes Ingress, while functional, is often unsuited to complex environments. Limited traffic routing, a lack of extensibility, minimal role-based access control, constrained protocol support, and inconsistent implementations are all limitations that have held back Kubernetes Ingress.
CRDs, instead, offer boundless extensibility. However, they lack a common standard, resulting in a situation marked by flexibility rather than standardization.
To address these concerns, in 2019, the Kubernetes SIG-NETWORK group started the development of the Gateway API.
The Kubernetes Gateway API is a unified and extensible solution that seamlessly integrates with Kubernetes' native resources, caters to advanced use cases, introduces a role-oriented approach, and boasts portability.
The underlying idea is to avoid a one-size-fits-all approach and leverage the advantages of more comprehensive structures.
The Gateway API isn't just a step up from the traditional Ingress; it's a leap. It answers the call for a more capable, extensible, and secure solution for managing traffic in Kubernetes environments.
What is the Kubernetes Gateway API?
The Kubernetes Gateway API is a specification or standard managed by the SIG-NETWORK community that models service networking in Kubernetes. It is designed to improve Kubernetes service networking using flexible and role-based interfaces.
Since the Gateway API functions as a specification or standard, supporting projects and companies must adhere to it. This adherence promotes portability and reusability by ensuring multiple implementations have the same user interfaces.
Gateway API vs. Ingress
Ingress | Gateway API | |
Traffic Routing | Basic HTTP routing and advanced routing features are not natively supported. | Header-based matching, traffic weighting, typed routes, and different backend types. |
Extensibility | Achieved with custom annotations through a vendor-specific approach. | Allows users to define their own custom resources. |
Standardization | Individual implementations with inconsistencies across different Ingress controllers. | Universal specification that is supported across various implementations. |
Role-Based Access Control | Does not natively let different teams manage different configuration sections. | Allows individual teams to manage their traffic while cluster operators set the policies. |
Protocol Support | To expose non-HTTP services to the internet, different Kubernetes resources are needed. | Extensive protocol support. |
Security | Basic support for TLS termination. | Generally facilitates enhanced security controls which the cluster operators define. |
Gateway API Concepts
The Gateway API actively incorporates four key concepts: a role-oriented approach, portability, expressiveness, and extensibility.
These concepts create a flexible foundation for Kubernetes service networking, offering teams more control, advanced routing options, flexible configuration, and standardized traffic management for a Kubernetes cluster.
This approach makes it easier to use and tailor the Gateway API to your teams' specific needs while aiding better collaboration among different departments within your organization.
1. A Role-Oriented Approach
The Gateway API utilizes a role-oriented approach designed to synchronize with the typical organizational roles that interact with and configure Kubernetes service networking. As a result, platform engineers, operations engineers, and application developers can all handle various aspects of the Gateway API.
For example, platform engineers can be crucial in deploying gateway classes and establishing a solid foundation for service networking.
Operation engineers then leverage these gateway classes to deploy gateways, effectively managing and coordinating their placement within the available infrastructure.
Gateways can be scoped to specific spaces in the cluster, and assigned to different teams, ensuring seamless collaboration and organization.
Whether this structure is flexible enough to align with the diversity of real-world teams and their workflows or simple enough for the average team to implement is still unclear.
Some organizations may prefer the Ingress specification for its simplicity. In contrast, others may favor the Gateway API for its enhanced security and separation of duties.
2. Portability
The Gateway API prioritizes portability. It's a specification that supports multiple implementations, ensuring broad compatibility on the core features.
Vendors will continue to be able to add proprietary extensions in the Kubernetes Gateway API.
The portable design of the Gateway API is intended to avoid one of the unintended consequences of Ingress, which is the rapid growth of non-portable, vendor-specific annotations. Many Ingress users demanded missing capabilities in the Ingress API and turned to vendors to meet these needs.
The goal of the Gateway API is to provide advanced functionality while maintaining the universal nature of its specification, avoiding the need for such vendor-specific solutions. The Gateway API promotes standardization by actively integrating the most common features into a "Core" set, which vendors must implement. Additionally, vendors can build proprietary extensions on top of this base.
As the Gateway API evolves, it will be interesting to see how much this "Core" set satisfies common needs and to what degree vendors continue to add their unique features.
3. Expressiveness
The Gateway API standardizes a wide range of features, such as header-based matching, traffic splitting, and other capabilities that used to need custom annotations in Ingress.
4. Extensibility
The Gateway API offers the flexibility to link custom resources at different API layers, enabling precise customization for more advanced use cases.
Similar Articles:
Multi-Tenant Kubernetes Clusters with the HAProxy Kubernetes Ingress Controller
Run the HAProxy Kubernetes Ingress Controller Outside of Your Kubernetes Cluster
Gateway API Features
When managing network traffic in Kubernetes, the Gateway API promises a comprehensive set of features that add value in the context of modern infrastructures.
Classes
GatewayClasses formalize different kinds of load balancing implementations. They make it simple for users to understand the many capabilities accessible through the Kubernetes resource model.
This classification aims to provide users with various load balancing options and clarity and explicitness in what each option brings.
Gateways
Shared Gateways and cross-Namespace support allow the sharing of load balancers and Virtual IPs (VIPs) by enabling independent Route resources to attach to the same Gateway.
In practical terms, this means that teams, even those operating across different namespaces, can share infrastructure safely without requiring direct coordination. It's a valuable feature for promoting both efficiency and collaboration.
Routes
While Ingress is limited to HTTP routing, the Gateway API expands its support to include Typed Routes and different types of backends. This flexibility opens the door for the API to support various protocols, such as HTTP and gRPC, along with a range of backend targets.
Use Case of a Role-Oriented Approach
In a well-structured organization, each individual has roles and responsibilities. For the purpose of this example, we have the Platform Administrator and the Application Owner. They both interact with the Ingress resource, but each carries a unique set of duties.
The Platform Administrator configures the Ingress resource. On the other hand, the Application Owner manages the services linked to the backend.
In this specific situation, we're dealing with two applications: v2-service and v1-service, with v1-service residing at the root path and v2-service at /v2.
The issue arrives when it's time to move these applications to a live production environment. A question then arises: who's responsible for updating the YAML configurations? Is it the job of the Platform Administrator who handles the Ingress, or does it fall under the duties of the Application Owner who looks after the services?
This can cause confusion and delays in the production deployment process and can lead to conflicts between teams.
However, a solution has emerged: the Gateway API. It's designed to solve these challenges with a role-based design for Kubernetes service networking, maintaining a balance between distributed flexibility and centralized control.
The Gateway API allows shared network infrastructure, such as hardware load balancers, cloud networking, and cluster-hosted proxies, to be used by several independent teams, all following the guidelines and constraints set by cluster operators. This way, the production deployment process can run smoothly and efficiently.
Gateway API Pros & Cons
Pros
Enhanced Separation of Duties: The Kubernetes Gateway API fosters an improved delineation of responsibilities among different teams and roles. This structure allows each person to focus on their specific role, minimizing the possibility of meddling with or affecting the workflows of others.
Role-Based Access Control (RBAC): With RBAC support, the Kubernetes Gateway API simplifies segregating access and permissions on a role-by-role basis. This enables administrators to create refined access control, ensuring only those with the right authorization can manage and interact with specific resources.
Improved Service Control with ReferenceGrant: ReferenceGrant facilitates seamless communication across different namespaces. With Ingress, there's a risk of accidentally accessing out-of-scope resources, while ReferenceGrant requires explicit access permission. This design drastically reduces the chance of inadvertently interfering with components that are not relevant to your current work.
Reduced Risk of Errors: By leveraging the Kubernetes Gateway API, there is a lower likelihood of unintentionally impacting or modifying infrastructure parts outside your work's scope. Reducing the visibility of outside components minimizes the chances of introducing errors or disrupting critical services.
Cons
Installation and Version Compatibility: Compared to the plug-and-play nature of Ingress, the Kubernetes Gateway API is not as user-friendly straight out of the box. While this may seem inconvenient, consider that the development of the Gateway API will likely iron out these wrinkles over time.
Multiple Object Structure: The Kubernetes Gateway API is not a single object. It is composed of several separate elements, each with its own structure. This complexity offers more granular control and increased scalability, but it can intimidate new users.
Time Investment and Learning Curve: To successfully deploy the Gateway API, you'll need to sacrifice some time to learn how to assemble its various components. The API's detailed structure also necessitates a deeper understanding of Kubernetes' intricacies.
Overkill for Simple Requirements: The Kubernetes Gateway API might be more than you actually need for smaller organizations. Its advanced functionalities align with the needs of large-scale, complex companies. That said, don't dismiss the Gateway API if your current needs are modest. As your business grows and your requirements become more complex, the Gateway API might offer the scalability and flexibility you need.
HAProxy Kubernetes Ingress Controller Gateway API Support
The HAProxy Kubernetes Ingress Controller supports the new Gateway API, offering an evolved approach to routing in Kubernetes environments. This integration unlocks many advantages, such as improved functionality and enhanced control over traffic routing. It provides greater flexibility in handling TCP services, stepping beyond the traditional capabilities of Ingress.
One important aspect is that our support for the Gateway API encompasses all options. However, regarding routes, our current support is limited to TCPRoute. This focus ensures we deliver a top-tier, stable, dependable performance that exceeds industry standards.
The HAProxy Ingress Controller is a robust tool that uses the full capabilities of HAProxy, tailored explicitly for a Kubernetes environment. Being native to Kubernetes, it employs the Kubernetes API for HAProxy configuration.
In addition to our advancements with the Gateway API, we want to underline our unwavering commitment to Ingress and CRDs. Our support for these conventional resources remains a priority as we acknowledge their significance in your Kubernetes experience.
If you're interested in learning more about the power of the Gateway API and how it can revolutionize routing in your Kubernetes environment, register for our on-demand webinar - Gateway API: A New Approach to Routing in Kubernetes - and transform the way you work with Kubernetes.
FAQ
Gateway API vs. API Gateway (What’s the difference?)
Despite the similar name, an API Gateway is unrelated to the Kubernetes Gateway API. The Kubernetes Gateway API is a specific feature in the Kubernetes ecosystem, comprising a set of resources tailored for modeling and directing traffic within Kubernetes clusters.
On the other hand, an API Gateway is a centralized entry point for managing and routing API requests, functioning as a reverse proxy outside the Kubernetes cluster.
Will Ingress Disappear?
Certainly not. The Gateway API is an evolution of ingress. It provides Extended support and Custom extensions, enhancing traffic management without compromising existing Ingress support.
Gateway API vs. CRDs
The Gateway API is a specification for managing and modeling service networking in Kubernetes. Custom Resource Definitions (CRDs) is a Kubernetes feature that allows for the design of custom resources that act like standard Kubernetes objects.
While both the Gateway API and CRDs extend the Kubernetes functionality, their use cases and implementation methods are different.
The primary difference is that the Gateway API is tasked with routing traffic within Kubernetes, while CRDs allow for the design and management of custom resources to match the specific needs of an application or environment.
Conclusion
The Gateway API represents an evolution in Kubernetes service networking, providing capabilities that align with the needs of modern, complex deployments. It equips organizations with the tools to manage their traffic within Kubernetes environments efficiently and effectively, facilitating seamless operations and collaboration across various departments.
However, the suitability of this technology depends on whether it aligns with a specific organizational structure and successfully distributes workloads among different teams. Its effectiveness still needs to be seen. Some organizations might prefer the simplicity of the Ingress specification, while others opt for the Gateway API due to its enhanced security and clear separation of responsibilities.
Both approaches will likely serve their distinct purposes. The HAProxy Kubernetes Ingress Controller has the advantage of implementing Ingress, CRDs, and Gateway APIs. However, this comprehensive support might not apply across all vendors.
To delve deeper into the subject, register for our on-demand webinar, Gateway API: A New Approach to Routing in Kubernetes, and unlock a new perspective on routing in your Kubernetes environment.
Subscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.
