无法通过名称访问Kubernetes ClusterIP服务？求验证方法

一、初始连接超时的根本原因 #

你最初碰到的连接超时问题，本质是Service的Selector与Pod标签不匹配：你的Deployment给Pod打的标签是io.kompose.service: redis，但Service的Selector写的是app: redis，两者完全对不上，导致Service找不到对应的Pod，自然没法转发流量。这就是为啥你看到Service处于运行状态，但实际根本访问不通的原因。

二、验证ClusterIP服务可访问性的实用方法 #

针对你关心的「怎么验证ClusterIP服务能不能通过名称访问」这个问题，这里有几个靠谱的方法：

1. 在集群内的Pod中直接测试连通性 #

创建一个临时测试Pod（比如用busybox镜像），进入Pod内部后用工具测试：

# 创建临时测试Pod，退出后会自动删除
kubectl run -it --rm --image=busybox:1.36 test-pod -- sh

# 进入Pod后，先安装telnet（如果镜像自带的话可以跳过）
apk add telnet

# 用telnet测试服务端口是否能连通
telnet redis-svc 6379
# 或者用nc命令，更简洁
nc -zv redis-svc 6379

# 如果需要测试Redis本身的可用性，可以安装redis-cli
apk add redis-cli
redis-cli -h redis-svc ping

如果连通正常，telnet会进入交互界面，nc会输出redis-svc (10.x.x.x:6379) open，redis-cli会返回PONG。

2. 检查Service的Endpoints状态 #

你之前说kubectl get endpoints没帮上忙，但其实它是排查Service问题的核心工具：正常情况下，Service的Endpoints应该包含对应Pod的IP和端口。执行命令：

kubectl get endpoints redis-svc

如果输出里的ENDPOINTS列显示了Pod的IP（比如192.168.xx.xx:6379），说明Service和Pod匹配成功；如果是空的，那肯定是Selector不匹配的问题。

3. 测试服务名称的DNS解析 #

在集群内的Pod中，测试服务名称是否能正常解析到ClusterIP：

# 在测试Pod中执行nslookup
nslookup redis-svc
# 或者用dig工具，需要先安装
apk add bind-tools
dig redis-svc.default.svc.cluster.local

如果能解析到Service的ClusterIP，说明集群DNS服务工作正常，接下来只需要确认端口连通性就行。

三、解决kubelet环境变量覆盖的问题 #

你后来遇到的「服务名称设为redis时，kubelet自动生成的REDIS_PORT覆盖自定义变量」的问题，有两种可行的解决思路：

1. 修改自定义环境变量的名称 #

既然kubelet会根据服务名称生成大写加下划线的环境变量，那你可以把PHP代码中读取的端口变量名改成其他的，比如REDIS_SERVER_PORT，然后在PHP的Deployment中配置：

spec:
  containers:
  - env:
    - name: REDIS_HOST
      value: redis
    - name: REDIS_SERVER_PORT
      value: "6379"
    # 其他容器配置...

同时修改PHP代码（比如Laravel的config/database.php），让它读取REDIS_SERVER_PORT而不是REDIS_PORT。

2. 禁用Service的环境变量注入 #

如果你不想修改代码，可以在Pod的Spec中设置enableServiceLinks: false，这样kubelet就不会自动注入所有Service相关的环境变量了：

spec:
  enableServiceLinks: false
  containers:
  - env:
    - name: REDIS_HOST
      value: redis
    - name: REDIS_PORT
      value: "6379"
    # 其他容器配置...

注意：这个设置会禁用所有Service的环境变量注入，如果你的应用还需要其他Service的环境变量，这种方法可能不适用，此时第一种方法会更合适。

内容的提问来源于stack exchange，提问作者Qiulang