Kubernetes Ingress, Is It Time to Say Goodbye? A Deep Dive into Gateway API 🚀

Aug 12, 2026

—

Hello! Are you operating services in a Kubernetes environment? If so, you’re probably very familiar with ‘Ingress,’ which connects external traffic to internal cluster services. Ingress has long served as Kubernetes’ standard gateway.

However, as services become more complex and requirements diversify, you might have had thoughts like these:

“I want to show a different page only to mobile users… 🤔” “Can’t I deploy a new version of the app to only 10% of traffic first? 🐦” “I want to send requests with a specific HTTP header to a different service… 🧐”

Implementing such advanced routing strategies is challenging with Ingress’s basic features alone. While some functionality is possible using annotations provided by each Ingress Controller, this leads to vendor lock-in and lack of standardization, resulting in poor portability.

It is at this point that Kubernetes’ next-generation networking standard, the Gateway API, emerges!

🧱 Limitations of Ingress: Why Do We Need Something New?

Before understanding the Gateway API, it’s crucial to clearly identify the limitations of the existing Ingress.

Limited Routing Rules: Ingress primarily supports only hostname and path-based routing as standard. Header, query parameter, and weight-based routing are not standard features.
Vendor-Dependent Configuration: As mentioned above, using advanced features requires reliance on specific Ingress Controller annotations like nginx.ingress.kubernetes.io/rewrite-target. This means all settings must be reconfigured when switching to a different Ingress Controller. 😩
Difficulty in Permission Management: Ingress resources are typically managed by cluster administrators or platform teams. However, when an application developer wants to modify routing rules for a specific path, they often have to modify a large Ingress YAML file, making permission separation difficult and posing a risk of conflicts.

To solve these problems, the Gateway API was born, designed to be more flexible, expressive, and role-based.

✨ The Emergence of Gateway API: What’s Different?

The Gateway API is a successor project to Ingress, maximizing management flexibility by separating networking configurations into multiple independent resources. Remember these three core components:

GatewayClass: A cluster-wide template. It defines what kind of load balancer (e.g., AWS LB, NGINX, Istio) will be used. (Primarily managed by cluster administrators) ☁️
Gateway: The actual instance of a GatewayClass. It defines specific IP addresses, ports, TLS settings, etc., and represents the load balancer itself. (Primarily managed by infrastructure operators) 🚪
HTTPRoute: Defines the actual routing rules. It contains application-level rules such as “send /login path to auth-service, and /api/v2 path to new-api-service.” (Primarily managed by application developers) 🗺️

The biggest advantage of this structure is Separation of Concerns. The infrastructure team provides a stable gateway via Gateway, and the development team only needs to focus on the HTTPRoute rules required for their services. They can work independently without encroaching on each other’s areas. 🤝

🎯 Key Features: Unparalleled Traffic Control Capabilities

Now, let’s look at real-world examples to understand why Gateway API enables “more granular control over traffic routing.”

1. Header-based Routing

Let’s assume you want to distinguish between mobile app users and web users and send them to different backend services. You can branch routing based on the User-Agent header.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: mobile-routing-example
spec:
  parentRefs:
  - name: my-production-gateway
  hostnames: ["example.com"]
  rules:
  - matches:
    - headers:
      - type: Exact
        name: User-Agent
        value: "MyMobileApp/1.0"
    backendRefs:
    - name: mobile-app-service
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: web-app-service
      port: 8080

The HTTPRoute above sends requests with the User-Agent header “MyMobileApp/1.0” to mobile-app-service, and all other requests to web-app-service. This is possible with standard features, without Ingress annotations!

2. Weight-based Routing for Canary Deployments 🐦

You want to deploy a new version of my-app-v2 and send only 10% of the total traffic to it first to test stability. Gateway API provides a standard weight field for this.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-deployment-example
spec:
  parentRefs:
  - name: my-production-gateway
  hostnames: ["api.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: my-app-v1 # Existing version service
      port: 80
      weight: 90
    - name: my-app-v2 # New version service
      port: 80
      weight: 10

This single setting is all it takes! The my-app-v1 service will receive 90% of the traffic, and my-app-v2 will receive 10%. No more reliance on complex additional tools or non-standard annotations. ⚖️

🌐 Overall Context: Why Switch to Gateway API?

While the power of individual features is important, the greater change brought by Gateway API is the standardization and portability of Kubernetes networking.

Role-based API: Clearly separates responsibilities and permissions between infrastructure and development teams, facilitating smoother collaboration and reducing errors.
Portability: All routing rules (headers, weights, etc.) are included in the standard specification. This means that even if you switch from NGINX Gateway Fabric to an Istio-based Gateway, the HTTPRoute definition can be largely reused. This frees you from vendor lock-in. 🌍
Expressiveness and Extensibility: In addition to HTTPRoute, it supports various protocols like TCPRoute, UDPRoute, and TLSRoute, and routing rules can be infinitely extended through custom filters.

Conclusion

Ingress remains an excellent tool for exposing simple web services. However, in today’s world, where microservice architectures are becoming complex and advanced features like canary deployments, A/B testing, and fine-grained traffic control are essential, the limitations of Ingress are clear.

The Gateway API is not merely a replacement for Ingress; it is a next-generation standard designed to meet the demands of modern cloud-native environments. While there’s no immediate need to replace all Ingresses, if you’re starting a new project or feeling the limitations of your existing system, it’s time to actively consider the Gateway API. ✨