5 Reasons to Switch to the Calico Ingress Gateway (and How to Migrate Smoothly)

The End of Ingress NGINX Is Coming. What Comes Next for Production Clusters?

Why Ingress NGINX Is No Longer Enough

Ingress NGINX solved an important problem early in Kubernetes adoption, but its design shows its age in modern production environments.

Configuration relies heavily on controller-specific annotations, which makes behavior harder to reason about, harder to standardize, and difficult to port across environments. As deployments grow, annotation sprawl increases operational risk and creates friction between platform teams and application developers.

Ingress also lacks a clean separation of responsibilities. Cluster operators and developers often share the same Ingress resources, increasing the likelihood of misconfiguration and making it harder to enforce consistent policy at scale.

With the Ingress NGINX Controller approaching retirement, these limitations become more than inconveniences. Reduced maintenance and ecosystem support increase long-term risk, especially for organizations running business-critical workloads. Continuing to rely on Ingress NGINX means taking on ownership of that risk yourself.

This post explains why Gateway API is the future of Kubernetes ingress, and why platform teams are choosing Calico Ingress Gateway as their long term solution.

Reason 1: Ingress NGINX Is Being Phased Out and That Creates Platform Risk

Ingress has served the Kubernetes ecosystem well, but it was never designed to support the scale, complexity, and role separation that modern platforms require.

As Ingress NGINX approaches retirement, the challenges that teams have worked around for years become harder to ignore:

• Heavy reliance on controller specific annotations
• Inconsistent behavior across ingress implementations
• Limited extensibility for advanced routing and policy
• Blurred ownership between platform operators and application teams

Over time, these issues increase operational risk. Platform teams are left maintaining fragile configuration patterns while trying to standardize ingress behavior across many services and teams.

With reduced ecosystem support ahead, continuing to rely on Ingress NGINX means accepting long term ownership of that risk. Ingress is no longer just a configuration detail. It is now a platform decision with security, supportability, and operational consequences.

👉 Ready to make the switch? Talk to the Tigera team about your Ingress NGINX transition.

Reason 2: Gateway API Is the Future of Kubernetes Ingress

The Kubernetes Gateway API was created to address the shortcomings of Ingress and provide a durable foundation for service networking.

Unlike Ingress, Gateway API is built around a clear separation of responsibilities:

• GatewayClass defines platform wide behavior
• Gateway manages infrastructure and listeners
• HTTPRoute and related resources allow application teams to define routing safely

This model reduces friction between teams and enables consistent policy enforcement without sacrificing flexibility.

Gateway API also brings first class support for capabilities that previously required custom annotations, including traffic splitting, header based routing, cross namespace access controls, and multi protocol support. These features are part of the API itself, making configurations easier to reason about, audit, and evolve over time.

Because Gateway API is upstream and vendor neutral, adopting it reduces future migration risk and avoids lock in to controller specific behavior. It is not just an alternative to Ingress. It is the direction Kubernetes is moving for ingress and gateway traffic.

The remaining question is not whether to adopt Gateway API, but which implementation provides the safest and most operationally sound path forward.

Reason 3: Production Grade Envoy Built for Scale and Reliability

Calico Ingress Gateway is built on Envoy Proxy, one of the most widely adopted and battle tested proxies in modern infrastructure.

By delivering a 100 percent upstream, production hardened distribution of Envoy Gateway, Calico provides:

• High performance Layer 7 traffic handling
• Mature resiliency features such as retries, timeouts, and circuit breaking
• Native observability through Envoy telemetry
• Compatibility with the broader Envoy ecosystem

For teams coming from NGINX, this represents a significant step forward in both capability and consistency. Complex behaviors that once required fragile annotations become explicit, well defined configuration.

Just as important, Calico maintains strict upstream compatibility. This ensures long term stability and avoids the operational risk that comes from forks or proprietary extensions.

👉 Contact Tigera to see how Calico Ingress Gateway runs Envoy in production

Reason 4: Built In Security from the Edge to the Pod

Ingress is often the first line of defense for Kubernetes workloads, yet many ingress solutions treat security as an add on rather than a core concern.

Calico Ingress Gateway combines Envoy’s application layer controls with Calico’s proven network security capabilities to deliver end to end protection across Layers 3 through 7.

This includes:

• Web application firewall capabilities
• HTTP request filtering and inspection
• Anomaly detection at the edge
• Deep integration with Calico Network Policy

By unifying ingress security with cluster wide network policy, Calico enables a true zero trust model. Traffic is inspected, controlled, and enforced consistently from the perimeter to individual workloads.

This level of integration is difficult to assemble from standalone components and becomes increasingly valuable as environments grow in size and complexity.

Reason 5: A Supported Migration Path That Reduces Risk

Migrating from Ingress NGINX does not have to be disruptive.

Gateway API and Calico Ingress Gateway are designed to support incremental adoption. In many environments, teams can run existing ingress controllers alongside a new Gateway API implementation, validate routing behavior, and transition traffic gradually.

For organizations already using Calico, migration can often be handled using available tooling and documentation. For teams new to Calico, working directly with Tigera ensures that migration is planned, tested, and aligned with production requirements.

The goal is not just to replace Ingress NGINX, but to do so in a way that minimizes risk, preserves uptime, and sets a solid foundation for the future.

Make the Ingress Decision with Confidence

Ingress NGINX retirement has turned ingress into a strategic platform decision. Teams need a solution that is supported, secure, and aligned with where Kubernetes is going, not one that requires ongoing workarounds to keep running.

Gateway API provides the future-proof foundation Kubernetes was missing, and Calico Ingress Gateway delivers that foundation using proven, upstream Envoy technology with security built in from the start.

Whether you are already running Calico or evaluating your options for the first time, the path forward does not need to be risky or disruptive. With the right implementation and the right level of support, migrating away from Ingress NGINX can be a controlled and confidence-building step toward a more secure and scalable platform.