ngrok Operator supports Kubernetes Gateway API

04-30-2025: More updates with details about extended support for the Gateway API within the ngrok Kubernetes Operator in v0.18.0 .

01-21-2025: We updated this blog post with new information about using the Kubernetes Operator with our Traffic Policy engine.

We are excited to announce support for the Kubernetes Gateway API.

To use the Gateway API, cluster operators will set up a Gateway on their cluster with one or more listeners. These listeners will be linked to endpoints at ngrok. Application developers will then be able to create routes that modify traffic and direct it to backends like Kubernetes Services.

Regardless of whether you use the existing Kubernetes ingress controller or this new Gateway API implementation, you’ll still get all the benefits of ngrok:

• Effortless configuration: Set the authentication keys to your ngrok account and you’re done. Operators do not need to configure networking details like ELBs, IPs, network interfaces or VPC routing.

• Environment independence: Runs identically in EKS, GKE, k3s on your laptop, OpenShift in your own datacenter or Minikube on your Raspberry Pi.****

• Security and resiliency: Because the Operator pushes authentication and policy to ngrok’s global network, attacks and other unwanted traffic never reach your origin network.

• Acceleration: ngrok’s GSLB boosts application performance by routing end-user traffic to the closest point of presence, minimizing latency.

We now support the full core spec of Gateway API, and it’s never been easier to wire up Kubernetes ingress with ngrok.

Bookmark this sectionLet’s get started

Want to jump into the references? Find them here:

• Documentation: Detailed usage, operational and configuration documentation.

• Open source repo: Star the repository on GitHub to follow along!

Otherwise, let’s take a test ride on the ngrok Gateway API. We’ll create a gateway for the echo service container mendhak/http-https-echo which echos back http requests. In the examples below, we use $NGROK_DOMAIN placeholder to represent an ngrok hostname like yourName.ngrok.app Go to the dashboard to reserve a domain. First, create your Gateway and GatewayClass objects.

1apiVersion: gateway.networking.k8s.io/v12kind: GatewayClass3metadata:⋯4  name: ngrok5spec:⋯6  controllerName: ngrok.com/gateway-controller7---8apiVersion: gateway.networking.k8s.io/v19kind: Gateway10metadata:⋯11  name: simple-gateway12  namespace: ngrok-operator13spec:⋯14  gatewayClassName: ngrok15  listeners:⋯16    - name: simple-listener⋯17      hostname: "$NGROK_DOMAIN"18      port: 44319      protocol: HTTPS

The above code tells the operator that the Gateway uses ngrok’s infrastructure, and then provisions a domain. Next let’s deploy that echo service, so the HTTPRoute can direct traffic to this service.

1apiVersion: apps/v12kind: Deployment3metadata:⋯4  name: http-echo-deploy5  namespace: ngrok-operator6spec:⋯7  selector:⋯8    matchLabels:⋯9      app: http-echo-app10  replicas: 211  template:⋯12    metadata:⋯13      labels:⋯14        app: http-echo-app15    spec:⋯16      containers:⋯17        - name: http-echo-path2⋯18          image: mendhak/http-https-echo:3119          ports:⋯20            - containerPort: 808021---22apiVersion: v123kind: Service24metadata:⋯25  name: http-echo-svc26  namespace: ngrok-operator27  labels:⋯28    app: http-echo-app29spec:⋯30  ports:⋯31    - name: http-echo-app⋯32      port: 8033      protocol: TCP34      targetPort: 808035  selector:⋯36    app: http-echo-app

Now, make your HTTPRoute.

1apiVersion: gateway.networking.k8s.io/v12kind: HTTPRoute3metadata:⋯4  name: simple-route5spec:⋯6  parentRefs:⋯7    - name: simple-gateway8  hostnames: [<HOSTNAME>]9  rules:⋯10    - backendRefs:⋯11        - name: http-echo-svc⋯12          port: 8013          kind: Service

And just like that, your service is now available to the entire world. Add some gas to it by using Filters, and adding more hosts. Add the following listeners to your Gateway:

1- protocol: HTTPS⋯2   hostname: <HOSTNAME_2>3   port: 4434   tls:⋯5     mode: Terminate6     certificateRefs:7     - name: ngrokcert8   name: domain-two9 - protocol: HTTPS⋯10   hostname: <HOSTNAME_3>11   port: 44312   tls:⋯13     mode: Terminate14     certificateRefs:15     - name: ngrokcert16   name: domain-three

Replace the Route’s Hostnames with the following:

1hostnames:⋯2  - <HOSTNAME_1>3  - <HOSTNAME_2>4  - <HOSTNAME_3>

Next, add some functionality to the HTTPRoute. The most composable way to do this is with ngrok’s Traffic Policy engine, which has full support in the Kubernetes Operator via a NgrokTrafficPolicy CRD and the extensionRef filter in the Gateway API.

For example, if you want to add a certain request header whenever someone hits your service from a certain path, you can use the add headers action.

1---2kind: NgrokTrafficPolicy3apiVersion: ngrok.k8s.ngrok.com/v1alpha14metadata:⋯5  name: paprika-header6spec:⋯7  policy:⋯8    on_http_request:⋯9      - name: "Add header to /paprika path"⋯10        expressions:⋯11          - "req.url.path.startsWith('/paprika')"12        actions:⋯13          - type: add-headers⋯14            config:⋯15              headers:⋯16                paprika-header: spicy-value

Then modify your existing HTTPRoute to add an ExtensionRef filter that references your new CRD.

1- backendRefs:⋯2    - name: http-echo-svc⋯3      port: 804  matches:⋯5    - path:⋯6        type: PathPrefix7        value: /paprika8  filters:⋯9    - type: ExtensionRef⋯10      extensionRef:⋯11        group: ngrok.k8s.ngrok.com12        kind: NgrokTrafficPolicy13        name: paprika-header

With the on_http_response phase of ngrok’s Traffic Policy engine, you could also add a response variable.

1---2kind: NgrokTrafficPolicy3apiVersion: ngrok.k8s.ngrok.com/v1alpha14metadata:⋯5  name: paprika-header6spec:⋯7  policy:⋯8    on_http_response:⋯9      - name: "Add header on response"⋯10        actions:⋯11          - type: add-headers⋯12            config:⋯13              headers:⋯14                my-response-header-name: my-header-value

You can follow a similar pattern for redirecting from one path to another using the redirect action.

1---2kind: NgrokTrafficPolicy3apiVersion: ngrok.k8s.ngrok.com/v1alpha14metadata:⋯5  name: pumpkin-paprika6spec:⋯7  policy:⋯8    on_http_request:⋯9      - name: "Redirect from /pumpkin to /paprika"⋯10        actions:⋯11          - type: redirect⋯12            config:⋯13              from: /pumpkin14              to: /paprika

Bookmark this sectionThe Kubernetes Gateway API

Kubernetes Gateway API caters to the needs of modern organization roles that use and configure networking into Kubernetes. Built with a role-oriented architecture, it balances distributed flexibility with centralized governance and control by. It allows shared network infrastructure (hardware load balancers, cloud networking, cluster-hosted proxies etc) to be used by many different and non-coordinating teams, all bound by the policies and constraints set by cluster operators, responsible for managing Kubernetes clusters.

This eliminates friction in application and API delivery by providing the flexibility needed by the users of the infrastructure (application developer) while also maintaining control by the owners of the infrastructure (Infrastructure provider and cluster operator). It also enhances security by ensuring granular control over who can manage networking resources.

Gateway API is also expressive - it natively supports enhanced routing for multiple types of routes (L4 and L7), header-based matching, traffic weighting, and other capabilities that equip developers to direct and shape traffic easily. This enhanced support for routing gives developers the flexibility to configure path routing that maps requests to Kubernetes services.

Bookmark this sectionMotivation: Addressing ingress limitations

The Kubernetes Gateway API is being developed to address the limitations of the existing Ingress API. Ingress API doesn’t offer enough features out of the box requiring infrastructure operations teams to fill the remaining 70-80% of the interface with annotations to cover what cluster operators and application developers require. This forces users to maintain bespoke configurations for each infrastructure provider they use. Moreover, it also lacks functionality for allocating portions of the cluster to different teams or applications, leading to either the cumbersome setup of multiple controller instances or forcing cluster providers to limit app developers’ control over their deployment strategies.

The Gateway API addresses these challenges, enabling a more flexible and secure environment for managing networking into Kubernetes. It overcomes the issue of limited functionality through routes, which establish a set of rules that contain Matches and Filters to support any desired matching logic or transformation needed by app developers.

This means users don’t need to maintain bespoke configurations for each environment and eliminates friction when migrating from one platform to another as the Gateway API abstracts connectivity by providing a common interface into Kubernetes. Furthermore, the Gateway API’s role-based framework allows individual app developers to integrate with the same gateway independently, without impacting each other’s services.

Bookmark this sectionWhat’s next?

The ngrok Kubernetes Operator currently supports the creation of Gateways, HTTPRoutes, and the core filters on those routes. We’ve also added support for the Traffic Policy engine, which lets you compose API gateway functionality into how your K8s-based APIs and apps respond adding complexity to your clusters.

This is particularly useful for adding traffic management to your Gateways and Routes when you’d otherwise be limited by what the Gateway API offers you in terms of matches, filters, references, and name matching—see our NgrokTrafficPolicy CR docs for details.

Curious about where else the ngrok Kubernetes Operator is headed on its road to v1.0 ? Read our blog post on how ngrok is now your Kubernetes-native ingress.

We’re also working to support Gateway API v1.2, released in October 2024, which includes timeouts, propagation of labels/annotations, and other protocols.

Bookmark this sectionGet started with the ngrok Operator today

• Documentation: Detailed usage, operational, and configuration documentation.

• Open source repo: Star the repository on GitHub to follow along, or create an issue if you’d like to see some changes to how ngrok implements Gateway API!

If you don’t have an account, you can sign up today to get started with ngrok. Questions? Contact us at support@ngrok.com.