Service 没有 selector，kubectl port-forward 无法转发

集群内的应用能通过 Service 连接外部数据库，本机执行 kubectl port-forward service/... 却得到 Service is defined without a selector。如果这个 Service 本来就用手动维护的 EndpointSlice 指向外部地址，错误并不表示数据库端点配置无效。

kubectl port-forward 最终要选择一个 Pod，建立到该 Pod 的转发。给命令传 Service 名称时，kubectl 用 Service 的 selector 找 Pod；没有 selector，就无法沿这条路径选择目标。EndpointSlice 中有可达 IP，也不会把外部数据库变成可转发的 Pod。

确认后端是什么

先读取实际对象。下面的空间和名称都需替换：

kubectl config current-context
kubectl -n team-data get service external-db -o yaml
kubectl -n team-data get endpointslice \
  -l kubernetes.io/service-name=external-db -o yaml

核对 spec.selector 是否缺失或为空，以及 EndpointSlice 的地址、端口、管理标签和可用的目标引用。外部数据库的端点可能没有 Pod 引用，不能只凭 IP 看起来像集群网段就认定它属于 Pod；需要与实际资源和网络拓扑核对。

无 selector 的 Service 是一种受支持的后端抽象。集群流量可以按它的端点转发，但 Kubernetes API server 不允许借它代理未映射到 Pod 的端点，以免 API 变成任意外部地址的访问代理。把 Service 改成 ExternalName 也不会补出 Pod selector。

普通 Service 有 selector，却找不到可用后端时，检查方向不同，可看标签与 EndpointSlice 就绪状态。

后端确实是已有 Pod 时，直接指定它

如果已经核实目标是自己有权访问的 Pod，可以指定实际 Pod，而不依赖这个无 selector 的 Service。例如数据库容器实际监听 5432，本机选用未占用的 15432：

kubectl -n team-data port-forward --address 127.0.0.1 \
  pod/verified-db-pod 15432:5432

这是启动本地监听和转发的命令，Pod 名称、空间与远端端口必须按真实对象填写。这里的远端端口是 Pod 内应用的监听端口，不一定等于 Service 的 port。保留本机回环地址，不为方便调试绑定所有网卡。

当前账户仍需具有相应的 Pod 转发权限。监听成功以后，用数据库客户端连接本机对应端口，验证身份、数据库名称及必要的查询；转发通了不等于数据库认证正确。Pod 终止会结束该转发会话，不能把它当作持续运行的连接入口。

外部数据库应使用已有授权连接路径

外部数据库没有对应 Pod 时，按它实际支持的路径连接：已有 VPN、专线、允许本机使用的原生入口，或能够访问数据库的已授权跳板机。选择路径前确认网络出口、账户权限、数据库 TLS 与现有运维要求。

如果组织已有 SSH 跳板机，本地隧道可以借该主机访问数据库，但需要核实隧道目的地址在跳板机上如何解析、数据库实际端口和主机身份。云数据库的身份代理则还受云账户权限、代理版本和出站网络限制；不能把其他数据库类型的代理命令直接换个名字照用。

不要给外部数据库 Service 随意增加 selector 来消除报错。selector 会改变后端管理语义，可能开始选择集群内另一批 Pod。临时部署代理 Pod 也需要新增访问权限和持续维护，不能未经评估就作为默认修复。

最终验证所选路径确实到达预期数据库，本地监听范围符合要求，原来集群内的 Service 连接仍正常。调试完成后结束转发或隧道，保留原有数据库入口与访问控制。