Kubernetes 的 REDIS_PORT 变成 tcp:// 地址，应用无法解析端口

应用未配置 REDIS_PORT，本来准备使用默认端口 6379，部署到 Kubernetes 后却在启动时报告端口不是整数。容器实际环境中出现了类似 REDIS_PORT=tcp://10.0.0.11:6379 的值时，检查同命名空间内是否有名为 redis 的 Service，以及 Pod 是否启用了 Service 环境变量注入。

这不是 Redis 改了端口类型，而是应用使用的变量名与 Kubernetes 的兼容服务发现变量相撞。必须先确认实际变量来源；Helm、ConfigMap、镜像或入口脚本也可能设置同名变量。

REDIS_PORT 与 REDIS_SERVICE_PORT 含义不同

对于有 ClusterIP、首个端口为 TCP 6379 的 redis Service，kubelet 可以生成下面这类环境变量：

REDIS_SERVICE_HOST=10.0.0.11
REDIS_SERVICE_PORT=6379
REDIS_PORT=tcp://10.0.0.11:6379

地址只是示意。带 SERVICE_PORT 的值是端口数字，而兼容旧容器链接形式的 REDIS_PORT 是协议加地址。应用恰好把后一个名称作为整数端口配置时，原来的“未设置就使用默认值”分支不再成立。

Service 名会转成大写，连字符转成下划线，所以类似名称也可能与其他应用变量碰撞。这里的普通注入限于相关命名空间，并要求 Service 具有可用 ClusterIP；不能把所有 Service 类型和跨命名空间对象都当成同一来源。

对照 Pod 声明与容器实际环境

以下名称为占位值。先在受控终端查看实际 Pod、工作负载模板及目标 Service：

kubectl -n app get pod worker-pod -o yaml
kubectl -n app get service redis -o yaml
kubectl -n app exec worker-pod -c worker -- printenv REDIS_PORT

第三条要求容器正在运行且已有 printenv；只查看已经确认不含秘密的端口字段，不输出整个环境。Pod 启动就退出时，使用已有启动日志或隔离诊断入口，不为取值把生产入口改成长期 shell。

检查 env、envFrom、enableServiceLinks，以及最终进程是否由入口再次改写变量。显式容器环境变量优先于同名 Service 注入，因此清单里已经明确写了数字、进程却得到 URL 时，还要核对实际 Pod、选中的容器与启动链，不能继续只怪 Service。

自动变量是在构造容器环境时加入的，并不作为 env 项全部回写到 Pod 清单。清单没有 REDIS_PORT，不足以证明进程环境中没有它。Service 与容器创建的先后也会影响注入内容；这不是随 Service 更新实时同步的配置。

明确应用参数，或关闭不需要的普通 Service 注入

只处理这个应用端口时，可在原模板中明确设置应用真正使用的值：

env:
  - name: REDIS_PORT
    value: "6379"

这是假设业务确实使用 6379 的配置片段，不能据此更改实际 Redis 监听端口。地址、认证与其他参数仍按应用自己的契约配置，修复数字解析不代表连接已经成功。

如果应用已经通过 DNS 发现服务，且确认没有依赖普通 Service 注入的变量，可以在工作负载的 Pod 模板中设置：

spec:
  template:
    spec:
      enableServiceLinks: false

独立 Pod 的字段位于 spec 下，不包含 template；应按原对象结构合并。关闭前检查入口与所有容器是否依赖这类变量，不能把一个应用的碰撞问题扩大成未经核对的全命名空间策略。

这个开关也不保证清空所有与 Kubernetes 有关的环境变量。已经核对的 Kubernetes 1.35.0 实现仍有 API Service 的特殊注入路径，KUBERNETES_* 等变量可能保留。

新 Pod 才能采用新的环境构造

保存原模板、参数来源和镜像，通过 Helm、GitOps 或已有发布入口变更，再按工作负载更新策略替换受影响 Pod。不要只改一份本地 YAML，也不要删除 redis Service 来避免注入；后者会同时影响真正使用它的客户端。

新 Pod 中核对端口字段来源与值，再验证应用启动、目标服务解析和连接。所有副本都应检查，不能用一个新 Pod 的结果代表尚未替换的旧副本。

若还有 ConfigMap 更新后环境未变化的问题，可另看旧 Pod 环境不会自动更新。回退时恢复配套模板与配置来源，再安排受控替换；单独回滚模板不会自动恢复同名 ConfigMap 的旧内容。