Port-forward 端口转发
快速把集群内服务转到本地端口。
kubectl port-forward 适合本地调试，把集群内的 Pod 或 Service 暴露到本机端口。
常见用法
kubectl port-forward svc/api 8080:80
kubectl port-forward pod/api-7c9d8d9c8c-abcde 8080:80
适用场景
- 快速验证 API
- 本地 UI 访问
- 临时排查问题
注意事项
- 仅适合开发调试，不适合生产流量
- 端口占用冲突时换本地端口
用 port-forward 的“正确姿势”
port-forward 更像一根临时网线：你用它来快速确认“服务到底通不通”，而不是用它当长期访问方案。
我自己最常用的两种方式：
- 先转发 Service（更像真实流量入口）
- 再转发 Pod（怀疑 Service/selector 有问题时用）
kubectl get svc -n <ns>
kubectl port-forward -n <ns> svc/<svc> 18080:80
kubectl get pods -n <ns>
kubectl port-forward -n <ns> pod/<pod> 18080:80
几个很常见的坑也顺手说一下：
- 本地端口被占用（换成 18080/28080 之类就行）
- 转发到了错误的 namespace/context（看一眼
kubectl config get-contexts） - 你以为在转发 0.0.0.0，其实默认只监听 127.0.0.1（需要给同局域网访问时再加
--address 0.0.0.0） - 集群里 Service 没有 endpoints，转发 Service 当然也不通（先
kubectl get endpoints -n <ns> <svc>）
网络身份与服务发现
Kubernetes 网络强调“稳定名称”而不是“稳定 IP”。Service 提供稳定的虚拟 IP 和 DNS 名称，Endpoints 会追踪后端 Pod。端口转发 是在这个模型上构建网络访问与发现规则的关键环节。
Service 类型与路由选择
ClusterIP 适合内部访问，NodePort 与 LoadBalancer 用于对外暴露，Ingress 则负责 HTTP 路由与域名管理。选择何种类型取决于环境与流量路径，建议明确哪些入口是用户访问、哪些是内部调用、哪些仅用于调试。
Headless 与直连模式
Headless Service 不创建虚拟 IP，而是直接发布 Pod IP，适合需要固定地址或集群内 peer 发现的系统。此时客户端需要自行处理连接均衡与故障转移，但可以获得更直接的拓扑控制。
Port forward 的定位与限制
端口转发适合临时调试，不改变集群网络配置即可从本地访问 Pod 或 Service。它不应作为生产访问方式，也不适合长期自动化。需要常规访问时，应设计正式的 Service 或 Ingress。
DNS 命名习惯
Kubernetes DNS 支持短名称与完整名称，跨命名空间时建议使用 service.namespace 形式。稳定的命名规则可以减少配置混乱，提升团队协作效率。
外部流量路径
外部流量通常经过负载均衡、NodePort、kube-proxy 到达 Pod，每一跳都会引入超时与失败点。排障时应按路径逐段确认连接状态。
安全与策略
NetworkPolicy 可能阻断通信，即便 DNS 能解析也无法连通。若使用 mTLS 或服务网格策略，要确保策略与 Service 选择器一致，避免意外断流。
运维建议
统一命名规则便于 DNS 预测。上线时关注 endpoints 是否及时更新，尤其是在滚动更新期间。外部流量要设置健康检查与超时策略，避免负载均衡层把请求打到不可用实例。
kubectl get svc -n demo
kubectl get endpoints -n demo
kubectl get endpointslices -n demo
kubectl port-forward svc/demo-api 8080:80 -n demo
收个尾：把它当成“临时网线”就对了
port-forward 的价值基本就两点：
- 你想快速确认应用接口到底回不回应
- 你想把问题切开：到底是应用问题，还是 Service/Ingress/网络链路问题
如果 port-forward Pod 能通、但 port-forward Service 不通，八成就是 selector/endpoints 有问题；如果两者都不通，才更像应用本身或容器内端口配置的问题。