Skip to main content

Command Palette

Search for a command to run...

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

Published
4 min read
(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.

  1. 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.

  1. 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
  1. 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
  1. 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
  1. 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.

142 views

More from this blog

Ajay Patel

116 posts