A Kubernetes Ingress Controller is the runtime component that implements Kubernetes Ingress rules and brings primarily HTTP/HTTPS traffic to cluster services. An API gateway is an API-focused reverse proxy and policy layer that commonly manages consumer authentication, throttling, quotas, transformations, routing, and API lifecycle concerns. One product can perform both roles, but the concepts are not identical.

There is also a third term that now matters: Kubernetes Gateway API. Gateway API is the successor to the Ingress API for modern Kubernetes service networking. It is a Kubernetes configuration standard, not the same thing as an API gateway product. Some API gateways and ingress technologies implement it.

What a Kubernetes Ingress Controller does

The Kubernetes Ingress resource describes rules that map external HTTP/HTTPS traffic to Services, usually by hostname and path. The resource does nothing by itself: an Ingress Controller watches those resources and configures a data plane such as a reverse proxy, cloud load balancer, or other traffic system.

The core Ingress API is intentionally small. Kubernetes documents it as providing external access to cluster services and potentially load balancing, TLS termination, and name-based virtual hosting. The Gateway API migration guide notes that the Ingress API's standardized features are primarily TLS termination and simple content-based HTTP routing.

Ingress controllers often provide much more than the core API through annotations, ConfigMaps, custom resources, or vendor-specific configuration. Depending on the implementation, that can include:

• TLS certificate handling and redirects.
• Header manipulation and URL rewrites.
• Authentication integrations.
• IP allow/deny rules.
• Rate limiting.
• WAF integration.
• Canary or weighted routing.
• Observability and access logs.

This implementation-specific flexibility is also why “Ingress Controller” does not describe one fixed security feature set. An NGINX, HAProxy, cloud-managed, Envoy-based, or vendor API-gateway controller can expose different capabilities while all supporting Kubernetes ingress patterns.

What an API gateway does

An API gateway also acts as a reverse proxy, but its design center is usually the API consumer boundary. Microsoft’s Azure Architecture Center describes an API gateway as routing client requests to backend services while offloading cross-cutting functions such as authentication, TLS/mTLS, IP restrictions, and client rate limiting.

Common API gateway capabilities include:

• OAuth/OIDC/JWT validation and client authentication.
• API keys, consumer identities, subscriptions, and usage plans.
• Per-consumer, tenant, route, burst, and quota controls.
• API version, stage, host, path, method, and backend routing.
• Request and response transformation.
• Protocol mediation or aggregation in some products.
• Schema/request validation and policy execution in some products.
• API analytics, developer portals, and API products in API-management platforms.
• Centralized external API logging and policy.

Not every API gateway includes full API management. Some are lightweight traffic gateways; others are complete lifecycle platforms. The right comparison is always against the exact controller and gateway implementation you plan to operate.

API gateway vs Kubernetes Ingress Controller

Gateway API changes the Kubernetes side of the comparison

Kubernetes recommends Gateway instead of Ingress because the Ingress API is frozen. “Frozen” does not mean removed: Kubernetes states that Ingress remains generally available with stability guarantees and that there are no plans to remove it. It means no new features are being added.

Gateway API addresses several Ingress limitations. Its migration guide identifies three major improvements: clearer personas/ownership, a broader standardized feature set, and structured extensibility rather than heavy reliance on implementation-specific string annotations.

Key Gateway API resources

• GatewayClass: identifies a class of gateway implementation and its controller.
• Gateway: defines listeners and the traffic entry point controlled by an infrastructure or cluster operator.
• HTTPRoute: defines HTTP routing rules and can be owned by application teams.
• GRPCRoute, TCPRoute, UDPRoute and TLSRoute: protocol-specific routing resources according to release/channel support.
• ReferenceGrant: controls permitted cross-namespace references.

As of September 2026, Gateway API v1.6 is the current major release line documented by Kubernetes; the v1.6.0 release graduated TCPRoute and UDPRoute to Standard. The Gateway API project also publishes conformance information so teams can compare which implementations actually support which profiles and features.

Gateway API is not an API gateway product

The Gateway API FAQ is explicit: Gateway API is a set of Kubernetes resources for service networking, while an API gateway is a tool that exposes application APIs through a managed interface and can centralize authentication, authorization, and request limits. Some API gateway products can be programmed through Gateway API.

That distinction prevents a common architecture mistake: migrating from Ingress to Gateway/HTTPRoute improves the Kubernetes networking model, but it does not automatically add API consumer management, subscriptions, schema policy, sensitive-data detection, or a developer portal.

Security responsibilities by layer

Ingress/Gateway layer: cluster entry and traffic safety

The Kubernetes traffic entry layer should provide a hardened public/private listener, current TLS, supported software, safe routing, namespace/RBAC boundaries, request-size and timeout controls, and controller-specific protections. Restrict who can modify routes, listeners, certificates, and privileged extensions.

If the controller allows arbitrary snippets, plugins, or annotations that affect generated proxy configuration, treat those as privileged code/configuration paths. Gateway API's structured resources reduce some annotation dependence, but implementation-specific extensions still need governance.

API gateway layer: consumer and API policy

The API gateway is well placed to validate public/partner identity, enforce per-consumer quotas and rate limits, normalize requests, and centralize declared API policy. The per-user rate limiting guide explains why identity-, tenant-, route-, and cost-aware limits are stronger than one IP-based threshold.

Application layer: definitive business authorization

Neither Ingress nor an API gateway should be the only control for resource ownership and changing business state. A backend service should still determine whether the authenticated principal can access the requested object, invoke the function, modify the field, or perform the transaction.

Runtime layer: behavior and response context

A request can pass TLS, JWT validation, route policy, and rate limits and still be abusive. Valid users can probe object identifiers, extract data gradually, call workflows in abnormal sequences, or trigger expensive operations within static thresholds.

For that layer, runtime API security complements ingress and gateway policy with request/response inspection, API discovery, behavioral context, sensitive-data visibility, and security evidence.

Common deployment patterns

A clean responsibility flow

API consumer
    |
    | OAuth/JWT, API key, quota, consumer policy
    v
API Gateway
    |
    | trusted identity / request context
    v
Kubernetes Gateway or Ingress data plane
    |
    | host/path/service routing
    v
Application Service
    |
    +-- object + function + business authorization
    +-- response minimization

Runtime API monitoring observes supported traffic where application
requests and responses are available.

You do not need all four logical layers in every environment. The point is to assign ownership explicitly. One product can implement several boxes if it provides the required controls and the operating model remains clear.

2026: migrating from Ingress and Ingress-NGINX

The biggest current migration issue is specific to the community Ingress-NGINX project. Kubernetes announced its retirement in November 2025 and states that it was retired on March 24, 2026. Existing deployments continue to function, but there are no further project releases, bug fixes, or security updates.

If you use Ingress-NGINX, continuing to run the existing binary is therefore materially different from continuing to use the Kubernetes Ingress API with a maintained controller. Kubernetes recommends moving Ingress-NGINX users to Gateway API or another maintained Ingress controller.

Inventory before translating manifests

Migration is not a simple YAML rename. Ingress-NGINX commonly used annotations, ConfigMaps, snippets, defaults, and controller-specific behaviors that may not map one-for-one to a new implementation. Kubernetes' migration guidance specifically warns that implementation-specific features require implementation-specific conversion.

• List all Ingress and IngressClass objects.
• Identify the actual controller image/version and ownership.
• Inventory every annotation and ConfigMap setting.
• Record TLS secrets, redirects, rewrites, auth integrations, IP rules, timeouts, request limits, and canary behavior.
• Capture externally observable behaviors before migration: status codes, redirects, headers, cookies, source IP forwarding, TLS, timeouts, and body limits.
• Map rules to Gateway/HTTPRoute or the target controller.
• Test shadow/canary traffic and rollback before changing DNS/load-balancer ownership.

Kubernetes released ingress2gateway 1.0 in March 2026 to assist with converting Ingress configuration to Gateway API. Treat generated output as migration assistance, not proof of equivalent runtime behavior.

Do not migrate security assumptions blindly

An old annotation may have enforced authentication, a body-size limit, a WAF hook, a rate limit, or source-IP handling. If it has no direct target equivalent, decide where that control will live instead of silently dropping it. Use regression tests for security headers, unauthorized requests, oversized payloads, routing conflicts, TLS modes, and admin paths.

The Kubernetes API runtime visibility guide is useful after cutover because it focuses on what endpoints and data are actually exposed through ingress and east-west paths.

Decision guide: what should you deploy?

Evaluation questions for an ingress/Gateway API implementation

• Is the project/vendor actively supported and how are security fixes delivered?
• Which Gateway API version, profiles, route types, and conformance tests are supported?
• How are cross-namespace routes and secrets authorized?
• Which controller-specific policies still require CRDs or annotations?
• How are TLS, client IP, proxy protocol, HTTP/2/HTTP/3, WebSocket, and gRPC handled?
• What request/header/body/time/concurrency limits can be enforced?
• How is high availability designed and how are upgrades rolled back?

Evaluation questions for an API gateway

• Which identity methods are native: OAuth/OIDC/JWT, mTLS, API keys, custom auth?
• Can limits be keyed by user, app, tenant, route, subscription, and cost?
• Does it support the protocols your APIs actually use?
• Are transformations, schema validation, API versions, and lifecycle workflows required?
• Does it expose Gateway API resources if Kubernetes-native ownership matters?
• Can request identity and trace context be passed safely to backend services?
• Does it preserve enough request/response context for security operations?

Common mistakes

Production checklist

Authoritative references

Separate Kubernetes traffic entry from API consumer governance

Ingress Controllers and API gateways overlap because both are reverse proxies at application boundaries. The useful architectural distinction is intent: Kubernetes ingress/Gateway resources describe how traffic reaches cluster services, while API gateways commonly add consumer-aware API policy and management.

For new Kubernetes networking, evaluate Gateway API rather than building new dependencies on a frozen Ingress feature model. If you run Ingress-NGINX specifically, plan migration because the project is retired. In every design, keep application authorization authoritative and make sure runtime API behavior remains visible after the traffic path changes.

Frequently asked questions