Why Gateway API is the future of gateways in Kubernetes and service mesh ingress?

This article will take Kubernetes Ingress, Istio, and Envoy Gateway as examples to introduce you to the ingress gateway and Gateway API in Kubernetes, and introduce the new trend of Gateway API integrating Kubernetes and service mesh ingress gateways.

Viewpoint of this article

Ingress, as the first-generation ingress gateway of Kubernetes, its resource model is too simple to adapt to today’s programmable network;
Gateway API is the latest achievement of Kubernetes ingress gateway. It separates concerns through role division and provides cross-namespace support to make it more suitable for multi-cloud environments. It has been supported by most API gateways;
Ingress gateway (north-south direction) and service mesh (east-west direction, intra-cluster routing) have some overlapping functions, and the Gateway API provides a new reference model for the integration of the two;

History of Kubernetes Ingress Gateways

In June 2014, Kubernetes was open sourced. At first, only Service objects of type NodePort and LoadBalancer could be used to expose services in the cluster. Later, Ingress was born.
, Two years later (Kubernetes 1.2) the Ingress API entered the Beta version, and then in order to maintain its lightweight and portable features, the Ingress API developed slowly compared to other Kubernetes APIs, and it was not upgraded to GA until Kubernetes 1.19.

The main goal of Ingress is to expose HTTP applications with a simple, declarative syntax. You can deploy a variety of Ingress Controllers in Kubernetes, and specify the controller used by the gateway through IngressClass when creating an Ingress, or set the default default IngressClass in Kubernetes. Kubernetes only supports AWS, GCE and Nginx Ingress Controller by default, and also supports a large number of third-party Ingress Controllers
.

The following diagram shows the workflow of Kubernetes Ingress.

Kubernetes Ingress Workflow

The detailed process is as follows:

Kubernetes cluster administrator deploys Ingress Controller in Kubernetes;
Ingress Controller will continuously monitor the changes of IngressClass and Ingress objects in Kubernetes API Server;
The administrator applies IngressClass and Ingress to deploy the gateway;
The Ingress Controller will create the corresponding ingress gateway and configure routing rules according to the administrator’s configuration;
If in the cloud, the client accesses the load balancer for that ingress gateway;
The gateway will route traffic to the corresponding backend service according to the host and path in the HTTP request;

Istio supports both Ingress and Gateway APIs. Below is an example configuration using the Istio ingress gateway, which will be created later using the Gateway API.

 apiVersion : networking.k8s.io/v1 kind : IngressClass metadata :   name : istio spec :   controller : istio.io/ingress-controller --- apiVersion : networking.k8s.io/v1 kind : Ingress metadata :   name : ingress spec :   ingressClassName : istio   rules :   - host : httpbin.example.com     http :       paths :       - path : /         pathType : Prefix         backend :           service :             name : httpbin             port : 8000

Note: The IngressClass used must be specified in the ingressClassName field in the Ingress spec, otherwise the corresponding ingress gateway will not be created.

Limitations of Kubernetes Ingress

Although IngressClass realizes the decoupling of ingress gateway and background implementation, it still has huge limitations:

The configuration of Ingress is too simple and only supports HTTP protocol routing;
HTTP routing only supports host and path matching. There is no general configuration for advanced routing functions, which can only be implemented through annotation, such as using Nginx Ingress Controller to implement URL redirection
, you need to configure nginx.ingress.kubernetes.io/rewrite-target annotation, which can no longer meet the needs of programmable routing;
The situation that services in different namespaces are bound to the same gateway often occurs in practice, and the ingress gateway cannot be shared in multiple namespaces;
Responsibilities for creation and management of ingress gateways are not demarcated, leading developers to not only

Kubernetes Gateway API

Gateway API is a collection of API resources – GatewayClass , Gateway , HTTPRoute , TCPRoute , ReferenceGrant etc. The Gateway API exposes a more general proxy API that can be used for more protocols than just HTTP, and models more infrastructure components, providing better deployment and management options for cluster operations.

In addition, Gateway API achieves decoupling of configuration by separating resource objects, which can be managed by personnel with different roles. The API objects are shown in the following figure.

Gateway API and roles

Below is an example of using the Gateway API in Istio.

 apiVersion : gateway.networking.k8s.io/v1alpha2 kind : Gateway metadata :   name : gateway   namespace : istio-ingress spec :   gatewayClassName : istio   listeners :   - name : default     hostname : "*.example.com"     port : 80     protocol : HTTP     allowedRoutes :       namespaces :         from : All --- apiVersion : gateway.networking.k8s.io/v1alpha2 kind : HTTPRoute metadata :   name : http   namespace : default spec :   parentRefs :   - name : gateway     namespace : istio-ingress   hostnames : [ "httpbin.example.com" ]   rules :   - matches :     - path :         type : PathPrefix         value : /     backendRefs :     - name : httpbin       port : 8000

Similar to Ingress, Gateway uses gatewayClassName declare the controller it uses, which needs to be created by the platform administrator and allows client requests to the *.example.com domain name. Application developers can create routing rules in the namespace where their services are located, in this example default , and bind to the Gateway through parentRefs , of course, this must be in the case that the Gateway explicitly allows it to bind (through the allowRoutes field rule settings in ).

After you apply the above configuration, Istio will automatically create a load balancing gateway for you. The following figure shows the workflow of the Gateway API.

Gateway API Workflow

The detailed process is as follows:

Infrastructure providers provide GatewayClass and Gateway controllers;
Platform operation and maintenance deployment Gateway (you can deploy multiple, or use different GatewayClass );
Gateway Controller will continuously monitor the changes of GatewayClass and Gateway objects in Kubernetes API Server;
Gateway Controller will create the corresponding gateway according to the configuration of cluster operation and maintenance;
The application developer applies xRoute and binds the service;
If in the cloud, the client accesses the load balancer for that ingress gateway;
The gateway will route to the corresponding backend service according to the matching conditions in the traffic request;

From the above steps, we can see that the Gateway API has a clear role division compared to Ingress, and the routing rules can be decoupled from the gateway configuration, which greatly increases the flexibility of management.

The following figure shows the flow of processing after traffic enters the gateway.

Gateway processing flow chart

From the figure, we can see that the route is bound to the gateway. The route is generally deployed in the same namespace as its backend service. If it is in a different namespace, it needs to be in the ReferenceGrant
It explicitly gives the route the reference permission across namespaces, for example, the HTTPRoute foo in the foo namespace below can refer to the bar service in the bar namespace.

 kind : HTTPRoute metadata :   name : foo   namespace : foo spec :   rules :   - matches :     - path : /bar     forwardTo :       backend :       - name : bar         namespace : bar --- kind : ReferenceGrant metadata :   name : bar   namespace : bar spec :   from :   - group : networking.gateway.k8s.io     kind : HTTPRoute     namespace : foo   to :   - group : ""     kind : Service

Currently, Gateway API only supports HTTPRoute , TCPRoute , UDPRoute , TLSRoute and GRCPRoute still in the experimental stage. Gateway API has been supported by a large number of gateway and service mesh projects, please check the support status in Gateway official documentation
.

Ingress Gateways and Service Meshes

Service meshes are primarily concerned with east-west traffic, i.e. traffic inside a Kubernetes cluster, but most service meshes also provide ingress gateway functionality, such as Istio. However, the functions and APIs of Istio are too complicated. In this article, we take SMI as an example to illustrate the relationship between the ingress gateway and the service mesh.

SMI
(Service Mesh Interface) is an incubation project of CNCF, open source and in 2019, it defines a common standard for vendor-independent service meshes running in Kubernetes.

The following diagram illustrates the overlap between the Gateway API and the Service Mesh API.

Gateway API partially overlaps with SMI

From the figure we can see that the Gateway API and SMI have a clear overlap in the traffic specification section. These overlaps lead to the same functionality that needs to be implemented repeatedly in the Gateway API and service mesh.

Istio service mesh

Of course, not all service meshes are fully compliant with the SMI standard. Istio is currently the most popular service mesh implementation. It provides rich traffic management functions, but does not have a separate policy API for these functions, but is coupled in VirtualService and DestinationRule as shown below.

VirtualService

Routing: Canary publishing, matching routing based on user body, URI, Header, etc.;
Error injection: HTTP error code injection, HTTP delay injection;
Traffic segmentation: percentage-based traffic segmentation routing;
Traffic mirroring: send a certain percentage of traffic mirroring to other clusters;
Timeout: Set the timeout time, the request will fail after the set time;
Retry: Set the retry strategy, such as trigger conditions, number of retries, interval time, etc.;

DestinationRule

Load balancing: Set load balancing strategies, such as simple load balancing, region-aware load balancing, and regional weighted load balancing;
Circuit Breaking: Eliminate abnormal nodes from the load balancing pool through Outlier Detection and connection pool settings;

VirtualService mainly handles routing-related functions, while DestinationRule is responsible for the opening and closing and load balancing of cluster nodes.

Gateway API Ingress Gateway for Fusion Kubernetes and Service Mesh

As mentioned above, there is some functional intersection between the Gateway API and the service mesh. In order to reduce duplication of development and promote the modeling of common concerns between the Gateway API and the service mesh, the Gateway API Working Group proposed GAMMA
(Gateway API Mesh Management and Administration) initiative.

Advocated by this initiative, those advanced traffic management functions whose details vary in different gateway implementations, such as timeouts, retries, health checks, etc., are all passed through policy attachments
(Policy Attachment) will be implemented by each provider. You can specify the resource object to which the policy attachment is attached via the targetRef field, for example:

 apiVersion : networking.acme.io/v1alpha1 kind : RetryPolicy metadata :   name : foo spec :   override :     maxRetries : 10   default :     maxRetries : 5   targetRef :     group : gateway.networking.k8s.io/v1alpha2     kind : HTTPRoute     name : foo

In this example the retry policy is attached to the name foo and HTTPRoute . The policy attachment is attached to different resource objects, and its effective priority is also different. For example, GatewayClass is a cluster-level resource. If the policy attachment is overlaid on it, it will take effect first.

You can specify override and default values for the attached policy, and its priority in the hierarchy of ingress and different resources within the grid is as shown below.

Kubernetes ingress and priority of overrides and defaults in the grid

Currently, the Gateway API is being explored to handle grid traffic, and some design options have been proposed
.

Envoy Gateway

The first open source version v0.2 of Envoy Gateway will be released in October 2022
, which is an Envoy proxy-based gateway created by following the Gateway API, Tetrate
Is one of the core initiators of the project. The goal of Envoy Gateway is to lower the barriers for users to adopt Envoy as an API gateway to attract more users to Envoy. It’s expressive, extensible, role-oriented API design through ingress and L4/L7 traffic routing, making it the foundation for vendors to build API Gateway value-added products.

Long before the release of Envoy Gateway, Envoy, as one of the most popular cloud-native proxies, has seen mass adoption, and several Gateway software is built on Envoy, which is used by the Istio service mesh as the default sidecar proxy and communicated via the xDS protocol. Configure these distributed proxies. In the Envoy Gateway, it also uses xDS to configure the Envoy fleet. The following figure shows the architecture of the Envoy Gateway.

Envoy Gateway Architecture Diagram

The infrastructure provider will provide you with GatewayGlass , you can create an Envoy Gateway by creating a Gateway declaration, and your routes and policy attachments in the Gateway will be sent to the Envoy fleet through the xDS protocol.

For a further introduction to Envoy Gateway, please read:

Summarize

As the next-generation Kubernetes Ingress API, Gateway API provides Kubernetes gateway suppliers with API specifications to a certain extent, enriches the functions of ingress gateways on the premise of ensuring its portability, and facilitates the management of gateways through separation of concerns. . Finally, the GAMMA initiative is promoting the integration of the ingress gateway of the service mesh with the Gateway API, and the policy attachment may further extend the functionality of the Gateway API to the east-west gateway, we will wait and see.

refer to

This article is reprinted from https://jimmysong.io/blog/why-gateway-api-is-the-future-of-ingress-and-mesh/
This site is for inclusion only, and the copyright belongs to the original author.