Ingress is one of the most widely used resources in Kubernetes. This component is responsible for infrastructure and applications, and helps expose applications and services outside the cluster. However, Kubernetes networking technology has come a long way, and many new use cases soon exposed the limitations of Ingress.

The Ingress API doesn't provide the advanced load balancing capabilities that users want to define, and it's pretty impractical for users to manage. Vendors have attempted to extend the platform by using annotations to address these additional use cases, but this has resulted in inconsistent implementations between vendors.

As such, the Gateway API has created a collection of new resources and APIs that will improve and possibly replace Ingress in the future.

The Gateway API divides the Ingress functionality into 3 components, each responsible for its own part, as described below. Additionally, the Gateway API adds other valuable functionality. Many downstream implementers and integrators of the Gateway API are in public preview and are iterating rapidly.

In addition to this Envoy also announced their Envoy Gateway to standardize Kubernetes Ingress.

The old way - Ingress

Using the security best practice is to expose the API through Ingress, you should configure the ingress service before connecting to the load balancer. This means that Ingress includes ingress controller details (configured by the platform administrator) and application routes (configured by the developer).

New way - Gateway API

1. Architecture

GatewayClass -> Gateway -> [*]Route

GatewayClass is provided by a platform/infrastructure provider such as Istio or Google Cloud.

Gateway is an instance of the gatewayClass defined by the platform/cluster administrator that binds the gateway to the LoadBalancer.

*Route is used to bind a route to a gateway (multiple routes can be configured to a gateway). Available at the TCP/IP layer:

• HTTPRoute - can route both HTTP and HTTPS
• TLSRoute - Route TLS and routes based on parameters in the TLS layer and SNI (Server Name Indication)
• TCPRoute - Route based on TCP destination port
• UDPRoute - Route based on UDP destination port

2. Advantages

Advantages of using the new way:

(1) New features have been added to the Gateway API:

• HTTP header-based matching
• HTTP header manipulation
• Weighted traffic split
• Traffic mirroring
• Role-Oriented Resource Model

(2) Gateway API also supports extensions:

• route to other protocols
• Arbitrary backend CRDs, such as buckets, functions, etc.
• Custom parameters and configuration (LB algorithm, custom matching)
• New approach decouples infrastructure from applications

Looking to the future

The Gateway API supports more sophisticated LB features such as weighted traffic splitting and HTTP header-based matching and manipulation. This feature is still in development, and many vendors have started to provide experimental support, so expect the Gateway API to move forward steadily.

Original: https://nonamesecurity.com/blog/the-new-way-to-expose-apis-in-kubernetes-cluster