Kubernetes ClusterIP Service未负载均衡仅单Pod处理请求原因排查

架构老林

2026-10-10

问题根因

核心原因是kubectl port-forward本身的实现逻辑限制：该命令仅会选择Service关联的任意一个后端Pod建立长连接进行流量转发，全程不会走ClusterIP的负载均衡分发逻辑，所有请求自然只会打到同一个Pod上。
次要可选项影响：如果未显式配置Service的sessionAffinity为None，开启了会话保持的情况下，来自同一客户端IP的请求也会固定转发到同一个Pod，但该配置项默认值就是None，不是你当前场景的问题诱因。

修复及验证方案

方式1：修改Service类型对外暴露

将Service类型改为NodePort（单集群/自建集群通用）或LoadBalancer（云厂商托管集群可用），直接通过对外暴露的地址发起请求，即可触发kube-proxy的负载均衡逻辑：

apiVersion: v1
kind: Service
metadata:
  labels:
    app: fibonacci-deployment
  name: fibonacci-deployment
spec:
  ports:
  - name: 8000-8000
    port: 8000
    protocol: TCP
    targetPort: 8000
  selector:
    app: fibonacci-deployment
  type: NodePort # 云托管集群可改为LoadBalancer
  sessionAffinity: None # 显式关闭会话保持，保证请求随机分发

部署完成后访问节点IP:分配的NodePort发起压测，即可看到流量分发到不同Pod。

方式2：集群内部发起请求验证

无需修改现有Service配置，直接在集群内启动临时测试容器，访问Service的内部域名即可验证负载均衡效果：

# 启动临时curl容器
kubectl run -it --rm --image=curlimages/curl curl-test -- sh
# 容器内执行压测，访问内部服务域名
counter=1
while :
do
  curl -s http://fibonacci-deployment.default.svc.cluster.local:8000/fib?n=$counter
  ((counter++))
done