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.
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ย –
- Create namespaces and must have the shared-gateway-access label set to true. You can apply the manifest below: kubectl apply -f namespaces.yaml
https://medium.com/media/c5c215b66f40a61cccf9594587638a49/href
- Deploy the GKE layer 7 global external load balancer (gke-l7-gxlb) Gateway in the infra-ns namespace: kubectl apply -f gateway.yaml
https://medium.com/media/81802fc4aed6ab41ab48c75078dd54eb/href
- 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.
https://medium.com/media/45c3632f4a2808e12f49e4ecb559feac/href
- Deploy the HTTPRoute: kubectl apply -f store-route.yaml
https://medium.com/media/04327251d0367d20665b554c7c3cbb21/href
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)
Getting started with GKE Gateway controller was originally published in Google Developers Experts on Medium, where people are continuing the conversation by highlighting and responding to this story.
