Introduction to Kubernetes Gateway API
A non-exhaustive blog for DevOps and cloud architects to get started with Kubernetes Gateway API.
Join the DZone community and get the full member experience.
Join For FreeKubernetes Ingress has been around for a while. It helps to expose services in the cluster to the external world and provides basic traffic routing functionalities. But for advanced networking features DevOps and architects have to rely on vendors and their CRDs and custom annotations.
If you have ever written custom annotations on NGINX Ingress, you know how tedious the process is. Luckily Kubernetes Gateway API is here to solve it and some other drawbacks with native Ingress.
What Is Kubernetes Gateway API?
Kubernetes Gateway API is a collection of resources that helps to standardize the specifications for implementing Gateway/Ingress rules in Kubernetes. Gateway API provides resources such as, GatewayClass
, Gateway
, and *Route
, which are also role-delineated (see Fig. A).
Fig.A – Kubernetes Gateway API resources
Note that Gateway API only standardizes the specifications; for implementation, DevOps and architects will need an Ingress controller or a service mesh like Envoy Gateway or Istio.
The resources help DevOps and architects to configure basic to advanced networking rules in Kubernetes without relying on vendor-specific CRDs and annotations. There are various implementors and integrators of K8s Gateway API.
Challenges of Native Kubernetes Ingress
Kubernetes Gateway API is introduced to solve some pressing challenges with native Kubernetes Ingress:
- Limited functionality: Native K8s Ingress only provides basic load-balancing functionality. Advanced traffic routing capabilities, such as path-based routing, require DevOps folks to configure tedious custom annotations provided by their respective Ingress controller.
- Lack of standardization: Vendors providing Ingress controllers have their annotation specifications. If DevOps has to switch Ingress controllers, they have a learning curve regarding vendor-specific CRDs and annotations. Besides, they will have to rewrite the current vendor’s specifications using the new ones. It takes a reasonable amount of time to write and test annotations before they can be implemented.
- Single Ingress resource: Usually, in a shared K8s cluster, there will be a single Ingress resource and multiple tenants will work on it. An admin will create multiple Ingress objects for various app teams at max, but it is still hard to implement role-based access controls on any object. If proper RBAC policies are not in place, teams may mess up the route configuration.
Gateway API not only solves the challenges at the Gateway/Ingress level, but it could also evolve to manage service-to-service/east-west traffic within the same cluster.
Kubernetes Gateway API Resources and the Request Flow
Kubernetes Gateway API provides the following resources that give freedom for IT teams to work on resources that fall under their respective roles:
GatewayClass (Infra Provider)
The resource specifies the controller that implements the Gateway API CRDs associated with the class in the cluster. The Gateway API implementation controller is specified using controllerName
, which then manages the GatewayClass
.
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: istio
spec:
controllerName: istio.io/gateway-controller
In the above sample configuration, GatewayClass
(es) the controllerName: istio.io/gateway-controller
will be managed by the Istio service mesh.
Gateway (Cluster admin/Architect)
A Gateway
resource acts as a network endpoint that gets the traffic inside the cluster, like a cloud load balancer. DevOps or Infra team can add multiple listeners to the external traffic and apply filters, TLS, and traffic forwarding rules. Gateway
is attached to a GatewayClass
and is implemented using the respective controller defined in GatewayClass
.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: k8s-gateway
namespace: k8s-gw
spec:
gatewayClassName: istio
listeners:
- name: default
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: All
In the above Gateway
resource, gatewayClassName
refers to the respective GatewayClass
the resource is attached to, and listeners
specify that the Gateway
listens to HTTP traffic on port: 80
.
Route (Devs/DevOps)
Route resources manage the traffic from the Gateway to the back-end services. Multiple Route resources, such as HTTPRoute
, TCPRoute
, GRPCRoute
, etc., are used to configure the routing rules of the respective traffic from a Gateway listener to a backend service. The app team can configure different path names and Header filters (under the rules
section in the YAML) in the Route resources to handle the traffic to the backend. Each Route
can be attached to a single or multiple Gateways as per the requirements, which can be specified under parentRefs
.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: k8s-http-route-with-istio
namespace: with-istio
spec:
parentRefs:
- name: k8s-gateway
namespace: k8s-gw
rules:
- matches:
- path:
type: PathPrefix
value: /with-istio
backendRefs:
- name: echoserver-service-with-istio
port: 80
The rules
field allows the set of advanced routing behaviors such as header-based matching, traffic splitting, balancing, etc. The above configuration routes HTTP traffic with the request path /with-istio
from the k8s-gateway
— to echoserver-service-with-istio
service on port: 80
, which is the destination.
Combining the above resources, the request flow in Gateway API would look like this: a request would first come to the Gateway, from which *Route
applies the routing rules before the request finally ends up on the respective backend service (see Fig. B).
Benefits of K8s Gateway API
By now, I hope you must be convinced of the role delineation benefits of Kubernetes Gateway API. Let us explore it and some other crucial benefits and features of Gateway API.
Proper Role Delineation and RBAC
The cluster admin no longer needs to worry about developers accidentally introducing any wrong configuration to the Ingress resource, as they do not need to share the Gateway
resource with anyone. Devs/DevOps can create *Routes
and attach them to particular Gateways without distracting other teams’ routes.
No Vendor Lock-in
The standardization brought by Gateway API makes it seamless to switch between vendors providing controllers. DevOps and architects can use the same API to configure networking with the new vendor by changing the gatewayClassName in the Gateway resource. Almost all popular Gateway controllers and service meshes support integration with K8s Gateway API.
Increased Developer Experience
Advanced traffic routing rules can now be configured in *Routes
Gateway API, which spares developers/DevOps from writing and rigorously testing vendor-specific CRDs and annotations. Besides, K8s Gateway API allows users to extend it by creating custom resources that suit their unique needs.
How To Implement Kubernetes Gateway API With Istio Service Mesh
In the demo below, I have a service deployed in both Istio-enabled and non-Istio namespace. I have used Gateway
to let the traffic inside the cluster and HTTPRoute
resource to apply path-based routing for the traffic — using Istio as the controller.
Watch the tutorial to see Gateway API implementation for north-south traffic with Istio service mesh:
(As a side note, Istio made it clear that Gateway API will be Istio’s default API for traffic management in the future.)
Parting Thoughts
I hope you have a good understanding of Gateway API by now. I deliberately left a few things to mention in this piece, like the GAMMA initiative and ReferenceGrant, to make it easier to consume. We’ll go over each concept around Kubernetes Gateway API in detail in the coming days.
Published at DZone with permission of Anas T. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments