A first look into the Kubernetes Gateway API on OpenShift

OpenShift Ingress Gateway-API Istio

- Toni Schmidbauer Toni Schmidbauer ( Lastmod: 2025-08-29 ) - 6 min read

image from A first look into the Kubernetes Gateway API on OpenShift

This blog post summarizes our first look into the Kubernetes Gateway API and how it is integrated in OpenShift.

The Kubernetes Gateway API is new implementation of the ingress, load balancing and service mesh API’s. See upstream for more information.

Also the OpenShift documentation provides an overview of the Gateway API and it’s integration.

Things to consider when using Gateway API with OpenShift

  • Currently UDN (User Defined Networks) with Gateway API are not supported.

  • Only TLS termination on the edge is supported (no pass-through or re-encrypt), this needs to be confirmed. We can’t find the original source of this statement

  • The standard OpenShift ingress controller manages Gateway API Resources

  • Gateway API provides a standard on how to get client traffic into a Kubernetes cluster. Vendors provide an implementation of the API. So OpenShift provides ONE possible implementation, but there could be more than one in a cluster.

    • We found the following sentence in the OpenShift documentation interesting:

      Because OpenShift Container Platform uses a specific
version of Gateway API CRDs, any use of third-party implementations
of Gateway API must conform to the OpenShift Container Platform
implementation to ensure that all fields work as expected

Setting up Gateway API on OpenShift

Before you begin, ensure you have the following:

  • OpenShift 4.19 or higher with cluster-admin access

First you need to create a GatewayClass object.

Be aware that the GatewayClass object is NOT namespaced.
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: openshift-default
spec:
  controllerName: openshift.io/gateway-controller/v1 (1)
1The controller name needs to be exactly as shown. Otherwise the ingress controller will NOT manage the gateway an associated resources.

This creates a new pod in the openshift-ingress namespace:

$ oc get po -n openshift-ingress
NAME                                        READY   STATUS    RESTARTS   AGE
istiod-openshift-gateway-7b567bc8b4-4lrt2   1/1     Running   0          12m (1)
router-default-6db958cbd-dlbwz              1/1     Running   12         14d
1this pod got create after applying the gateway class resource

router-default is the default openshift ingress pod. The first difference seems to be the SCC (security context constraint) the pods are using.

$  oc get po -n openshift-ingress -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.annotations.openshift\.io/scc}{"\n"}{end}'
istiod-openshift-gateway-7b567bc8b4-4lrt2       restricted-v2
router-default-6db958cbd-dlbwz  hostnetwork

The standard router used host networking for listing on port 80 and 443 on the node where it is running. Our GatewayClass currently only provides a pod running Istiod awaiting further configuration. To actually listen for client request additional configuration is required.

A Gateway is required to listen for client requests. We create the following gateway:

---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: http-gateway
  namespace: openshift-ingress (1)
spec:
  gatewayClassName: openshift-default
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: "*.apps.ocp.lan.stderr.at"
1We create this gateway in the same namespace as the istio deployment. This is required for OpenShift.

This creates an additional pod in the openshift-ingress namespace:

$ oc get po
NAME                                             READY   STATUS    RESTARTS   AGE
http-gateway-openshift-default-d476664f5-h87mp   1/1     Running   0          36s

We also got a new service for the our http-gateway

➜  oc get svc
NAME                             TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
http-gateway-openshift-default   LoadBalancer   172.30.183.48    10.0.0.150    15021:30251/TCP,80:30437/TCP            4m52s

The interesting thing is the TYPE of the service. It’s of type LoadBalancer. We have MetalLB deployed in our cluster, this might be the reason for this. We will try to configure a gateway without MetalLB in in upcoming post.

Lets take a look at the gateway resource

$  oc get gtw
NAME           CLASS               ADDRESS      PROGRAMMED   AGE
http-gateway   openshift-default   10.0.0.150   True         3m

So this seems to be working. But know we have a problem: the *.apps domain that we used for our gateway points already to the default OpenShift Ingress. We could either

  • redeploy the gateway with a different wildcard domain (e.g. *.gtw…​)

  • create a more specific DNS record that points to our new load balancer

Let’s try to confirm this with curl:

$  curl -I http://bla.apps.ocp.lan.stderr.at
HTTP/1.0 503 Service Unavailable
pragma: no-cache
cache-control: private, max-age=0, no-cache, no-store
content-type: text/html

503 is the response of default OpenShift Ingress.

$  curl -I http://10.0.0.150
HTTP/1.1 404 Not Found
date: Fri, 29 Aug 2025 14:31:31 GMT
transfer-encoding: chunked

Our new gateway returns a 404 not found response. We choose the first option and create another wildcard DNS entry for *.gtw.ocp.lan.stderr.at. We re-deployed our gateway with the new hostname:

---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: http-gateway
  namespace: openshift-ingress
spec:
  gatewayClassName: openshift-default
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: "*.gtw.ocp.lan.stderr.at" (1)
1New hostname for resources exposed via our gateway
$ oc apply -f gateway.yaml
gateway.gateway.networking.k8s.io/http-gateway created

This also creates a DNSRecord resource:

$ oc describe dnsrecords.ingress.operator.openshift.io -n openshift-ingress http-gateway-c8d7bfc67-wildcard
Name:         http-gateway-c8d7bfc67-wildcard
Namespace:    openshift-ingress
Labels:       gateway.istio.io/managed=openshift.io-gateway-controller-v1
              gateway.networking.k8s.io/gateway-name=http-gateway
              istio.io/rev=openshift-gateway
Annotations:  <none>
API Version:  ingress.operator.openshift.io/v1
Kind:         DNSRecord
Metadata:
  Creation Timestamp:  2025-08-29T14:49:45Z
  Finalizers:
    operator.openshift.io/ingress-dns
  Generation:  1
  Owner References:
    API Version:     v1
    Kind:            Service
    Name:            http-gateway-openshift-default
    UID:             a023de5d-c428-4249-a190-de3cbfeb6964
  Resource Version:  141150968
  UID:               7a61a867-216e-40b7-88f3-e3934493c477
Spec:
  Dns Management Policy:  Managed
  Dns Name:               *.gtw.ocp.lan.stderr.at.
  Record TTL:             30
  Record Type:            A
  Targets:
    10.0.0.150
Events:  <none>

This resource is only internally used by the OpenShift ingress operator (see oc explain dnsrecord for details).

Creating HTTPRoutes for exposing our service.

To actually expose a HTTP pod via our new gateway we need:

  • A Namespace to deploy an example pod. We will use a Nginx for this

  • A Service that exposes our Nginx pod

  • and finally a HTTPRoute resource

For the nginx deployment we used the following manifest:

---
apiVersion: v1
kind: Namespace
metadata:
  name: gateway-api-test
spec:
  finalizers:
  - kubernetes
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: gateway-api-test
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: quay.io/nginx/nginx-unprivileged:1.29.1
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: gateway-api-test
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

Let’s see if our nginx pod got deployed successfully:

$ oc get po,svc -n gateway-api-test
NAME                                    READY   STATUS    RESTARTS   AGE
pod/nginx-deployment-796cdf7474-b7bqz   1/1     Running   0          20s

NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/nginx   ClusterIP   172.30.42.36   <none>        8080/TCP   21s

And finally confirm our Service is working:

$ oc port-forward -n gateway-api-test svc/nginx 8080 &
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

$ curl -I localhost:8080
Handling connection for 8080
HTTP/1.1 200 OK
Server: nginx/1.29.1
Date: Fri, 29 Aug 2025 15:45:12 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Wed, 13 Aug 2025 14:33:41 GMT
Connection: keep-alive
ETag: "689ca245-267"
Accept-Ranges: bytes

We received a response from our nginx pod, hurray!

So next let’s try to create a HTTPRoute to expose our nginx service to external clients:

---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: nginx-route
spec:
  parentRefs:
  - name: http-gateway
    namespace: openshift-ingress
  hostnames: ["nginx.gtw.ocp.lan.stderr.at"]
  rules:
  - backendRefs:
    - name: nginx
      namespace: gateway-api-test
      port: 8080

One important point here, the Gateway actually come in two flavors

  • dedicated gateways, only accepting HTTP routes in the same namespace (openshift-ingress) in our case.

  • shared gateways, which also accept HTTP route objects from other namespaces

see Gateway API deployment topologies in the OpenShift documentation for more information.

As this post is already rather long, we focus on the dedicated gateway topology for now.

The HTTP route must be deployed in the same namespace as the gateway if the dedicated topology is used.

So let’s deploy our HTTPRoute:

$ oc apply -f httproute.yaml

Verify we can reach our nginx pod:

curl -I http://nginx.gtw.ocp.lan.stderr.at
HTTP/1.1 500 Internal Server Error
date: Fri, 29 Aug 2025 15:57:34 GMT
transfer-encoding: chunked

This return a 500 error, something seems to be wrong with our route, let’s take a look at the status of the HTTPRoute:

$ oc describe gtw http-gateway
.
. (output omitted)
.
Status:
  Parents:
    Conditions:
      Last Transition Time:  2025-08-29T15:54:43Z
      Message:               Route was valid
      Observed Generation:   1
      Reason:                Accepted
      Status:                True
      Type:                  Accepted
      Last Transition Time:  2025-08-29T15:54:43Z
      Message:               backendRef nginx/gateway-api-test not accessible to a HTTPRoute in namespace "openshift-ingress" (missing a ReferenceGrant?) (2)
      Observed Generation:   1
      Reason:                RefNotPermitted
      Status:                False (1)
      Type:                  ResolvedRefs
    Controller Name:         openshift.io/gateway-controller/v1
    Parent Ref:
      Group:      gateway.networking.k8s.io
      Kind:       Gateway
      Name:       http-gateway
      Namespace:  openshift-ingress
1Something seems to be wrong as the status is False
2Seems we are missing a ReferenceGrant

Looking at the upstream documentation reveals a security feature of the Gateway API. Before a HTTPRoute can reach a service in a different namespace we must create a ReferenceGrant in the namespace providing the service.

So let’s try to deploy following ReferenceGrant in the gateway-api-test namespace:

---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: nginx
  namespace: gateway-api-test
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: openshift-ingress
  to:
  - group: ""
    kind: Service

Checking the status field of our HTTPRoute again:

(output omitted)
Status:
  Addresses:
    Type:   IPAddress
    Value:  10.0.0.150
  Conditions:
    Last Transition Time:  2025-08-29T15:47:07Z
    Message:               Resource accepted
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Last Transition Time:  2025-08-29T15:47:08Z
    Message:               Resource programmed, assigned to service(s) http-gateway-openshift-default.openshift-ingress.svc.cluster.local:80
    Observed Generation:   1
    Reason:                Programmed
    Status:                True (1)
    Type:                  Programmed
1Status is now True

and finally calling the nginx pod again via our gateway:

$  curl -I http://nginx.gtw.ocp.lan.stderr.at
HTTP/1.1 200 OK
server: nginx/1.29.1
date: Fri, 29 Aug 2025 16:01:33 GMT
content-type: text/html
content-length: 615
last-modified: Wed, 13 Aug 2025 14:33:41 GMT
etag: "689ca245-267"
accept-ranges: bytes

Finally everything seems to be in place and working.

Conclusion

In this blog post we took a first look at the Kubernetes Gateway API and it’s integration into OpenShift. We enabled the Gateway API via a GatewayClass resource, created a simple HTTP Gateway via a Gateway, deploy a Nginx pod and a Service and exposed the service via an HTTPRoute and a ReferenceGrant.

Hopefully an upcoming blog post will cover how to

  • How to deploy a Gateway without MetalLB

  • Deploy a TLS secured service

  • implement HTTP redirects

  • rewriting URL’s (if possible)

  • and other possibilities of the Gateway API

See Also:

  • Reusable Argo CD Application Helm Template –

    When working with Argo CD at scale, you often find yourself creating similar Application manifests repeatedly. Each application needs the same basic structure but with different configurations for source repositories, destinations, and sync policies. Additionally, managing namespace metadata becomes tricky when you need to conditionally control whether Argo CD should manage namespace metadata based on sync options. In this article, I’ll walk you through a reusable Helm template that solves these challenges by providing a flexible, DRY (Don’t Repeat Yourself) approach to creating Argo CD Applications. This template is available in my public Helm Chart library and can easily be used by anyone.

  • Cert-Manager Policy Approver in OpenShift –

    One of the most commonly deployed operators in OpenShift environments is the Cert-Manager Operator. It automates the management of TLS certificates for applications running within the cluster, including their issuance and renewal. The tool supports a variety of certificate issuers by default, including ACME, Vault, and self-signed certificates. Whenever a certificate is needed, Cert-Manager will automatically create a CertificateRequest resource that contains the details of the certificate. This resource is then processed by the appropriate issuer to generate the actual TLS certificate. The approval process in this case is usually fully automated, meaning that the certificate is issued without any manual intervention. But what if you want to have more control? What if certificate issuance must follow strict organizational policies, such as requiring a specifc country code or organization name? This is where the CertificateRequestPolicy resource, a resource provided by the Approver Policy, comes into play. This article walks through configuring the Cert-Manager Approver Policy in OpenShift to enforce granular policies on certificate requests.

  • Single log out from Keycloak and OpenShift –

    The following 1-minute article is a follow-up to my previous article about how to use Keycloak as an authentication provider for OpenShift. In this article, I will show you how to configure Keycloak and OpenShift for Single Log Out (SLO). This means that when you log out from Keycloak, you will also be logged out from OpenShift automatically. This requires some additional configuration in Keycloak and OpenShift, but it is not too complicated.

  • Step by Step - Using Keycloak Authentication in OpenShift –

    I was recently asked about how to use Keycloak as an authentication provider for OpenShift. How to install Keycloak using the Operator and how to configure Keycloak and OpenShift so that users can log in to OpenShift using OpenID. I have to admit that the exact steps are not easy to find, so I decided to write a blog post about it, describing each step in detail. This time I will not use GitOps, but the OpenShift and Keycloak Web Console to show the steps, because before we put it into GitOps, we need to understand what is actually happening. This article tries to explain every step required so that a user can authenticate to OpenShift using Keycloak as an Identity Provider (IDP) and that Groups from Keycloak are imported into OpenShift. This article does not cover a production grade installation of Keycloak, but only a test installation, so you can see how it works. For production, you might want to consider a proper database (maybe external, but at least with a backup), high availability, etc.).

  • Using ApplicationSet with Matrix Generator and define individual Namespaces –

    During my day-to-day business, I am discussing the following setup with many customers: Configure App-of-Apps. Here I try to explain how I use an ApplicationSet that watches over a folder in Git and automatically adds a new Argo CD Application whenever a new folder is found. This works great, but there is a catch: The ApplicationSet uses the same Namespace default for all Applications. This is not always desired, especially when you have different teams working on different Applications. Recently I was asked by the customer if this can be fixed and if it is possible to define different Namespaces for each Application. The answer is yes, and I would like to show you how to do this.

Copyright © 2020 - 2025 Toni Schmidbauer & Thomas Jungbauer