If you’ve managed traffic in Kubernetes, you’ve likely navigated the world of Ingress controllers. For years, Ingress has been the standard way of getting HTTP/S services exposed. But let’s be honest, it often felt like a compromise. We wrestled with controller-specific annotations to unlock critical features, blurred the lines between infrastructure and application concerns, this complexity didn’t just make portability more difficult, it sometimes led to security vulnerabilities and other complications.
As part of Calico Open Source v3.30, we have released a free and open source Calico Ingress Gateway that implements a custom built Envoy proxy with the Kubernetes Gateway API standard to help you navigate Ingress complexities with style. This blog post is designed to get you up to speed on why such a change might be the missing link in your environment.
The Situation: The Ingress Rut
The challenge with traditional Ingress wasn’t a lack of effort, since the landscape is full of innovative solutions. However, the problem was the lack of a unified, expressive, and role-aware standard. Existing ingress controllers were capable, implemented advanced features, however at the same time tied you to a specific project/vendor.
This meant:
- Vendor Lock-In: Migrating from one ingress controller to another became a painful exercise in translating a web of custom annotations. Configurations were tied to the implementation, not the intent.
- Blurred Responsibilities: Who owned the Ingress resource? Was it the platform team setting up load balancers and Transport Layer Security (TLS), or the application team defining routing paths? This ambiguity often led to confusion and operational friction.
- Limited Expressiveness: Core needs like traffic splitting, header-based routing, or even simple redirects often require non-standard, and sometimes fragile, workarounds.
- Security Gaps: Enforcing consistent security practices like TLS encryption and HTTPS redirects across a diverse set of applications and teams was often difficult and inconsistent or required too much effort and annotations.
Kubernetes Gateway API vs. Ingress: The Core Differences
| Feature | Ingress | Gateway API |
| Separation of roles | Primarily App Developers (but blurs roles) | Role-Based (Infra Providers, Dev Ops, Cluster Ops, App Developers) |
| Standardization | While Core Ingress CRDs are standard; Advanced features are vendor specific | Aims for standardization across features |
| Expressiveness | Basic (Host/Path) Advanced via Annotations | Rich (Traffic Splitting, Headers, etc.) |
| Protocol Support | Primarily HTTP/S | HTTP/S, TCP, UDP, TLS, gRPC |
| Extensibility | Primarily via Annotations | Defined Extension Points |
The Implication: Tied Hands and Increased Risk
This “Ingress rut” had tangible consequences. Platform teams struggled to enforce security standards and provide a consistent ingress experience. Application teams faced limitations or were forced to grapple with infrastructure details they didn’t need to. Reliance on vendor-specific annotations tied our hands, making our infrastructure less agile and more fragile. Ultimately, the complexity made it harder to ensure that all traffic was managed securely, increasing the overall risk profile.
The Resolution: Gateway API Meets Calico
Enter the Kubernetes Gateway API. It’s not just an “Ingress v2”; it’s a fundamental redesign, a community-driven future for Kubernetes. Its strength lies in:
- Standardization and Portability: It defines a core, standard way to manage ingress, reducing reliance on vendor-specific hacks.
- Role-Based Architecture: It introduces distinct resources GatewayClass, Gateway, and HTTPRoute (among others) that can be tied directly to organizational roles. Infrastructure teams manage the Gateway (the entry point), while application teams manage their HTTPRoutes (the routing rules).
- Richer Features: It natively supports advanced routing, traffic splitting, and filtering through standardized mechanisms.
The Outcome: Secure, Streamlined, and Standardized
Here are some of the advantages that implementing Calico Ingress Gateway and the Gateway API standard offers:
- Custom Envoy build: Calico Ingress Gateway is a custom built container that integrates Envoy Proxy in your cluster. This custom container allows us to deliver an enterprise grade, CVE hardened image with a minimal attack surface.
- Secure by Default: GatewayAPI defines TLS based policy, and routing designed for handling TLS procedures. Depending on your scenario you could either pass through or terminate and re-create a new TLS based connection to the backend.
- Clear Ownership: Platform and application teams have distinct responsibilities and resources, leading to smoother collaboration and reduced friction.
- Standardized & Portable: Calico Ingress Gateway is an implementation of official Kubernetes Gateway API via Envoy proxy, designed to simplify setup, deployment, and migration by avoiding vendor-specific annotations.
- Flexible & Powerful: We leverage advanced features like redirects natively, opening the door for more sophisticated traffic management strategies.
- Integrated: We bring Calico’s proven security and networking capabilities right to the edge, creating a unified control plane.
The Kubernetes Gateway API, brought to life by Calico v3.30’s Ingress Gateway and Envoy proxy, isn’t just an incremental improvement, it’s your gateway to the world of Gateway API. It’s time to move beyond “piles of annotations” and build a more robust, secure, and manageable future for your Kubernetes ingress.
