Why a Kubernetes Service named redis can break your app's REDIS_PORT

After a routine restart, this Python app crashed because REDIS_PORT held a URL, not a number. It had run fine for days, and the manifest never set REDIS_PORT. So the code fell back on whatever the environment provided, and int() couldn't parse tcp://10.96.12.4:6379.

The cause is kubelet, the node agent that starts your container. At start, it takes the variables from your Pod spec and merges them with variables generated for every Service that already exists in the same namespace. So the Service named redis quietly adds its own variables to the container's environment.

Kubernetes builds these names from the Service name: uppercase it, and turn dashes into underscores. Here, redis becomes REDIS. You get REDIS_SERVICE_HOST and REDIS_SERVICE_PORT first. Then come the Docker-links-style variables, and REDIS_PORT is a full URL, tcp colon slash slash 10.96.12.4, port 6379. That's the name your app reads.

Follow the timeline. The kubelet starts the old Pod before the Service exists, so it gets no REDIS variables. Then the Service redis is created, and the kubelet sees it, but the old Pod's environment stays unchanged. Days later, a rollout restart starts a new Pod, and only now does REDIS_PORT get injected. The crash follows a harmless restart.

Three rules explain all of this. The names come from Services, so another team's Service called redis decides your variable names. They're set only at container start, so running Pods never update. And explicit env entries in your spec win over injected ones.

Follow the decision on screen. If REDIS_PORT is in your spec, your value takes precedence, and the app runs. If it's missing, the injected URL fills the slot, so the fallback default never runs, and int() hits that URL and crashes. Optional variables with defaults are the vulnerable case.

Here are two fixes in the Deployment's Pod template. First, enableServiceLinks set to false stops Kubernetes from injecting those Docker-links-style variables, so REDIS_PORT never appears. Second, the app reads a prefixed name, MYAPP_REDIS_PORT, set explicitly to 6379. No Service can collide with that. Either change prevents the crash.

Each fix has a cost. Disabling service links is clean, but legacy code might read those injected variables, so check first. Prefixing avoids collisions, though it needs an app change. An explicit REDIS_PORT works too, but every Pod has to carry it.

The usual path is DNS. The app Pod asks cluster DNS to resolve redis, or redis.shop from another namespace, and DNS returns the Service address, 10.96.12.4. The Service then forwards to the Redis Pod on port 6379. The lookup happens at query time, so creation order doesn't matter. That's why many teams turn service links off.

At container start, kubelet stamps existing Services into your env. So prefix your app variables or disable service links, and discover Services through DNS.