What shortcomings of the Kubernetes Ingress resource is the Gateway API designed to fix?

## The annotation problem The `networking.k8s.io/v1` `Ingress` resource expresses exactly one thing: for a given host and path, send traffic to a Service port. Everything else real production traffic needs — rewriting the path before it reaches the backend, splitting 5% of traffic to a canary, routing on a header, setting a timeout or body-size limit, enabling sticky sessions, adding CORS, forcing HTTPS redirects — has no field. Controllers solved this the only way they could: annotations. In practice an Ingress in a mature cluster is three lines of `spec` and fifteen lines of `nginx.ingress.kubernetes.io/...` or `alb.ingress.kubernetes.io/...` keys. Annotations are free-form strings on metadata. The API server cannot validate them, so a typo silently does nothing; there is no schema, no `kubectl explain`, and no defaulting. They are per-implementation, so an Ingress written for one controller is not portable to another — the `spec` moves, the behaviour does not. And because some annotations rewrite request paths or inject configuration snippets, they have been a recurring source of security findings when untrusted tenants can set them. The Gateway API's answer is to make the common cases typed API fields. Path rewriting is a `URLRewrite` filter. Header manipulation is a `RequestHeaderModifier` filter. Traffic splitting is a `weight` on each `backendRef`. Header, method and query matching are structured `matches`. Mirroring is a `RequestMirror` filter. These are validated by the API server, discoverable, and portable across conformant implementations. ## The ownership problem A single Ingress object contains the TLS Secret reference, the public hostname, the class selection, and the application's path rules. In a shared cluster those belong to different people. Because Kubernetes RBAC grants on resource kinds, not on fields, you cannot say "developers may edit paths but not `spec.tls`". Platform teams therefore either accepted the risk or built admission webhooks and templating layers to fake field-level control. Gateway API splits the object along ownership lines. The cluster operator owns the `Gateway` — listeners, ports, hostnames, certificates — and declares in `allowedRoutes` which namespaces and route kinds may attach. Application teams own `HTTPRoute` in their own namespace and reference the Gateway with `parentRefs`. Attachment is two-sided: the route must ask, and the listener must permit. Standard RBAC now expresses exactly the intended permission, with no webhook required. ## The scope problem Ingress models HTTP and HTTPS. Anything else — raw TCP, UDP, or TLS passthrough — was done with per-vendor ConfigMaps or extra Services. Gateway API keeps one listener model and layers protocol-specific route kinds on top: `HTTPRoute`, `GRPCRoute` (GA), and the experimental `TCPRoute`, `UDPRoute` and `TLSRoute`. A single Gateway can carry listeners for several protocols. ## The extensibility and observability problems Gateway API defines conformance levels — Core, Extended, Implementation-specific — so implementations advertise which typed features they support instead of inventing parallel annotation dialects. Implementation-specific behaviour still exists, but it is expressed through `ExtensionRef` filters and `parametersRef` that point at real, schema-bearing CRDs. Policy attachment lets cross-cutting concerns be modelled as separate objects targeting a Gateway or a route. Status is the other quiet improvement. Ingress status carries little more than a load-balancer address, so failures like "this controller ignored your object" or "your TLS Secret is missing" surface only in controller logs. Every Gateway API resource carries conditions: Gateways report `Accepted` and `Programmed` per listener plus `attachedRoutes`; routes report `Accepted` and `ResolvedRefs` per parent, with reasons such as `NotAllowedByListeners`, `NoMatchingListenerHostname` and `BackendNotFound`. Debugging becomes a `kubectl describe` instead of log archaeology. ## What Gateway API does not fix It is still CRDs you install and a controller you operate; it does not remove the data plane or its capacity planning. Not every implementation supports every Extended feature, so real portability requires checking conformance. And there is genuine cost: more objects, more indirection, and a migration for every existing Ingress. For a small single-team cluster with one hostname and simple paths, Ingress remains perfectly adequate — it is frozen, not deleted, and its long install base means it will be served for years.