Ingress APIs manage external access to the services in a cluster, typically HTTP. This would generally be implemented as an API Gateway style of traffic routers that relay traffic to proxied services through a common entry point. The user would be left to control when and how to publish a service by using a declarative definition of the desired behavior (with YAML/JSON file).
While Kubernetes historically did have API resources that never saw the GA daylight, Ingress is unique. Ingress resources are heavily used by users, there is a rich eco-system of Ingress Controllers that implement the API, and the API debuted all the way back to 2015, as a beta feature in Kubernetes 1.1. Kubernetes 1.19 this is going to change that – Ingress is going GA!
Ingress – A Kubernetes cluster companion
Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource. An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting. An Ingress controller is responsible for fulfilling the Ingress, usually with a load balancer.
A great example of Kubernetes Ingress controller that is worth looking into and that leverages Envoy as its proxy is Project Contour. That tried to address, using CRDs the use cases shortcomings of the Ingress API.
Example: Project Contour Ingress Controller – Envoy based Ingress
Ingress V1 – What’s New:
- A new pathType field that can specify how Ingress paths should be matched.
- ImplementationSpecific (default): With this path type, matching is up to the controller implementing the IngressClass.
Implementations can treat this as a separate pathType or treat it identically to the Prefix or Exact path types.
- Exact: Matches the URL path exactly and with case sensitivity.
- Prefix: Matches based on a URL path prefix split by /. Matching is case sensitive and done on a path element by element basis.
- A new IngressClass resource (example below) that can specify how Ingresses should be implemented by controllers and can reference a custom resource with additional parameters. The new IngressClass resource provides a way to replace those notorious annotations used by different ingress controllers and that were not part of the API specification.
- Support for wildcards in hostnames
Many Ingress providers have supported wildcard hostname matching like *.foo.com matching app1.foo.com, but until now the spec assumed an exact FQDN match of the host. Hosts can now be precise matches (for example “foo.bar.com”) or a wildcard (for example “*.foo.com”). Precise matches require that the http host header matches the Host setting. Wildcard matches require the http host header is equal to the suffix of the wildcard rule.
– host: “*.foo.com”
– path: /foo/
– path: /bar/
The future of Ingress is Service APIs
The Service APIs capture the work that is currently underway on a new highly configurable set of APIs that will provide an alternative to Ingress in the future. The proposal draft for this exciting evolution is in this document. Ingress will not be deprecated, but it will be superseded by a different set of APIs and resources as an alternative in order to support more complex use cases.
Ingress APIs, a highly adopted core component of many Kubernetes users backed a rich eco-system of Ingress Controller that implemented the API, finally graduated to GA. The road ahead to refine and new use cases are already being paved with The Service APIs. With cleaner separation and role-based control for different personas and groups of users who consume Ingress together, specifically the application developers and operators, the future looks even more promising.