(Part-2) Practical Guide to Kubernetes Gateway API: Setup, Use Cases, and Best Practices

We're continuing our exploration of the Kubernetes Gateway API. If you missed our previous blog, you can catch up by reading it here.
Today, we'll cover how to use the Gateway API for cross-namespace routing, HTTPS redirects and rewrites, and modifying HTTPS headers.
Cross-namespace routing
let’s see how it works!

We will create Shared-Gateway in Infra namespace.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: shared-gateway
namespace: infra
spec:
gatewayClassName: gke-l7-global-external-managed
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: Selector
selector:
matchLabels:
shared-gateway-access: "true"
Thing to remember here is Every Namespace should have matching labels. Only Namespaces which are labelled shared-gateway-access: "true" will be able to attach their Routes to shared-gateway.

Now let’s create one app , svc in test1 namespace.

Now create HttpRoute in Test1 namespace.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: app1
namespace: test1
spec:
parentRefs:
- name: shared-gateway
namespace: infra
hostnames:
- 34.49.150.61 <Remeber to change this one to your gateway address>
rules:
- matches:
- path:
value: /app1
backendRefs:
- name: app1
port: 8080

Remember All the namespace with matching labels are allowed to use shared gateway.

Now wait for while and then test.
You will see our application running.

Now It is time to create second app and service in test2 namespace.

Now create HttpRoute For that app in test2 namespace
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: app2
namespace: test2
spec:
parentRefs:
- name: shared-gateway
namespace: infra
hostnames:
- 34.49.150.61 <Remeber to change this one to your gateway address>
rules:
- matches:
- path:
value: /app2
backendRefs:
- name: app2
port: 8080

Now again wait for a while and then test URL.
This is useful when more than one user or team is sharing the underlying networking infrastructure, yet control and configuration must be segmented to minimize access and fault domains.
This is not possible in Ingress.
Now, let’s another use case of Gateway api.
Http Header-based matching
Imagine you run a news website and want to serve tailored versions of your homepage based on whether the user is on an Android device, an iPhone, or a generic mobile browser. The content may be optimized for each platform, such as displaying platform-specific advertisements or providing app download prompts.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: http-route-headermatch
spec:
parentRefs:
- name: shared-gateway
namespace: infra
hostnames:
- 34.49.150.61 <Remeber to change this one to your gateway address>
rules:
- matches:
- headers:
type: RegularExpression
name: User-Agent
value: ".*(Android).*"
backendRefs:
- name: android
port: 80
- matches:
- headers:
type: RegularExpression
name: User-Agent
value: ".*(iPhone).*"
backendRefs:
- name: iPhone
port: 80
- matches:
- headers:
type: RegularExpression
name: User-Agent
value: ".*(Mobile).*"
backendRefs:
- name: mobile
port: 80
- matches:
- path:
type: Prefix
value: "/"
backendRefs:
- name: desktop
port: 80
Http Method-based matching
Let's say you're developing version 2 (/v2) of your API, but only the GET method has been fully implemented and tested. You want to allow users to retrieve data using GET /v2/products, but requests for creating, updating, or deleting resources should still go to version 1 (/v1).
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: http-route-methodmatch
spec:
parentRefs:
- name: shared-gateway
namespace: infra
hostnames:
- 34.49.150.61 <Remeber to change this one to your gateway address>
rules:
- matches:
- path:
type: Pathprefix
value: /api/v2
method: GET
backendRefs:
- name: api-v2
port: 80
Http- Header request modification.
Imagine you are developing an API endpoint (/test) that requires user authentication. However, for testing purposes, you want to bypass the actual authentication process. Instead, you can modify the request headers to include hardcoded or predefined username and password values.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: http-route-requestmod
spec:
parentRefs:
- name: shared-gateway
namespace: infra
hostnames:
- 34.49.150.61 <Remeber to change this one to your gateway address>
rules:
- matches:
- path:
type: Pathprefix
value: /test
filters:
- type: RequestHeaderModifier
requestHeaderModifier:
set:
- name: Authrization
value: "Basic ewhgbbGSubiuhfgbAEWhklh=="
backendRefs:
- name: api-v2
port: 80
Http- Header request redirect.
Imagine You have an application hosted at myapp.com, and you've decided to move it to new.myapp.com. To ensure that users accessing the old domain are automatically redirected to the new one, you can set up an HTTP redirect. This can be configured at the web server level or through an API Gateway.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: http-route-redirect
spec:
parentRefs:
- name: shared-gateway
namespace: infra
hostnames:
- myapp.example.com
rules:
- filters:
- type: RequestRedirect
requestRedirect:
hostname: new.myapp.example.com
statusCode: 302
There is a lot you can do with Gateway Api. Keep reading official document.
That was all for Gateway Api. Will explore Kubernetes more in next Blog till then keep exploring and keep reading official documentation.



