Meet the new Kubernetes Gateway API


main

Gateway API is an open source project managed by the SIG-NETWORK community. It’s is a collection of resources that model service networking in Kubernetes. These resources - GatewayClass,Gateway, HTTPRoute, TCPRoute, Service, etc - aim to evolve Kubernetes service networking through expressive, extensible, and role-oriented interfaces that are implemented by many vendors and have broad industry support.

Here I am going to show you few steps to try this out and uses cases that can help you to improve your Kubernetes cluster.

First thing I am going to do is spin up a Kubernetes cluster locally on my computer using kind

GO111MODULE=on go get sigs.k8s.io/kind@v0.10.0
export PATH="$(go env GOPATH)/bin:${PATH}"
kind create cluster

main

Now we need to install the Gateway controller into our Kubernetes cluster.

The following command will install the Gateway API CRDs. This includes the GatewayClass, Gateway, HTTPRoute, TCPRoute, and more. Note that a running Gateway controller in your Kubernetes cluster is required to actually act on these resources. Installing the CRDs will just allow you to see and apply the resources, though they won’t do anything.

kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.3.0" | kubectl apply -f -

We should have an output like this:

main

Now that we have all resources installed in your Kubernetes cluster, let’s go through a Proof of Concept of the Kubernetes APi Gateway.

The simplest possible deployment is a Gateway and Route resource which are deployed together by the same owner. This represents a similar kind of model used for Ingress. With the following commands, a Gateway and HTTPRoute are deployed which match all HTTP traffic and directs it to a single Service named foo-svc.

main

kind: Gateway
apiVersion: networking.x-k8s.io/v1alpha1
metadata:
  name: prod-web
spec:
  gatewayClassName: acme-lb
  listeners:  
  - protocol: HTTP
    port: 80
    routes:
      kind: HTTPRoute
      selector:
        matchLabels:
          gateway: prod-web-gw 

The Gateway represents the instantation of a logical load balancer. It’s templated from a hypothetical acme-lb GatewayClass. The Gateway listens for HTTP traffic on port 80. This particular GatewayClass automatically assigns an IP address which will be shown in the Gateway.status after it has been deployed.

Gateways bind Routes to themselves via label selection (similar to how Services label select across Pod labels). In this example, the prod-web Gateway will bind any HTTPRoute resources which have the gateway: prod-web-gw label. The label can be any arbitrary label, but using one that identifies the name or capabilities of the Gateway is useful to Route owners and makes the relationship more explicit. More complex bi-directional matching and permissions are possible and explained in other guides.

The following HTTPRoute defines how traffic from the Gateway listener is routed to backends. Because there are no host routes or paths specified, this HTTPRoute will match all HTTP traffic that arrives at port 80 of the load balancer and send it to the foo-svc Pods.

kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
metadata:
  name: foo
  labels:
    gateway: prod-web-gw
spec:
  rules:
  - forwardTo:
    - serviceName: foo-svc
      port: 8080 

While Route resources are often used to filter traffic to many different backends (potentially with different owners), this demonstrates the simplest possible route with a single Service backend. This example shows how a service owner can deploy both the Gateway and the HTTPRoute for their usage alone, giving them more control and autonomy for how the service is exposed.

What does the Gateway API look like?

The Gateway API introduces a few new resource types:

  • GatewayClasses are cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes.

  • Gateways are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs.

  • Routes are not a single resource, but represent many different protocol-specific Route resources. The HTTPRoute has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are TCPRoutes, UDPRoutes, and TLSRoutes which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future.

Blue/Green use case with Gateway API

With the new gateway API we can also implement a cluster traffic splitting for a Blue/Green use case. GatewayClasses have many advanced traffic routing capabilities including traffic splitting, header matching, header manipulation, traffic mirroring, and more. In this example, you’ll demonstrate how to use weight-based traffic splitting to explicitly control the traffic proportion across two services.

main

kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
metadata:
  name: bar-route
  namespace: bar
  labels:
    gateway: external-https-prod
spec:
  hostnames:
  - "bar.example.com"
  rules:
  - forwardTo:
    - serviceName: bar-v1
      port: 8080
      weight: 90
    - serviceName: bar-v2
      port: 8080
      weight: 10
  - matches:
    - headers:
        values:
          env: canary
    forwardTo:
    - serviceName: bar-v2
      port: 8080

Gateway API in GKE

main

Last week, Google announced the Preview release of the GKE Gateway controller, Google Cloud’s implementation of the Gateway API. Over a year in the making, the GKE Gateway controller manages internal and external HTTP/S load balancing for a GKE cluster or a fleet of GKE clusters. The Gateway API provides multi-tenant sharing of load balancer infrastructure with centralized admin policy and control. Thanks to the API’s expressiveness, it supports advanced functionality such as traffic shifting, traffic mirroring, header manipulation and more.

Here I am sharing a blog post from Google that explain the major features of this custom controller. The most interesting for me to highligh is the Multi-Cluster support.

The GKE Gateway controller is built with native multi-cluster support for both internal and external load balancing via its multi-cluster GatewayClasses. Multi-cluster Gateways load-balance client traffic across a fleet of GKE clusters. This targets various use cases including:

  • Multi-cluster or multi-region redundancy and failover
  • Low latency serving through GKE clusters that have close proximity to clients
  • Blue-green traffic shifting between clusters (try this tutorial)
  • Expansion to multiple clusters because of organizational or security constraints

When you put it all together, you have a single load balancing infrastructure that can be safely shared by multiple teams. The Gateway API not only a more expressive API for advanced routing, but is also a role-oriented API, designed for multi-tenant infrastructure. Its extensibility ensures that it will evolve for future use-cases while preserving portability. Ultimately these characteristics will allow Gateway API to adapt to different organizational models and implementations well into the future.

As usual, if you have any question, send me a message at contact@wecloudpro.com

Back to blog