Introducing support for the Kubernetes Gateway API in the ngrok Kubernetes Operator

We are excited to announce support for the Kubernetes Gateway API, now available in developer preview.

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 and edges 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. 

Let'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 <HOSTNAME> placeholder to represent an ngrok hostname like yourName.ngrok.app Go to the dashboard to reserve a domain. First let’s create our Gateway and GatewayClass objects

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: simple-gatewayclass
  namespace: ngrok-ingress-controller
spec:
  controllerName: ngrok.com/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: simple-gateway
  namespace: ngrok-ingress-controller
spec:
  gatewayClassName: simple-gatewayclass
  listeners:
    - protocol: HTTPS
      hostname: 
      port: 443
      tls: 
        mode: Terminate
        certificateRefs:
        - name: ngrokcert # ngrok generats a cert for you, so this field is just a placeholder to satisfy the gateway crd
      name: simple-listener

‍

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.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo-deploy
  namespace: ngrok-ingress-controller
spec:
  selector:
    matchLabels:
      app: http-echo-app
  replicas: 2
  template:
    metadata:
      labels:
        app: http-echo-app
    spec:
      containers:
      - name: http-echo-path2
        image: mendhak/http-https-echo:31
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo-svc
  namespace: ngrok-ingress-controller
  labels:
    app: http-echo-app
spec:
  ports:
  - name: http-echo-app
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: http-echo-app

‍

Now, let's make our HTTPRoute.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: simple-route
spec:
  parentRefs:
  - name: simple-gateway
  hostnames: [<HOSTNAME>]
  rules:
  - backendRefs:
    - name: http-echo-svc
      port: 80
      kind: Service

‍

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

   - protocol: HTTPS
      hostname: <HOSTNAME_2>
      port: 443
      tls: 
        mode: Terminate
        certificateRefs:
        - name: ngrokcert
      name: domain-two
    - protocol: HTTPS
      hostname: <HOSTNAME_3>
      port: 443
      tls: 
        mode: Terminate
        certificateRefs:
        - name: ngrokcert
      name: domain-three

‍

Let’s replace the Route’s Hostnames with the following:

hostnames:
  - <HOSTNAME_1>
  - <HOSTNAME_2>
  - <HOSTNAME_3>

‍

Next, let’s add some functionality to the HTTPRoute. We can do this by adding Rules with new Filters and Matches. For instance, if we want to add a certain request header whenever someone hits our service from a certain path we can do that with a simple rule containing a path match to select the rule, and a request header filter to add our desired header.

  - backendRefs:
    - name: http-echo-svc
      port: 80
    matches:
    - path:
        type: PathPrefix
        value: /paprika
    filters:
    - type: RequestHeaderModifier
      requestHeaderModifier:
        add:
          - name: paprika-header
            value: spicy-value

‍

Additionally, we can instead also create a response header whenever that path is reached.

    filters:
    - type: ResponseHeaderModifier
      responseHeaderModifier:
        add:
          - name: my-response-header-name
            value: my-header-value

‍

Now, if you want to redirect from one path to another there’s a rule for that! Firstly, set up a match on that route.

  - matches:
    - path:
        type: PathPrefix
        value: /pumpkin

‍

Then add a RequestRedirect filter to redirect to the destination path.

    filters:
    - type: RequestRedirect
      requestRedirect:
        scheme: https
        hostname: <HOSTNAME_1>
        statusCode: 301
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /paprika

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

Motivation: 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. 

What’s next?

The ngrok Kubernetes Operator currently supports the creation of Gateways, HTTPRoutes, and the core filters on those routes. We already have plans to support additional filters, including both the extended filter and support for the ngrok Policy Engine. As additional parts of the Gateway API spec transition from experimental to stable, such as the TCPRoute and TLSRoute objects, we will implement these as well.

Get started with the ngrok Kubernetes Gateway API integration

• Documentation: Detailed usage, operational and configuration documentation.
• Open Source Repo: Star the repository on GitHub to follow along!

If you don’t have an account, you can sign up today to get started with ngrok. Reach us on Twitter, the ngrok community on Slack, or contact us at support@ngrok.com and share your feedback on this developer preview of the Gateway API.