Kubernetes无头服务端口转发为何始终路由至同一Pod？

问题背景 #

执行以下命令针对无头服务进行端口转发：

kubectl port-forward service/mongodb-headless 27017:27017 -n mongodb

已知无头服务不做负载均衡也不代理请求至后端Pod，但实际观察到该命令始终连接到同一个后端Pod（初始选择看似随机）。调研发现对无头服务的FQDN做DNS查询时，会以轮询方式返回所有后端Pod的IP，但无论重新执行端口转发操作还是重新部署无头服务，始终固定连接同一个Pod。

需明确以下问题：

• 为何针对无头服务的端口转发会将Pod端口绑定到本地端口？
• 会选择哪个后端Pod（比如3个中的1个）进行绑定？
• 为何无头服务始终固定连接同一个Pod？

解答 #

1. 端口绑定的本质原因 #

kubectl port-forward的核心是直接搭建本地与集群内Pod的网络隧道，不管目标是Service还是Pod本身。当指定目标为无头服务时，kubectl会先通过API Server获取该服务关联的所有后端Pod，然后挑选其中一个，后续逻辑就和直接转发Pod端口完全一致——绕开Service的代理环节，直接打通本地到Pod的通道，所以最终表现为把Pod的端口绑定到本地端口。

2. 后端Pod的选择逻辑 #

初始选择是在Ready状态的后端Pod中随机挑选。kubectl会基于无头服务的标签选择器，从API Server拉取符合条件的Pod列表，然后随机选中一个可用Pod。

3. 固定连接同一Pod的原因 #

这是因为kubectl会缓存第一次选中的Pod信息。后续即便重新执行port-forward命令或重新部署无头服务，只要之前选中的Pod还存在（名称、UID未变），kubectl就会复用缓存的Pod记录，不会重新触发随机选择。如果想切换到其他Pod，可以：

• 手动指定具体Pod转发：kubectl port-forward pod/mongodb-0 27017:27017 -n mongodb
• 清理kubectl本地缓存（如Linux系统下的~/.kube/cache目录）后重新执行服务转发命令

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