This note came from a cluster where the existing cloudflared tunnel credentials had to be replaced rather than gently repaired.

That distinction matters. Once a tunnel identity changes, you are not just fixing a pod. You are rotating the trust material that the whole deployment uses.

Step 1: Install or Refresh cloudflared Locally

The local setup started by installing the package and confirming the version:

1
2
3

wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared-linux-amd64.deb
cloudflared -version

Step 2: Log In and Create a New Tunnel

Then authenticate and create the replacement tunnel:

1
2

cloudflared tunnel login
cloudflared tunnel create develop-cluster-vm-tunnel

The important output here is not just the tunnel name. It is the generated credential JSON and the local certificate material that cloudflared uses.

Step 3: Replace the Kubernetes Secrets

The cluster had been storing both the tunnel credentials and the Cloudflare certificate in Kubernetes secrets.

The practical rotation sequence was:

1
2
3
4
5
6
7
8
9

kubectl delete secret tunnel-credentials -n cloudflared
kubectl create secret generic tunnel-credentials \
  --from-file=credentials.json=/home/<user>/.cloudflared/<tunnel-id>.json \
  -n cloudflared

kubectl delete secret cloudflarecert -n cloudflared
kubectl create secret generic cloudflarecert \
  --from-file=/home/<user>/.cloudflared/cert.pem \
  -n cloudflared

That is the part I especially wanted to preserve from the original note: tunnel fixes in Kubernetes often become secret replacement tasks, not just deployment restarts.

Step 4: Update Config and Deployment

The note also rebuilt the ConfigMap and deployment around the new tunnel name and target service.

A cleaned-up example config looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

apiVersion: v1
kind: ConfigMap
metadata:
  name: cloudflared
  namespace: cloudflared
data:
  config.yaml: |
    tunnel: develop-cluster-vm-tunnel
    credentials-file: /etc/cloudflared/creds/credentials.json
    metrics: 0.0.0.0:2000
    no-autoupdate: true
    ingress:
      - hostname: develop-cluster-vm-tunnel.example.com
        service: ssh://10.0.0.10:2222
      - service: http_status:404

And then the deployment is recreated or updated to mount that config and the new secrets.

Why This Is Worth Keeping

I like this note because it shows a more complete repair path:

  • local cloudflared install
  • login refresh
  • tunnel recreation
  • Kubernetes secret replacement
  • config refresh
  • deployment replacement

That is a much more accurate picture of what “fix the tunnel” can mean in a Kubernetes environment.