Kubernetes Ingress Migration for Better Traffic Control

If you’ve managed traffic in Kubernetes, you’ve likely worked with Ingress controllers. For years, Ingress has been the standard way to expose HTTP and HTTPS services. But in practice, it often came with trade-offs. Controller-specific annotations were required to unlock critical features, the line between infrastructure and application responsibilities was unclear, and configurations often became tied to the implementation rather than the intent.

Ingress NGINX Retirement Raises the Stakes

Recently, the Kubernetes community announced that Ingress NGINX will be formally retired, with only best-effort maintenance provided until March 2026. After that point, there will be no bug fixes, no security updates, and the project will move to read-only archival status. Any cluster still relying on Ingress NGINX after that date will be running an unsupported controller, which increases maintenance overhead and security risk.

For many organizations, now is the time to treat this as a high-priority project: inventory all clusters using Ingress NGINX, create a migration plan (test, convert, cut over), and avoid ending up in a reactive scramble as the March 2026 deadline approaches.

If the move from Ingress to the Gateway API once felt optional, this new timeline changes the situation. Depending on an aging data-plane component without active support creates operational challenges that organizations can no longer ignore.

🎥 Looking for guidance on what comes after NGINX Ingress?

These on-demand sessions cover both the strategy and the hands-on migration to Kubernetes Gateway API using Calico Ingress Gateway.

① Moving Beyond NGINX: Gateway API & Calico Ingress Gateway

Learn the safest, future-proof path away from NGINX Ingress using the Kubernetes Gateway API.

▶ Watch on demand

② Calico Demo: Switching from NGINX Ingress to Gateway API

See a real migration from NGINX Ingress Controller to Calico Ingress Gateway, including security and observability.

▶ Watch on demand

As part of Calico Open Source v3.30,(and now v3.31), 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. With v3.31, Calico’s networking foundations have become even stronger, offering improved data plane efficiency and simplified operations that further enhance Gateway API deployments. 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.

What’s New in Calico v3.31 and Why It Matters for Gateway API Users

While the Calico Ingress Gateway focuses on routing and traffic management, the underlying network data plane plays an important role in how efficiently and reliably traffic moves through the cluster. The release of Calico v3.31 introduces several improvements that strengthen the foundation for Gateway API deployments.

GA nftables data plane

Calico v3.31 makes the modern nftables data plane generally available. This provides better performance, more predictable behavior, and cleaner rule management compared to iptables. These improvements help ensure stable and consistent handling of both north-south and east-west traffic, especially in clusters with high ingress volume.

Simplified and Enhanced eBPF Mode

The eBPF data plane has been improved to make operations easier and reduce manual work. Calico now provides a template that defaults to eBPF, automatically disables kube-proxy when appropriate, and uses bpfNetworkBootstrap for smoother API server detection. These updates help deliver lower latency and a simpler, more streamlined networking setup for Gateway API users.

QoS, DSCP, and Traffic Shaping Enhancements

Calico v3.31 introduces bandwidth and packet-rate QoS controls along with more robust DSCP support. These capabilities help teams provide more predictable performance for services behind their Gateway API routes. Workloads that depend on consistent latency or quality of service, such as API backends or streaming systems, benefit directly from these improvements.

More Flexible NAT and Routing Behavior

Updates to NAT and routing behavior make configuration simpler and more reliable. Teams gain more control over source NAT and advanced routing patterns, which helps when working with service mesh, multi-cluster topologies, or complex north-south routing scenarios. These enhancements fit well with the Gateway API’s more expressive routing model.

Improved Observability

The Whisker observability layer in v3.31 includes performance improvements, IPv6 fixes, and UI refinements. These improvements make it easier to diagnose routing decisions, understand data plane behavior, and trace how traffic is handled by the Calico Ingress Gateway.

In short, Calico v3.31 strengthens the networking layer that carries Gateway API traffic. The combination of a modern data plane, simpler operations, and better visibility makes the transition from Ingress to Gateway API even more compelling.