Kubernetes中NodePort服务端口冲突问题分析与解决方案

问题背景

在Kubernetes集群中部署多个GPU服务器（如H200、A100、V100、P100等）时，用户遇到了一个特殊的网络连接问题。当通过NodePort服务暴露SSH端口时，即使不同节点使用相同的端口号（如30001），理论上应该能够通过不同节点的IP地址区分服务，但实际运行中却出现了连接错乱的情况。

现象描述

具体表现为两种异常情况：

1. 当通过SSH连接特定节点的NodePort时（如10.190.1.1:30001），连接会被错误地路由到其他节点的服务（如10.190.1.2上运行的Pod）
2. 部署在不同节点但使用相同端口的LLM推理服务也会出现请求被错误路由的情况

技术原理分析

在Kubernetes中，NodePort服务的工作原理是：

1. 每个NodePort服务会在所有集群节点上监听指定的端口
2. 当流量到达任何节点的NodePort时，kube-proxy会根据服务定义将流量转发到后端Pod
3. 默认情况下，NodePort服务的流量会通过轮询方式负载均衡到所有匹配的Pod

问题的根源在于用户配置方式：

• 为多个Pod使用了相同的服务选择器（如ai.allegro.agent.serial: pod-1）
• 创建了多个NodePort服务指向这些Pod
• 期望通过不同节点IP+相同端口来区分服务，这与Kubernetes的服务发现机制存在冲突

解决方案

方案一：为每个Pod创建独立的NodePort服务

为每个需要SSH访问的Pod创建独立的NodePort服务，并分配不同的端口号。例如：

# Pod A的服务
apiVersion: v1
kind: Service
metadata:
  name: pod-a-ssh
spec:
  type: NodePort
  ports:
  - port: 10022
    nodePort: 30001
  selector:
    ai.allegro.agent.serial: pod-a

# Pod B的服务
apiVersion: v1
kind: Service
metadata:
  name: pod-b-ssh
spec:
  type: NodePort
  ports:
  - port: 10022
    nodePort: 30002
  selector:
    ai.allegro.agent.serial: pod-b

方案二：使用HostPort直接暴露Pod端口

在Pod定义中直接使用hostPort属性，将容器端口映射到宿主机端口：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    ports:
    - containerPort: 10022
      hostPort: 30001

这种方式直接将Pod端口绑定到所在节点的指定端口，避免了服务层的负载均衡。

方案比较

方案	优点	缺点
独立NodePort服务	符合Kubernetes服务模型，便于管理	需要管理多个服务对象
HostPort直接暴露	连接直接，性能损耗小	需要确保Pod调度到特定节点

最佳实践建议

1. 对于需要直接访问的调试类服务（如SSH），推荐使用HostPort方式
2. 对于生产环境服务，建议使用独立的NodePort服务配合节点亲和性调度
3. 避免为多个Pod使用相同的服务选择器，除非确实需要负载均衡
4. 考虑使用ClusterIP服务配合Ingress控制器来管理外部访问

总结

Kubernetes的网络模型提供了多种服务暴露方式，理解NodePort服务的工作原理对于正确配置服务至关重要。当需要直接访问特定Pod时，应该避免依赖节点IP+端口的方式，而应该采用更明确的访问路径设计。通过合理选择服务暴露方式，可以避免端口冲突和连接错乱的问题。