InfrastructureLive in production

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.

0
Inbound ports
no port forwarding anywhere
4
Tunnel connections
healthy at time of writing
21
Probe coverage
ICMP, DNS, HTTP and TCP checks

Every figure above is measured or read from the running system.

Technology Stack

Cloudflare TunnelIngresscloudflaredConnectoringress-nginxOriginstep-caInternal PKIPowerDNSInternal DNS

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.

A visitor reaches Cloudflare, which terminates TLS. Inside the cluster a cloudflared connector dials outward to Cloudflare over QUIC. Traffic then reaches ingress-nginx on a NodePort. The home firewall forwards no ports.
The arrow out of the cluster is the whole point: nothing dials in.

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.