Getting started with GKE Gateway controller

One year ago, Google announced the preview release of the GKE Gateway controller and while it was kind of cool to play with initially, it did not offer any of the awesome, game-changing features that the Kubernetes Gateway API was supposed to bring at the time. However with the recent release of Gateway API v0.4.3, the GKE Gateway controller has also moved to v1alpha2 stage and brought along with it some of the exciting features it has to offer, so I am here to explain some of the use cases and how you can get started with GKE Gateway controllers.

Introduction

Ingress is a powerful and useful feature commonly used throughout many Kubernetes deployments and many different implementations of it with different feature sets via various ingress controllers. In fact, I have previously compared NGINX Ingress with GKE Ingress!

Traditional ingress falls short in that the Ingress resource and the Service resource needs to be in the same namespace. There is also a one-to-one relationship between the Ingress resource and its controller, meaning all your routes & rules are defined in one large YAML file. This may not seem like a big deal if you are the sole owner of the application that runs on your cluster and you manage all its endpoints, but what if you were sharing tenancy or if different endpoints are managed by different teams? A one-to-one relationship here could pose some administrative challenges; one team can accidentally break another team’s routes.

The Kubernetes Gateway API introduces features that allows (among other things) a one-to-many relationship between the Gateway (essentially your load balancer or ingress controller) and Route. This allows separate teams to each manage their own endpoints and routes. With Cross-Namespace routing, the Ingress and Service resources no longer need to be in the same namespace which means the Gateway itself can be a separate namespace managed by the platform team while the application teams that share the Gateway will also have their own.

The possibilities the GKE Gateway controller can bring!

What is the GKE Gateway controller?

Kubernetes Gateway API has been heralded as the next generation of ingress for Kubernetes and there are already many downstream implementations of it. The GKE Gateway controller is Google’s implementation of the Kubernetes Gateway API — after all, it has to integrate with GCP’s features such as Cloud Load Balancing, Network Endpoint Groups (NEGs), etc.

Deploying the demo

We are going to deploy a very simple demo involving Cross-Namespace routing.

• Install the Kubernetes Gateway API custom resource definition (CRD): kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.4.3" | kubectl apply -f -
  UPDATE 2022–12–26: the GKE Gateway controller is to be enabled via:
  gcloud container clusters update CLUSTER_NAME --gateway-api=standard --region=REGION
• Create namespaces and must have the shared-gateway-access label set to true. You can apply the manifest below: kubectl apply -f namespaces.yaml

• Deploy the GKE layer 7 global external load balancer (gke-l7-gxlb) Gateway in the infra-ns namespace: kubectl apply -f gateway.yaml

• Deploy the store pods and service in the store-ns namespace: kubectl apply -f store.yaml
  NOTE: I find that it is necessary to explicitly specify the annotation to use NEGs in the Service definition even though it should be the default behavior.

• Deploy the HTTPRoute: kubectl apply -f store-route.yaml

NOTE: it may take a couple of minutes for the NEGs to be created and routes to sync, so please be a little patient.

Testing

You can get the IP address of the Gateway by looking at the output of kubectl describe gateway external-http -n infra-ns or you can query it directly with kubectl get gateway external-http -n infra-ns -o=jsonpath="{.status.addresses[0].value}"

After which you can curl the endpoint, but you must provide the proper host header (e.g.curl -H "host: store.example.com" 123.45.67.89/de to match the route to reach the store-german backend).

Cleaning up

Run kubectl delete on the deployment manifests in reverse order.

What’s next?

The demo above was shortened for this Medium article, but if you would like to see the full demo (using an internal load balancer), you can find it in my Free Tier GKE repo (along with other examples).

Read the Getting started with Kubernetes APIs guide to familiarize yourself with its features (e.g. traffic splitting) so you can start thinking about how you can use it to improve security, workflows, testing, etc.

Keep in mind that the GKE Gateway controller is still in Preview mode and as it progresses towards eventual v1beta1 and onward, you can expect more changes to come (likely breaking changes — even going from v1alpha1 to v1alpha2 saw quite a few breaking changes).

PSA

Please also check out Google Dev Library which is a treasure trove of GCP-related blog posts, HOW-TO’s and code examples if you want to learn more about Kubernetes, GKE or just Google Cloud in general.

EDIT 2022–07–22: Gateway API is in v1beta1 (starting from CRD v0.5.0)