Gateway API provides a mechanism to program the Ingress. We show how EnRoute can be programmed using the Gateway API
EnRoute is an Ingress API Gateway that is built using Envoy proxy. EnRoute has an extremely simple configuration model to help connect and secuire microservices at Ingress.
The Gateway API is an upcoming standard that is a replacement for Ingress. Like Ingress, it is an attempt to describe networking for traffic entering the Kubernetes cluster.
EnRoute Ingress API Gateway is now compliant with the Gateway API standard v0.6.0. In a Kubernetes cluster, EnRoute can now listen for Gateway API artifacts.
In this article, we discuss how Gateway API can be used to program EnRoute Ingress Controller API Gateway.
We start with a simple example to introduce Gateway API capabilities. Subsequent articles in this series, with include more details depending on how our customers adopt and use it.
EnRoute can be easily configured using helm charts. To demonstrate gateway-api capabilities, a special chart called gateway-api is created. The following helm charts are available
add the helm chart -
check repositories -
We will use Gateway API to expose the service httpbin externally. Next we create a self-signed certificate which we can use to serve traffic over https.
Create a self-signed certificate
create kubernetes secret using self-signed certificate
The tlscert created in the step above is used in the gateway api example helm chart
We will cover the configuration using Gateway API below, but the listener we defined in the Gateway uses port 8444. Traffic from the LoadBalancer EnRoute service, should be directed to this port. Set targetPort to 8444 to direct encrypted traffic from the external Load Balancer to this Gateway API defined listener.
The helm chart creates the following artifacts
A GatewayClass object defines state that can be used by several Gateways
A Gateway defines listeners to receive incoming traffic from the external Load Balancer.
A HTTPRoute can be used to provide L7 routing rules to reach a service defined in Kubernetes
Teams using EnRoute can continue to work with a simpler configuration model on their projects. When teams are ready for additional complexity arising from Gateway API, they can transition easily. This is possible since EnRoute’s flexibility provides an ability to work with simpler API, and evaluate Gateway API without any operational overhead.
Gateway API abstractions are similar to EnRoute and resemble EnRoute model closely. EnRoute architecture was defined years back to provide an easy-to-use interface for Ingress, when Ingress was just released and it’s capabilities were limited.
EnRoute architecture allows for working with Gateway API and EnRoute API concurrently. Abstractions defined using any of the API can be mixed and matched to achieve the desired behavior and program the underlying Envoy proxy. This is possible since Gateway API configuration model resembles the EnRoute config model.
Gateway API assumes roles like platform operator, cluster operator, developer and uses ReferenceGrant, GatewayClass and Gateway to define cross-namespace access-control using them. We will discuss them in a subsequent article. While EnRoute supports these custom resources, they are not covered here for simplicity.
EnRoute is feature rich and is validated for stablity. All the development done on EnRoute, its features can be configured using EnRoute’s config model and will work with Gateway API. The current version of EnRoute supports the latest v0.6.0 of Gateway API as of writing this.