Kubernetes Ingress and Gateway API solve a similar problem: routing traffic from outside a Kubernetes cluster to internal Services. The difference is how much routing they can handle natively and how the configuration is organized. Kubernetes Ingress is a stable API for basic HTTP and HTTPS routing. It works well for host-based routing, path-based routing, TLS termination, and exposing multiple Services through one entry point. The API is also frozen, which means it is generally available and will not be removed. It is well understood, widely deployed, but it is no longer receiving new features. Gateway API is the newer Kubernetes project for L4 and L7 routing. It separates infrastructure, gateway, and application routing concerns into different resources. It also provides native support for capabilities that commonly required controller-specific Ingress annotations, including header matching, traffic weighting, redirects, and request modification. In short, Kubernetes Ingress is often the simpler choice for established HTTP and HTTPS workloads. Gateway API is usually the better choice for new deployments, advanced Kubernetes traffic management, and multi-team platforms. The Kubernetes project recommends Gateway API for new development, while existing Ingress deployments can continue to run. The two APIs can also be used together during a gradual migration. What Is Kubernetes Ingress? Kubernetes Ingress is an API object that manages external access to Services, typically using HTTP or HTTPS. An Ingress resource defines rules that match hostnames and URL paths, then sends matching requests to backend Services. An Ingress resource is only configuration. It does not route traffic by itself. A Kubernetes ingress controller watches the resource and configures a load balancer, reverse proxy, or other data plane to fulfill the rules. How Kubernetes Ingress Works An Ingress resource commonly contains: Hostnames such as shop.example.com or api.example.com URL paths such as /, /products, or /api Backend Services and ports TLS configuration that references Kubernetes Secrets An ingressClassName that identifies the intended ingress controller The core Ingress API supports three path types: Exact matches the URL path exactly. Prefix matches a path prefix. ImplementationSpecific leaves matching behavior to the selected IngressClass. For example, an Ingress resource might route requests for example.com/store to a store Service and requests for example.com/api to an API Service. The controller then makes that configuration available through an external address. The important distinction is between the Kubernetes API and the implementation. The Ingress resource describes the desired routing behavior, while the ingress controller determines how that behavior is implemented. Different controllers can support different features and interpret controller-specific configuration differently. Common Kubernetes Ingress Use Cases Kubernetes Ingress is commonly used for: HTTP and HTTPS routing to Services TLS termination at the cluster edge Host-based virtual hosting Path-based routing Load balancing across the Pods behind a Service Exposing multiple applications through one external entry point This last use case is often the main reason teams adopt an Ingress controller. Instead of creating a separate external load balancer for every application, several Services can share one entry point. Limitations of Kubernetes Ingress Ingress has a deliberately narrow core API. It is centered on HTTP and HTTPS traffic and basic host and path matching. It does not expose arbitrary ports or protocols, so non-HTTP workloads generally use a NodePort or LoadBalancer Service instead. Ingress also has no portable, native model for many advanced traffic management features. Header-based routing, weighted traffic splitting, URL rewriting, redirects, authentication, rate limiting, and custom timeouts have often been added through annotations or controller-specific configuration. Annotations can be useful, but they create portability and operational challenges: The same annotation may not exist in another ingress controller. Two controllers may implement similar annotations with different behavior. Application manifests become coupled to a particular controller. Advanced configuration is harder to validate because it is stored as untyped strings. There is also a question of ownership. An Ingress resource combines the routing rules and much of the entry-point configuration into one object. In a shared cluster, application teams may need the platform team to make every routing change, or they may receive permissions that are broader than they need. What Is the Kubernetes Gateway API? Gateway API is an official Kubernetes project focused on L4 and L7 routing. It represents the next generation of Kubernetes Ingress, load balancing, and service mesh APIs. Gateway API is not an ingress controller or a proxy. It is a collection of Kubernetes resources that a Gateway API controller watches and implements. Like an Ingress resource, a Gateway resource has no effect until a compatible controller is installed. Gateway API is designed to be: Role-oriented, so different teams can manage different parts of the configuration Portable, so common routing behavior is not tied to one vendor Expressive, so advanced routing is represented by typed fields instead of annotations Extensible, so implementations can add capabilities at the appropriate layer How Gateway API Works Gateway API separates the configuration into resources with different responsibilities. GatewayClass describes a category of gateway and identifies the Gateway API controller that implements it. It is usually managed by an infrastructure or platform team. Gateway requests an instance of a GatewayClass and defines the network entry points through listeners. A listener can specify a port, protocol, hostname, and which Routes may attach to it. Cluster operators commonly manage Gateways. HTTPRoute describes HTTP routing behavior. It attaches to a Gateway through parentRefs, matches requests, and forwards them to backend Services through backendRefs. Application teams can manage HTTPRoutes in their own namespaces without needing permission to edit the shared Gateway. For example, a basic Gateway and HTTPRoute could look like this: The Gateway listener controls which Routes can attach through allowedRoutes. This provides a controlled handshake between the Gateway owner and Route owner. A cross-namespace Route-to-Gateway attachment is governed by the Gateway listener configuration. For other cross-namespace references, such as a Route pointing to a Service in another namespace, ReferenceGrant provides an explicit approval from the owner of the target namespace. Gateway API Routing and Traffic Management Gateway API provides typed resources and fields for traffic patterns that often required Ingress annotations. Depending on the Route type and implementation, Gateway API can support: Hostname and path matching Header, query parameter, and HTTP method matching Weighted traffic splitting between backend Services HTTP-to-HTTPS redirects URL rewrites Request and response header modification Request mirroring and other implementation-supported extensions Cross-namespace Route attachment with explicit listener permissions Weighted backendRefs are especially useful for canary releases and A/B testing. A Route can send most traffic to one Service and a smaller share to another, without encoding that behavior in a vendor-specific annotation. Gateway API also reports status conditions on Gateways and Routes. Those conditions can show whether a Gateway is programmed, whether a Route was accepted, and whether its backend references resolved. This gives platform teams a more consistent way to inspect the state of Kubernetes routing configuration. Gateway API Beyond HTTP Traffic Gateway API uses protocol-specific Route resources for different kinds of traffic: HTTPRoute handles HTTP and HTTPS traffic that is available for inspection. GRPCRoute provides idiomatic routing for gRPC traffic. TLSRoute can route TLS connections using the SNI hostname, including TLS passthrough scenarios. TCPRoute and UDPRoute can describe raw L4 forwarding when the required release channel and controller implementation support them. This gives Gateway API a broader model than Ingress for workloads such as gRPC services, databases, message brokers, DNS, and other TCP or UDP applications. Support for individual Route types and features varies by Gateway API bundle, release channel, and controller, so production teams should verify the conformance and implementation documentation before relying on a feature. Kubernetes Ingress vs Gateway API: Key Differences Ingress and Gateway API are both Kubernetes networking APIs, but they are designed for different levels of complexity. Resource Model and Architecture Ingress combines the entry point, routing rules, and TLS configuration in one resource. Gateway API separates those concerns across GatewayClass, Gateway, and protocol-specific Route resources. That separation allows a platform team to provide shared gateway infrastructure while application teams manage their own routes. Traffic Routing Capabilities Ingress provides basic hostname and path routing. Gateway API adds native support for header, query parameter, and method matching, weighted backends, redirects, rewrites, and header modification through typed fields and filters. The exact feature set still depends on the controller. Gateway API standardizes the configuration model, but it does not make every controller implement every optional feature. Configuration and Extensibility Ingress commonly relies on controller-specific annotations for advanced behavior. Gateway API uses structured resources, typed fields, filters, and defined extension points. This makes common routing behavior easier to understand and more portable. It also gives tools a consistent resource model to inspect and manage. Role-Based Management Gateway API is designed around three broad personas: Infrastructure providers manage the underlying networking infrastructure. Cluster operators manage Gateways and cluster-wide constraints. Application developers manage Routes that describe application traffic. These roles do not have to belong to three separate organizations. The value is that the API can represent separate ownership and Kubernetes RBAC boundaries when a platform needs them. Multi-Protocol Support Ingress is designed for HTTP and HTTPS. Gateway API supports HTTP, HTTPS, gRPC, TLS routing, and additional L4 Route types where supported by the release and controller. Portability Across Implementations Ingress itself is a portable Kubernetes API, but advanced behavior is often implemented through annotations that are specific to an ingress controller. Gateway API moves more common behavior into the API itself. That does not mean every Gateway configuration can be moved between controllers without review. Controller support, conformance profiles, implementation-specific extensions, and infrastructure assumptions still matter. The portability improvement is that the common configuration has a shared, typed model. Why Kubernetes Is Moving Toward Gateway API Moving Beyond Ingress Annotations Annotations helped ingress controllers support features that the original Ingress API did not describe. Over time, they became a second configuration language, with different syntax and semantics for different controllers. Gateway API provides native fields and filters for many common traffic patterns. This reduces the amount of routing behavior that has to be expressed as opaque, controller-specific strings. Standardizing Advanced Traffic Management Modern platforms often need more than “send this path to that Service.” Teams may need to route based on headers, split traffic during a canary release, redirect HTTP to HTTPS, rewrite a request before it reaches the backend, or mirror traffic for testing. Gateway API makes these patterns part of the Kubernetes resource model. That allows deployment tools, progressive delivery systems, policy tools, and platform templates to work from a common API. Separating Infrastructure and Application Responsibilities In a multi-team environment, the team that owns the load balancer may not be the team that owns the application. Gateway API lets the platform team define the shared entry point and constraints while application teams create Routes for their own Services. This provides centralized control over the infrastructure without forcing every application change through the infrastructure owner. Supporting Modern Kubernetes Networking Requirements Kubernetes platforms increasingly serve HTTP APIs, gRPC applications, service-to-service traffic, and non-HTTP workloads. Gateway API is designed to cover north-south traffic and, through the GAMMA (Gateway API for Mesh Management and Administration) initiative, service mesh use cases as well. The result is a broader Kubernetes networking model that can be extended as new traffic management requirements emerge. Ingress Controller vs Gateway API Controller An Ingress resource and a Gateway resource are both declarative configurations. Neither one routes traffic without a controller. An ingress controller watches Ingress resources, selects the resources intended for it, and configures a proxy, load balancer, or other data plane. It may also interpret annotations that are specific to that controller. A Gateway API controller watches GatewayClass, Gateway, and Route resources. It provisions or configures the data plane for accepted Gateways, attaches Routes according to listener rules, and reports status back to the Kubernetes resources. Gateway API standardizes the resource model, not the proxy implementation. A Gateway API controller is still required, and the selected controller determines which protocols, filters, policies, and extensions are available. When comparing implementations, check the controller’s conformance results and feature documentation. Two implementations may both support Gateway API while differing in their support for L4 Routes, filters, TLS behavior, policy attachment, or advanced traffic management. When Should You Use Ingress vs Gateway API? The choice between Ingress and Gateway API depends on the existing environment, routing requirements, and operating model. When Kubernetes Ingress Still Makes Sense Ingress remains a reasonable choice when: An existing deployment is stable and only needs basic HTTP or HTTPS routing. Hostnames, paths, and TLS termination cover the application’s requirements. The cluster is operated by one team and does not need separate infrastructure and application ownership. The selected ingress controller is supported and meets the organization’s security and operational requirements. There is no need to migrate a stable Ingress deployment solely because the API is frozen. Frozen means that the API is no longer adding features, not that existing resources stop working. The controller decision is separate. For example, teams using an ingress controller that is no longer maintained may need to migrate for operational and security reasons even if their Kubernetes Ingress resources are otherwise adequate. When to Consider Gateway API Gateway API is often the better starting point when: The Kubernetes deployment is new. The application needs header-based routing, weighted traffic splitting, redirects, rewrites, or other advanced behavior. Multiple teams share cluster networking infrastructure. Platform and application configuration need separate ownership and RBAC. The organization wants to reduce dependence on controller-specific annotations. The platform needs gRPC, TLS routing, or supported TCP and UDP use cases. If several of these conditions apply, Gateway API is usually worth evaluating before investing in a new Ingress-based design. Can Ingress and Gateway API Be Used Together? Yes. Kubernetes Ingress and Gateway API resources can operate in the same cluster. Depending on the implementation, one controller may support both APIs or separate controllers may be used. Using both APIs enables gradual adoption. Existing applications can continue using Ingress while new applications use Gateway API. Teams can also create a Gateway API configuration beside an existing Ingress, test it, and shift traffic after the new path has been validated. During an overlap, plan the entry points carefully. Avoid having two controllers claim the same hostname unintentionally, and decide whether the migration will use a second load balancer, a separate address, or a controlled DNS and traffic cutover. How to Migrate From Ingress to Gateway API Migration does not need to be a single cutover. A staged process reduces risk and exposes controller-specific assumptions early. Assess Existing Ingress Resources and Annotations Begin by inventorying the Ingress resources, IngressClasses, TLS Secrets, backend Services, and annotations in use. Pay particular attention to annotations for: Authentication and access control TLS redirects and certificate handling Timeouts and connection behavior Request and response headers URL rewriting Canary traffic and traffic splitting Source restrictions and rate limiting Classify each setting as a direct Gateway API mapping, an implementation-specific feature, or a behavior that needs to be redesigned. This is more useful than assuming every annotation has a one-to-one replacement. Map Ingress Configuration to Gateway API Resources A common structural mapping looks like this: IngressClass maps conceptually to GatewayClass. The external entry point becomes a Gateway with explicit listeners. Ingress rules become HTTPRoute resources. Backend Services remain backend references, usually in backendRefs. Cross-namespace backend references require an appropriate ReferenceGrant. One Ingress resource does not have to become one HTTPRoute. In a multi-team cluster, it may be better to split a large Ingress into application-owned Routes that attach to a shared Gateway. The Kubernetes SIG Network ingress2gateway project can generate a starting point for some migrations. Review and test its output carefully, especially when the original Ingress uses controller-specific annotations. Replace Controller-Specific Configuration Some common patterns have Gateway API equivalents: A canary weight can become weighted backendRefs. Header-based canary routing can become header matching in HTTPRoute. A URL rewrite can become a URLRewrite filter where supported. An HTTP-to-HTTPS redirect can become a RequestRedirect filter. Header additions and removals can become a RequestHeaderModifier filter. Other features may require a controller extension, a policy resource, or an application change. Verify support against both the installed Gateway API bundle and the chosen Gateway API controller. Test Routing and Traffic Policies Run the new Gateway API configuration alongside the existing Ingress path when possible. Validate: Gateway and Route status conditions Hostname and path behavior TLS certificates and redirects Header matching and modification Weighted traffic distribution Timeouts and connection handling Network policies and backend reachability Source IP and forwarded-header behavior Performance and error-rate baselines Gateway API status conditions can help identify whether a Route was accepted and whether its backend references were resolved. Observability from the selected controller and CNI can provide the remaining data-plane details. Migrate Incrementally Move one application or hostname at a time. Shift traffic gradually, monitor service-level objectives, and keep the original Ingress configuration available until the new path is stable. Remove the old Ingress resources only after the Gateway API routes have been tested under real traffic and the rollback plan is no longer needed. Using Gateway API With Cilium Cilium provides a Gateway API implementation that integrates gateway traffic with the Cilium networking, security, and observability stack. This is useful for teams that want Kubernetes routing, network policy, load balancing, and flow visibility to use the same underlying datapath. Cilium as a Gateway API Implementation Cilium Gateway API support includes core resources such as GatewayClass, Gateway, HTTPRoute, GRPCRoute, and ReferenceGrant. Additional resources and features depend on the Cilium or Isovalent Networking for Kubernetes release and the Gateway API CRDs installed in the cluster. Typical prerequisites include: The Cilium L7 proxy is enabled. It is enabled by default in the documented configuration. NodePort is enabled, or the kube-proxy replacement is configured. The required Gateway API CRDs are installed before enabling the feature. The environment supports a LoadBalancer Service, unless the Cilium L7 proxy is exposed through host networking. Always check the documentation for the installed Cilium release because supported Gateway API bundle versions and optional Route resources change over time. eBPF-Powered Kubernetes Networking Many Gateway API implementations run a proxy as a Deployment or DaemonSet and expose it through a Service. Cilium also uses Envoy for Layer 7 processing, but eBPF intercepts traffic arriving at the Gateway Service and transparently forwards it to Envoy through the kernel’s TPROXY facility. This ties Gateway API into the Cilium datapath instead of treating the gateway as an isolated networking component. It also affects source IP visibility. For Gateway API traffic, Cilium can preserve the source address as traffic reaches Envoy without requiring externalTrafficPolicy: Local solely for that purpose. Envoy also sets forwarded-address headers that many HTTP libraries handle transparently. TLS passthrough is different. With TLSRoute in passthrough mode, Envoy reads the SNI from the TLS handshake and opens a new TCP stream to the backend. The backend therefore sees the Cilium Envoy or node address as the source of that forwarded stream. Gateway API, Load Balancing, and Network Policies Cilium Gateway API traffic passes through a per-node Envoy proxy that can interact with the Cilium eBPF policy engine. This makes Envoy a network policy enforcement point for north-south Gateway API traffic. There are two logical policy steps to account for. Traffic from outside the cluster commonly has the world identity. Traffic arriving at Envoy for Gateway API is assigned the special ingress identity. Traffic then leaves Envoy toward the backend workload identity. As a result, a CiliumNetworkPolicy may need to allow both the world to ingress step and the ingress to backend step. Allowing only one can produce requests that reach the gateway but never reach the application. Observability With Cilium and Hubble Hubble provides flow-level observability for the Cilium datapath. It can help teams investigate DNS activity, policy drops, Layer 7 behavior, service dependencies, and network reachability. That visibility is valuable during a Gateway API migration. When a request fails, teams can investigate whether the Route was accepted, whether the gateway forwarded the request, whether policy blocked the world to ingress step, or whether the backend rejected the connection. Frequently Asked Questions Is Kubernetes Ingress deprecated? No. The Kubernetes Ingress API is stable, generally available, and has no plans for removal. It is frozen, which means that no new features are being added. Kubernetes recommends Gateway API for new development. This is separate from the status of any particular ingress controller. An unsupported controller may still need to be replaced even when the Ingress API itself remains stable. Does Gateway API replace Kubernetes Ingress? Gateway API is the newer API for Kubernetes traffic management and the recommended direction for new capabilities. It does not require every existing Ingress deployment to migrate immediately. Existing Ingress and Gateway API resources can run together while teams migrate incrementally. What is the difference between Gateway API and an ingress controller? Gateway API is a specification and a set of Kubernetes resources. An ingress controller is software that implements the older Ingress API. Gateway API also requires a controller to translate its resources into a working proxy, load balancer, or other data plane. Is Gateway API production ready? The core Gateway API resources, including GatewayClass, Gateway, and HTTPRoute, are in the Standard channel and are considered stable. Other Route types and features can have different support levels. Check the release channel and conformance information for the specific resource and controller you plan to use. Can Kubernetes Ingress and Gateway API be used together? Yes. They can operate in the same Kubernetes cluster, using one controller that supports both APIs or separate controllers. Teams commonly use this arrangement to validate Gateway API routes and migrate applications gradually. What is HTTPRoute in Kubernetes Gateway API? HTTPRoute is the Gateway API resource that describes HTTP routing behavior. It attaches to a Gateway through parentRefs, matches requests by properties such as hostname, path, headers, query parameters, or method, and forwards traffic to Services through backendRefs. How do you migrate from Ingress to Gateway API? Inventory existing Ingress resources and annotations first. Then map the configuration to a GatewayClass, a Gateway with listeners, and one or more Route resources. Replace controller-specific annotations with native fields or supported filters, validate the new path in parallel, and shift traffic incrementally. Summary Kubernetes Ingress and Gateway API both provide a way to route traffic into Kubernetes, but they target different levels of complexity. Ingress remains a stable and practical choice for existing applications with straightforward HTTP and HTTPS requirements. Gateway API provides a richer and more structured model for advanced Kubernetes routing, weighted traffic, multiple protocols, shared gateways, and separate platform and application ownership. For new Kubernetes deployments, Gateway API is usually the better starting point. For existing Ingress workloads, a gradual migration lets teams preserve stability while adopting a more expressive and portable traffic management model. With Cilium, Gateway API also becomes part of an eBPF-powered Kubernetes networking stack that includes load balancing, network policy enforcement, and Hubble observability.