#Comparison Among Service, Ingress, Gateway API

The Alauda Container Platform supports multiple ingress traffic specifications in Kubernetes ecosystem. This document compares them (Service, Ingress, Gateway API) to help users make the right choice.

#For L4 (TCP/UDP) Traffic

Both LoadBalancer type Services and Gateway API (TCP/UDP Routes) can expose Layer 4 traffic externally. However, they differ significantly in their implementation approach and performance characteristics.

#LoadBalancer Service (Recommended)

Implementation: Kernel-space forwarding

• Traffic forwarding is handled directly by the Linux kernel (iptables/IPVS/eBPF)
• Minimal overhead and near-native performance

Advantages:

• High performance with low latency
• Lower CPU and memory overhead
• Battle-tested and mature technology

#Gateway API TCP/UDP Routes

Implementation: User-space proxy

• Implemented by Envoy Gateway (or other gateway controllers)
• Traffic must traverse from kernel space to user space and back
• Additional processing overhead in the application layer

Disadvantages:

• Performance degradation compared to kernel-space solutions
• Higher resource consumption (CPU/memory)
• Additional latency due to user-space context switching

#Recommendation

We recommend using LoadBalancer type Services for L4 traffic routing due to their superior performance and lower resource overhead. Reserve Gateway API for scenarios requiring advanced L7 features or when you need unified management of both L4 and L7 traffic within the Gateway API model.

Currently, we support LoadBalancer type services through MetalLB.

#For L7(HTTP/HTTPS) Traffic

While Ingress, GatewayAPI, can all expose L7 traffic externally, they differ in their capabilities.

#Ingress

Ingress is the standard specification adopted by the Kubernetes community and are recommended for default use. The Ingress is handled by ALB instances that are managed by the platform administrator.

#GatewayAPI(Recommended)

Gateway API is the next-generation routing standard for Kubernetes, designed to address the limitations of Ingress and provide more powerful, flexible, and standardized traffic management capabilities. Compared to Ingress, Gateway API offers the following advantages:

#1. Role-Oriented Design

• Clear separation of concerns: Infrastructure admin (GatewayClass, Gateway) vs. Application developer (Routes)
• Ingress mixes infrastructure and application concerns in a single resource

#2. Expressive Routing Capabilities

• Rich matching rules: HTTP headers, query parameters, methods, etc.
• Ingress is limited to host and path matching
• Built-in support for traffic splitting, mirroring, and advanced policies

#3. Protocol Support

• Native support for HTTP, HTTPS, TCP, UDP, gRPC, and TLS passthrough
• Ingress primarily focuses on HTTP/HTTPS only

#4. Extensibility

• Type-safe extension points through CRDs (e.g., HTTPRoute filters, policy attachments)
• Ingress relies heavily on vendor-specific annotations, leading to portability issues

#5. Cross-Namespace Routing

• Routes can reference Services in different namespaces (with ReferenceGrant)
• Ingress is typically limited to same-namespace references

#6. Multiple Listeners per Gateway

• A single Gateway can handle multiple ports, protocols, and hostnames
• Ingress typically requires one resource per configuration

#7. Portability and Standardization

• Vendor-neutral API with conformance tests
• Reduces lock-in and improves interoperability between implementations
• Ingress implementations vary widely in capabilities and annotations

#8. Attachment and Selection Model

• Routes explicitly attach to Gateway listeners via parentRefs
• Clearer relationships and easier troubleshooting
• Ingress uses IngressClass which is less flexible

Currently, we support GatewayApi through envoygateway.
for migration from ingress to gatewayapi please refer to migration guide