The Kubernetes team graduated the Ingress API to general availability (GA) in the recent 1.19 release after it was first introduced in 2015.
The Ingress API is used to route external HTTP/HTTPS traffic to backend Kubernetes services. Even though the API had been in beta, it was widely used since it was the only way of doing path-based routing for external traffic into multiple services deployed on Kubernetes. The two primary changes that advance it to GA, as the article in the Google Open Source blog states, are the pathType and the IngressClass.
In their KubeCon/CloudNativeCon talk in November 2019, Christopher M Luciano(IBM) & Bowei Du (Google) presented a preview of the GA enhancements. They noted that the previous API was limited in scope to "ensure massive portability" and went on to explain the changes that went into the GA version. These limitations led to a proliferation of third party extensions and products - free and commercial - which had add-on features for routing, authentication, access control, rate limiting, and metrics collection. Some of these include HAProxy, nginx, Traefik, Kong, Ambassador, and Contour - to name a few. The Kubernetes project itself maintains the GCE (used by Google Kubernetes Engine) and the nginx controllers.
The Ingress controller is a component usually implemented by the cloud vendor for managed Kubernetes, which "fulfills" the Ingress - i.e., sets up the external traffic proxy usually by a load balancer and configures and syncs routing rules on it based on the Ingress config. When Kubernetes is deployed on cloud vendor platforms like GCP, AWS and AKS, the Ingress controller implementation is provided by the vendor and is backed by the cloud vendor's load balancer. One also has the option of using a third party Ingress controller like nginx or HAProxy.
In terms of routing, the pathType change expands the previously available configuration by allowing delegation to the underlying Ingress controller. Apart from delegating - by setting "pathType: ImplementationSpecific" - the possible values are Exact match and a Prefix match. This allows for a more flexible configuration and is mandatory in Kubernetes 1.19.
The IngressClass is a resource that encapsulates information about the controller and its configuration. The Ingress definition would then refer to this class, and this supersedes the older, non-standard kubernetes.io/ingress.class annotation.
Previously, Ingress configuration was extended using annotations and ConfigMaps. In their talk, Luciano and Du also mention that the key changes to the API were cleaning up the object model, some tweaks to the specification, and flexibility in terms of alternate backend types. The last point is about supporting alternate backends like storage buckets and not just Kubernetes services. One of the stated goals for the new version was to have standard mechanisms for vendor specific behavior via extension mechanisms. The Ingress API is meant to be generic and cloud-agnostic, and independent of the Ingress controller. Most of these features were included in the 1.18 release itself.
There are indications that the roadmap for Ingress would be to maintain this version as v1 while working on "either a V2 Ingress API or an entirely different API with a superset of features". "Gateway" is an open-source Kubernetes API that is "designed to evolve the capabilities of Ingress", which is possibly a step in that direction.