Public Edge Without Inbound Ports
Exposing an on-premise Kubernetes cluster to the internet through a Cloudflare tunnel, while the existing production site keeps serving as the rollback.
An on-premise Kubernetes cluster reachable from the internet with zero inbound ports, staged so the live site stayed untouched as the rollback.
- Role
- Solo: designed, built and operate
- Timeframe
- Sep 2026 to present
- tunnel created 20 Sep 2026
- Team
- 1
- Problem
- Serving from the home cluster without exposing a home IP, and without risking the site recruiters actually visit.
- Approach
- A separate Cloudflare tunnel with its own credentials, a connector on a control-plane node dialling out, ingress on a pinned NodePort, the apex record protected by the deploy script, and layered checks ending with the public hostname answering.
- Result
- Public traffic reaches my ingress through the tunnel (the first success was a 404 from my own nginx). 4 connections healthy, 22 synthetic probes, certificate expiry graphed for every endpoint.
Every figure above is measured or read from the running system. Where a figure has a source line, that is how and when it was read.
Technology Stack
Shape
Traffic reaches Cloudflare, travels down an outbound-only tunnel to a connector running on a production control-plane node, and lands on the cluster's ingress controller at a pinned node port. Nothing listens on the public internet and no router rule was changed.
I created a separate tunnel rather than extending the existing one, so it has its own credentials and its own failure domain and can be deleted without touching anything already working.
Migrating a live job-hunt asset carefully
The site this would eventually serve is the one recruiters actually visit, so the cutover is staged rather than clever. The new path was proved on a subdomain first while the existing production hosting kept serving the apex untouched, and the deployment script refuses to modify the apex record at all.
The first success was a 404, served by my own ingress controller, from the public internet, through the tunnel. That is exactly the right result when no application is deployed behind it yet, and it proves the whole path end to end.
Signals that test the path, not the parts
A tunnel reporting 'healthy' only means a connector attached. It says nothing about whether the hostname reaches a live origin, which is the same 'green at every step, producing nothing' shape as a pipeline that runs perfectly and emits no output.
So the checks are layered: connections, connector process, and the one that matters most, the public hostname answering. That last check treats any 2xx through 4xx as success, because a 404 proves my nginx answered, while a 502 means the origin is dead. Certificate expiry is tracked as a graph for every endpoint, after an internal certificate expired unnoticed and broke continuous integration for several hours.