Kubernetes service links can crash an app that reads its own env prefix

Semaphore panicked on a bad Port value because Kubernetes injected SEMAPHORE_PORT=tcp://... for a Service with the same name. Turn off enableServiceLinks when the Service name matches the app, plus two migration gotchas from moving a config directory with a huge git checkout.

I moved a small Ansible UI called Semaphore into the cluster, and it crashed at startup with value of field 'Port' is not valid. The pod had been given no port setting at all, so where was the bad value coming from?

The cause is a Kubernetes default

For every Service in a namespace, Kubernetes injects environment variables into each pod: <SERVICE_NAME>_PORT, <SERVICE_NAME>_SERVICE_HOST and friends, with the name uppercased. My Service was called semaphore, so the pod got SEMAPHORE_PORT=tcp://10.x.x.x:80. Semaphore reads its config from variables with that same prefix, took tcp://... as the port, and gave up.

The fix is one line in the pod spec:

spec:
  enableServiceLinks: false

Nothing in the cluster depends on those variables, so I use it as a default whenever a Service’s name equals the application’s env prefix.

Two more things from the same migration

Semaphore’s wrapper writes a fresh config.json, with new encryption keys, only if none exists. The first empty start therefore creates one, and it has to be deleted before you copy the old one in. That file holds the key used to decrypt stored SSH keys, so it belongs in whatever backs the data up.

The other one was ESPHome. Its config directory held a three-gigabyte checkout of an icon font repository with about 170,000 files, and exactly one PNG from it was referenced. Grep only the top-level YAML, because a recursive grep crawls that tree over NFS for a long time, and copy just the files you find. I also left out the build cache and the PlatformIO directory, roughly a gigabyte between them, since ESPHome rebuilds those.