在Kubernetes Service的配置中，nodePort、port和 targetPort承担着不同的网络流量转发角色。简单来说：
-
port ：Service在集群内部的访问端口，其他服务通过
<ClusterIP>:<port>访问该Service。 -
targetPort：Service将流量转发到的Pod上的实际端口，必须与Pod内容器监听的端口一致。
-
nodePort ：在集群每个节点上开放的端口，允许外部客户端通过
<任意节点IP>:<nodePort>访问Service。
下面这个表格更清晰地展示了它们的区别：
| 端口类型 | 作用层级 | 主要用途 | 访问方式示例 | 是否必选 |
|---|---|---|---|---|
| port | Service 集群内部虚拟IP | 集群内服务间通信 | 10.96.123.456:80(ClusterIP:port) |
是 |
| targetPort | Pod/容器 | 指定流量最终到达容器的端口 | 由Service自动转发，通常不直接访问 | 否，默认与port相同 |
| nodePort | 集群节点(Node) | 从集群外部访问服务 | http://<节点IP>:32556 |
否，仅NodePort/LoadBalancer类型需要 |
端口协作流程
当有一个外部请求到来时，这些端口会按照一条清晰的路径协作，最终将流量送达正确的容器：
外部请求 → nodePort(节点IP上的端口) → port(Service的端口) → targetPort(Pod内容器的端口)
例如，service配置（nodePort: 32556, port: 13000, targetPort: 13000）：
-
外部用户通过浏览器访问
http://<任意节点IP>:32556。 -
该节点的
kube-proxy接收到请求，并根据Service规则将其转发到Service的ClusterIP上的13000端口。 -
Service的负载均衡机制将请求路由到某个健康Pod的13000端口，最终被Pod内运行的应用程序处理。
配置要点与示例
-
targetPort的灵活性 ：
targetPort可以是数字，也可以是Pod定义中命名的端口，这增加了配置的灵活性和可读性。例如，在Pod模板中，您可以定义name: http，然后在Service中设置targetPort: http。 -
端口映射无需一致 ：这三个端口的编号不需要相同。一个常见的场景是，让Service在80端口（
port: 80）对外提供HTTP服务，而实际的应用容器在8080端口（targetPort: 8080）进行监听。 -
containerPort的角色 ：在Pod的YAML定义中，还有一个
containerPort字段。它主要用于声明容器会监听哪个端口，起 informational（告知性）作用。即使不设置，只要容器进程确实在该端口监听，Service也能将流量转发过去。通常建议设置，以明确容器的网络契约。
注意事项
-
nodePort端口范围 ：如果您不显式指定
nodePort，Kubernetes会在30000-32767范围内自动分配一个。如果您需要指定，则必须在此范围内。 -
生产环境考虑 ：虽然
NodePort类型很方便，但对于高可用的生产环境，通常建议使用更高级的入口方式，如Ingress，它能提供基于域名和路径的路由、SSL终止等更强大的功能。