How Does Kubernetes Gateway API Replace Ingress?

TL;DR

Kubernetes Gateway API replaces Ingress with a more expressive, extensible, and role-oriented model built around GatewayClass, Gateway, and HTTPRoute. It separates infrastructure ownership from application routing and supports traffic splitting, URL rewriting, and weight-based load balancing without relying on large, controller-specific annotations. Read on to understand Ingress’s limitations, how Gateway API divides responsibilities, and which routing scenarios it handles.

Transcript

Hello everyone. My name's Abhishek. And welcome back to my channel. In today's video, let's explore what is Gateway API, why Gateway API, and most importantly, let's learn how to use Gateway API through some interesting demos. Specially for the demos, I prepared this GitHub repository. I'll share the link in the description. So, after watching the ... Read More

Key Insights

• Kubernetes north-south traffic is the flow that allows external users to reach pods and services inside a cluster. Kubernetes does not include a native load balancer component, so external load balancer providers integrate through controllers that watch Kubernetes resources.
• Ingress works by letting an engineer declare a backend service and an access path, after which an Ingress controller watches that resource and creates or configures a load balancer. External requests reach the load balancer and are forwarded to the relevant Kubernetes service.
• The Ingress specification is limited because it mainly communicates which service should be exposed and the path on which users can access it. It does not natively express many production requirements discussed in the presentation, including rate limiting, web application firewalls, redirects, or canary routing.
• Ingress annotations are a workaround that lets controller vendors expose features missing from the standard specification. The drawback is that annotations can become numerous, embed complex JSON inside YAML, change between controllers, reduce readability, and increase the learning burden for DevOps engineers.
• Controller-specific configuration reduces portability because ALB, NGINX, Traefik, and other Ingress controllers can use different annotations for similar behavior. Moving between controllers may therefore require engineers to study new documentation and rewrite configuration that is not represented by the common Ingress specification.
• Shared ownership is a problem when platform engineers and DevOps engineers must modify the same Ingress resource. Platform engineers may manage the Ingress class while application teams manage routing fields, leaving responsibilities mixed inside one file without a clear separation of concerns.
• Gateway API is a more expressive, extensible, and role-oriented approach to Kubernetes traffic management. Its design uses separate GatewayClass, Gateway, and HTTPRoute resources so infrastructure configuration and application routing can be assigned more cleanly to the teams responsible for them.
• Gateway API supports practical routing demonstrations that go beyond basic service exposure. The covered examples include a basic Gateway API deployment, splitting traffic between services, rewriting HTTP URLs, and applying weight-based load balancing for controlled request distribution.

Questions & Answers

Q: How does Kubernetes Gateway API replace Ingress?

Gateway API replaces the limited Ingress model with separate GatewayClass, Gateway, and HTTPRoute resources. This role-oriented structure separates infrastructure configuration from application routing while supporting traffic splitting, URL rewriting, and weight-based load balancing.

Q: Why does Kubernetes need a mechanism for north-south traffic?

Kubernetes handles service-to-service communication through its in-cluster network, but external users still need a way to reach pods and services. Because Kubernetes does not have a native load balancer component, providers integrate their load balancers through controllers.

Q: How does Kubernetes Ingress expose a service to external users?

A platform engineer or cluster administrator installs an Ingress controller, and a DevOps engineer creates an Ingress resource specifying a service and access path. The controller watches that resource and creates a public-facing load balancer that forwards matching requests to the relevant Kubernetes service.

Q: What are the main limitations of the Kubernetes Ingress specification?

The Ingress specification mainly identifies the service to expose and the path used to access it. It does not natively represent requirements discussed in the presentation such as rate limiting, web application firewalls, HTTP redirects, canary deployments, denial-of-service prevention, and URL rewriting.

Q: Why do Ingress controllers use annotations?

Annotations expose load balancer features that the standard Ingress specification cannot describe. They can configure behavior such as web application firewall integration or weight-based routing, but this moves important configuration into controller-specific fields.

Q: Why can Ingress annotations be difficult to maintain?

Production Ingress resources can accumulate many annotations for routing, security, and other load balancer features. Some annotations embed complex JSON inside YAML, making configurations lengthy, harder to read, and more difficult to understand.

Q: Why are Ingress configurations difficult to migrate between controllers?

Controllers such as ALB, NGINX, and Traefik can use different annotations for similar behavior. Changing controllers may therefore require engineers to study new documentation and rewrite configuration that is not represented by the common Ingress specification.

Q: How does Gateway API separate platform and application responsibilities?

Gateway API divides configuration among GatewayClass, Gateway, and HTTPRoute resources. This lets platform engineers manage infrastructure-related configuration while application teams manage routing, instead of requiring both groups to modify the same Ingress resource.

Summary & Key Takeaways

• Kubernetes handles service-to-service traffic through its in-cluster network, but external access requires another mechanism. Ingress controllers watch Ingress resources and configure public-facing load balancers that route requests to Kubernetes services. This approach solved north-south traffic management, but the standard Ingress specification remained limited as production requirements became more sophisticated.

• Ingress primarily identifies the service to expose and the path used to reach it. Requirements such as rate limiting, web application firewalls, HTTP redirects, canary deployments, denial-of-service prevention, and URL rewriting therefore moved into annotations. Large, controller-specific annotations made configurations harder to read, maintain, understand, and transfer between implementations.

• Gateway API provides a more expressive, extensible, and role-oriented alternative built around GatewayClass, Gateway, and HTTPRoute. These resources create clearer responsibilities for platform and application teams while supporting advanced routing scenarios. The demonstrations cover basic deployment, traffic splitting, URL rewriting, and weighted request distribution between Kubernetes services.