Kubernetes: Migrating from Ingress to Gateway API

Kubernetes has become the de facto standard for container orchestration. With the rise of microservices and cloud-native applications, managing network traffic within a Kubernetes cluster has become increasingly critical. The Ingress API has been the traditional solution for managing external access to services in Kubernetes. However, with the evolution of Kubernetes and the need for more advanced traffic management capabilities, the Gateway API has emerged as a powerful alternative. This post provides a detailed comparison of Gateway API and Ingress API, highlighting the advantages of Gateway API and offering recommendations for when to choose it over Ingress API.

Kubernetes Ingress API

The Ingress API in Kubernetes is an API object that manages external access to services within a cluster, typically HTTP and HTTPS routes. It defines rules for routing traffic to the appropriate services based on the request's host and path. Ingress controllers, which are typically third-party implementations, handle the actual traffic routing based on the Ingress resource. Ingress provides a single point of entry into a cluster or service, making it easier to manage applications and troubleshoot routing issues. Its primary functions are traffic load balancing, Secure Sockets Layer (SSL) termination, and name-based virtual hosting.

An Ingress is an alternative to creating a dedicated load balancer in front of Kubernetes services or manually exposing services within a node. It lets you flexibly configure routing rules, greatly simplifying your production environment.

Kubernetes Gateway API

Gateway API is an official Kubernetes project focused on Layer 4 (L4) and Layer 7 (L7) routing in Kubernetes. This project represents the next generation of Kubernetes Ingress, Load Balancing, and three separate personas and corresponding resources that they are expected to manage:

• Infrastructure Provider: This persona is responsible for providing and configuring the underlying network infrastructure, such as load balancers and network devices. They interact with GatewayClass resources, which define the capabilities and properties of a Gateway.

• Cluster Operator: This persona manages the Gateway resources, which represent the entry points for traffic into the cluster. They configure how the Gateways are implemented and how they interact with the underlying infrastructure.

• Application Developer: This persona defines the routing rules for their applications using various Route resources, such as HTTPRoute, TCPRoute, and GRPCRoute. They specify how traffic should be routed to their services based on various criteria.

Most of the configuration in Gateway API is contained in the Routing layer. These protocol-specific resources (HTTPRoute, GRPCRoute, etc.) enable advanced routing capabilities for both Ingress and Mesh.

The adoption of Kubernetes has driven the increased use of API gateways as organizations leverage the benefits of containerization and microservices architectures. API gateways enable efficient API management, scalability, and security in Kubernetes-based environments, making them a vital component in modern application development and deployment. Microgateways are increasingly used at the network edge to support the rise of microservices, edge computing, and the Internet of Things (IoT). They bring processing power and connectivity closer to data sources, reducing latency and congestion while enabling data aggregation, local processing, and security enforcement. They also facilitate communication between IoT devices and backend systems. Cloud-native API gateways have emerged to manage traffic in cloud-native environments, utilizing container orchestration platforms like Kubernetes and embracing cloud-native principles for scalability and resilience.

Advantages of Gateway API over Ingress API

Gateway API offers several advantages over Ingress API, making it a more powerful and flexible solution for managing network traffic in Kubernetes. Some of the key advantages include:

1. Enhanced Extensibility

Ingress API relies heavily on annotations for extending its functionality. However, annotations can be inconsistent and non-portable across different Ingress controllers. Gateway API, on the other hand, provides a standardized and extensible framework for adding new features and capabilities. It allows for custom resources to be linked at various layers of the API, enabling greater flexibility and customization. This extensibility makes it easier to integrate with service meshes, implement custom authentication mechanisms, and add advanced traffic management features.

2. Role-Oriented Configuration

Gateway API's role-oriented design allows for a clear separation of concerns between different personas involved in managing network traffic. This separation simplifies configuration and improves security by ensuring that each persona has the appropriate level of access and control. For example, cluster operators can define Gateway resources and policies, while application developers can focus on defining routing rules for their applications without needing to understand the underlying infrastructure.

3. Richer Functionality

Gateway API provides a richer set of features compared to Ingress API. It supports multiple protocols, including TCP, UDP, HTTP, and gRPC, natively within the specification. This multi-protocol support eliminates the need for custom controller extensions for non-HTTP traffic. Additionally, Gateway API offers built-in support for advanced traffic management capabilities such as traffic splitting, mirroring, request injection, and fine-grained metrics. These features enable more sophisticated traffic management strategies, such as canary deployments and A/B testing, without relying on vendor-specific extensions.

4. Improved Portability

Ingress definitions often rely on vendor-specific annotations and configurations, which can lead to portability issues when switching between different Ingress controllers. Gateway API establishes a common standard that works consistently across all compliant controller implementations. This portability ensures that your configurations can be easily migrated between different environments and reduces vendor lock-in.

5. Addressing Ingress API Limitations

Ingress API has several limitations that Gateway API addresses, such as its limited protocol support, limited traffic management capabilities, and lack of standardization. These limitations are discussed in detail within the advantages section above.

6. Resource Object Definitions

Ingress API and Gateway API differ significantly in their resource object definitions. Ingress API does not introduce new resource objects, while Gateway API introduces several new objects, such as GatewayClass, Gateway, HTTPRoute, TCPRoute, etc.. These new objects provide a more granular and flexible way to configure network traffic. For example, GatewayClass allows infrastructure providers to define the capabilities of a Gateway, while Gateway allows cluster operators to instantiate and configure Gateways. HTTPRoute, TCPRoute, and other Route resources enable application developers to define routing rules for their applications. This clear separation of concerns and the introduction of new resource objects contribute to the improved functionality and flexibility of Gateway API.

7. Five Motivations for Adopting Gateway API

There are five key motivations for adopting Gateway API over Ingress API:

• Need for more advanced routing features: Gateway API supports advanced routing features such as header-based routing and weighted routing for canary releases, which are not natively supported by Ingress API.

• Support for multiple protocols: Gateway API natively supports TCP and UDP, in addition to HTTP and gRPC, providing a more comprehensive solution for managing diverse traffic types.

• Scalability: Gateway API is designed to handle large-scale deployments and complex traffic patterns more efficiently than Ingress API.

• Better isolation mechanisms: Gateway API provides better isolation mechanisms between different applications and tenants, improving security and resource management.

• Alignment with the direction of Kubernetes and open standards: Gateway API is an official Kubernetes project and is aligned with the direction of Kubernetes and open standards, ensuring its long-term viability and compatibility.

Real-World Use Cases of Gateway API

Gateway API provides significant benefits in various real-world use cases, including:

• Microservices: In a microservices architecture, Gateway API can be used to manage traffic between different services, enforce security policies, and implement advanced traffic management strategies such as canary deployments and blue/green deployments. For example, you can use Gateway API to route traffic to different versions of a microservice based on HTTP headers or query parameters, enabling A/B testing or gradual rollouts of new features.

• Multi-Tenant Environments: Gateway API's role-oriented design and support for cross-namespace references make it ideal for managing traffic in multi-tenant environments. It allows different teams to share the same underlying infrastructure while maintaining isolation and security. For instance, you can use Gateway API to create separate Gateways for each tenant, with different policies and routing rules, ensuring that tenants cannot interfere with each other's traffic.

• Edge Computing: Gateway API can be used to manage traffic at the edge of the network, enabling efficient routing and load balancing for edge applications and devices. For example, you can use Gateway API to route traffic to edge nodes based on geographic location or device type, optimizing performance and reducing latency for edge users.

• API Gateways: Gateway API can be used to implement API gateways, providing a single entry point for all API requests and enabling features such as authentication, authorization, and rate limiting. For instance, you can use Gateway API to create an API gateway that enforces authentication for all API requests, protects against malicious traffic, and provides detailed metrics on API usage.

Adoption and Maturity of Gateway API

While Ingress API is still widely used, Gateway API is gaining increasing adoption in the Kubernetes community. Many Ingress controller providers are adding support for Gateway API, and several organizations are already using it in production environments. The Gateway API project is actively developed and maintained by the Kubernetes SIG-NETWORK community, ensuring its continued evolution and maturity.

However, as a relatively new addition to the Kubernetes ecosystem, Gateway API is still evolving. This means there might be fewer resources and less mature tooling compared with established solutions like Ingress controllers. Widespread adoption of the Gateway API is still growing, which can lead to compatibility challenges with existing deployments that rely on Ingress controllers. For those accustomed to Ingress controllers, the Gateway API introduces a new approach and terminology, potentially requiring a learning curve.

Migrating from Ingress API to Gateway API

Migrating from Ingress API to Gateway API can be done gradually. Several tools and resources are available to assist with the migration process, including:

• ingress2gateway Tool: This tool can automatically convert Ingress resources to Gateway API resources, simplifying the migration process.

• Migration Guides: Kubernetes documentation and various online resources provide detailed guides on how to migrate from Ingress API to Gateway API.

One key difference between Ingress API and Gateway API is the shift in personas involved in managing network traffic. The following table summarizes this shift:

This table highlights how Gateway API introduces a more granular and role-oriented approach to managing network traffic, with different personas responsible for different aspects of the configuration.

Conclusion

Gateway API offers several advantages over Ingress API, including enhanced extensibility, role-oriented configuration, richer functionality, improved portability, and addressing Ingress API limitations. Its adoption is growing rapidly, and it is becoming the preferred solution for managing network traffic in Kubernetes. While Ingress API may still be suitable for simple use cases with basic HTTP routing needs, Gateway API is recommended for organizations with more complex requirements.

Specifically, consider Gateway API if your organization has:

• Complex microservices architectures requiring advanced traffic management capabilities like traffic splitting, mirroring, and canary deployments.

• Multi-tenant environments where isolation and security between tenants are crucial.

• A need for multi-protocol support beyond HTTP and HTTPS.

• A desire for a more standardized and extensible framework for managing network traffic.

By choosing the right API for your needs, you can ensure efficient, secure, and scalable network traffic management in your Kubernetes environment.

Summary Table of Key Differences