Build your developer-defined "golden path" with the Kubernetes Gateway API and ngrok
By Joel Hans
April 25, 2024
By Joel Hans
April 25, 2024
Pundits and influencers have spent many a cycle gabbing about how DevOps and platform engineers must start building “golden paths” for their developer peers. Give these folks the right toolkit, and they’ll build faster, more consistently, and with security in mind… right?
The reality of golden paths has instead been DevOps and platform engineers gluing together a dozen open-source projects, layering in endless policy guardrails, and hoping that’ll keep developers in check. In practice, developers tend to know best about which tools are useful and which are unneeded and taxing cognitive load. They err on the side of homegrown solutions, much to the chagrin of anyone in operations, because it creates more tickets and handshakes required to configure secure ingress and networking at the cluster level.
The new Kubernetes Gateway API is emerging as not just a new and “better” way of configuring ingress and east-west traffic. It flips the concept of golden paths around entirely, making them no longer mandated by operations, but defined by developers.
As a developer, you can coordinate with your DevOps or platform engineering peers once to create a golden path that allows you to deploy quickly and focus on business requirements, not networking nuances, through a minimally viable configuration interface. You no longer deal with the sheer fiction of learning Kubernetes networking, and you free your peers from the friction of constantly setting up new deployments and enforcing compliance-level policy.
With the Kubernetes Gateway API, less is more. Even less—thanks to the ngrok Kubernetes Operator—is one step better.
The Kubernetes Gateway API replaces the "old" ingress controller-based method of managing traffic with persona- and role-based definitions for ingress, load balancers, service meshes, and more. Instead of offering a single ingress API for all folks who touch Kubernetes configurations, the Gateway API maps roles you’ll most commonly find in organizations using k8s to tightly-scoped objects:
Infrastructure providers -> GatewayClass, which defines multiple Gateways using one configuration and similar behavior.
Cluster operators -> Gateway, which defines how traffic moves between services within the cluster.
Application developers -> HTTPRoute, which maps requests from a Gateway to a Kubernetes service.
Unfortunately, the role-based interface also maps to the same story of the operations-defined golden path for deploying apps on Kubernetes. Even the basic north/south use case illustrates a top-down approach where the infrastructure provider and cluster operator control all deployment phases, and developers can build against this only after exposing just the tiniest slivers of the cluster.
Instead, we see the Kubernetes Gateway API as an interface for developer enablement by building their definition of a golden path:
GatewayClass and Gateway, along with any security policies and governance guardrails.HTTPRoute and update the existing Gateway with a new listener to reference your domain—without worrying about exactly what’s happening under the hood at the GatewayClass and Gateway level.It can’t be that simple… can it? How does this actually work without offloading all the nuance of Kubernetes networking onto you?
With this new minimally viable Gateway API for mapping requests to services, you can deliverapps much faster— without worrying that you’ll break the cluster or accidentally punch a massive hole in the operations-defined VPC. That’s a big step in the right direction for developer experience.
But if you only go this far, you’re still beholden to other teams for initial setup and ongoing maintenance.
You can configure a HTTPRoute for each new app and service, but your operational peers are still responsible for maintaining the health of the cluster, its security and its complex networking stack.
If you wanted to help them more, you’d have to upskill yourself on Kubernetes networking using production resources… and no one wants you to resort to that.
That’s why ngrok lives at the heart of this new developer-defined golden path.
Typically, you need to stitch together many different solutions and tools or write custom code to handle performance, security, observability, and availability requirements. With ngrok, you get all of that and more out of the box:
Certificate management: Instead of installing and managing cert-manager, let ngrok automatically provision and manage certificates on your behalf—more on that in a moment.
Observability: With no additional infrastructure, you can view traffic flows and events in real time using the ngrok Traffic Inspector and Events Subscriptions dashboards. You can even forward configuration audit logs to your security information and event management (SIEM) platform for security transparency.
Global load balancing: Minimize latency to your apps and APIs by using ngrok’s intelligent routing for both end-user and agent traffic. No matter where your users are, they’ll connect to the fastest Point of Presence (PoP), which also includes failover for high availability.
Global acceleration: With your traffic policies pushed to the ngrok global network, handshakes like authentication, transformation, and load balancing happen as close to your customers’ requests as possible.
DDoS protection: ngrok enforces your authentication and authorization policies at the edge, blocking attacks and misconfigurations from denial-of-service-ing your apps, which saves your operations peers a lot of headache, worry, and looking at observability data for clues about how to best respond.
This combination lets you not only flip the direction of the golden path, but define it only once.
When you use the Kubernetes Gateway API alone, someone still needs to generate TLS certificates using cert-manager and manually add them to the listeners on your Gateway for each domain your applications need to listen on. If those certificates exist in a different namespace than the Gateway, they will also need to add a ReferenceGrant to validate a cross-namespace reference.
That’s another manual task for your DevOps/IT peers, who are already responsible for generating the TLS certificates with the right Subject CN. Once your cluster provisions the gateway controller and load balancer, they can read the newly-allocated external IP address to create a new DNS record.
Only then can you write your HTTPRoute to map paths to services and start serving traffic from the public internet.
You might be happy with the end result, but your peers are still responsible for administering and renewing TLS certificates on your behalf forever… or at least until your company “exits” in one fashion or another.
When you pair ngrok with the Kubernetes Gateway API, you only need to configure domains and TLS once: add a wildcard domain to ngrok and update your DNS.
With every new listener on your Gateway, apply a tls.certificateRefs.name: ngrokcert configuration and watch ngrok and the Kubernetes Operator handle the rest by automatically:
Creating a new domain using your DNS wildcard and the hostname you specified in the listener.
Provisioning a new TLS certificate matching your domain.
Mapping your new domain and the IP address of the backend service you deployed on your Kubernetes cluster.
Enforcing HTTPS/TLS in the ngrok Cloud, with simple options to enable authentication/authorization.
Making maintenance a breeze in the ngrok dashboard.
For your peers, that's a pretty obvious golden path—by pitching into a better developer experience the one time you define the Gateway API, they also simplify their operational burden. In Kubernetes, that’s a very rare win-win.
No-hands TLS management wasn’t good enough for you? Let’s get even closer to home.
Every application destined for deployment on a Kubernetes cluster should undergo some local testing. The problem isn’t setting up a local Kubernetes environment—projects like Minikube, MicroK8s, and k3s are perfect for this use case. The problem is that there’s no overlap between your local k8s cluster and your target production cluster when it comes to networking and ingress.
Applying your production Gateway API configuration to your local cluster won’t work—there’s too much operator-level work, like maintaining TLS certificates and domains, for you to replicate locally. Instead, you’re forced to build on a test environment and hope the networking works when moving to production.
When you use the ngrok Kubernetes Operator and the Gateway API together, you’re always interfacing with the same ngrok Cloud no matter the environment. By abstracting traffic, certificate, and DNS management to ngrok, your Kubernetes manifests configure ingress identically on every k8s environment, from Minikube to GKE, letting you expose local environments to peers, hook into existing CI/CD pipelines, and more.
As a developer, that means true environmental independence to develop however works best for you—without that classic "it works on my incomprehensibly bespoke k8s environment! " argument.
The beauty of combining the ngrok Kubernetes Operator with the Kubernetes Gateway API is that it’s truly developer-defined.
After a single handshake with your friends in DevOps, platform engineering, or IT, your golden path is ready for you to own and operate.
The next time you want to deploy another service into the same cluster, you have more ownership to create a new namespace, apply your deployment, and attach a new HTTPRoute to the existing Gateway, with domains and TLS certificates handled for you automatically.
To get started building your golden path, check out the open-source ngrok Kubernetes Operator project and our deployment documentation, which walks you through installing the Operator through Helm and installing your first simple GatewayClass object.
If you’re still curious about the ngrok Kubernetes Operator, you can always deep-dive into what it does differently from the sea of alternative implementations.
Questions or comments? Hit us up on X (aka Twitter) @ngrokhq or LinkedIn, or join our community on Slack.