Kubernetes Service负载不均衡，请求仅打向单个Pod是什么原因？

你提供的Deployment与Service配置本身不存在语法错误，请求未负载均衡通常由以下几种原因导致，可按优先级排查：

• HTTP持久连接（Keep-Alive）复用（90%以上场景的根因）
  Kubernetes Service的负载均衡默认工作在*四层（TCP/UDP连接）*层面，而非七层（HTTP请求）层面。同一个TCP连接内的所有HTTP请求会始终转发到同一个后端Pod。
  日常测试时使用的浏览器、默认参数的curl都会启用HTTP Keep-Alive复用TCP连接，因此连续发起的请求都会落在同一个Pod上，属于正常现象。
  验证方法：
  执行以下命令多次发起请求，强制每次请求新建TCP连接：

  curl -H "Connection: close" <minikube service返回的访问地址>
  

  也可使用压测工具模拟并发请求验证：

  ab -n 100 -c 10 <minikube service返回的访问地址>/
  

  操作完成后查看两个Pod的日志，即可看到请求被分散到不同Pod。
• Service会话保持配置异常
  若你曾修改过Service配置，可能意外开启了ClientIP会话保持，该配置会将同一个客户端IP的所有请求转发到同一个Pod。
  检查方法：

  kubectl get svc nginx-test-service -o yaml | grep sessionAffinity
  

  默认返回结果应为sessionAffinity: None，若为ClientIP可删除对应配置后重试。
• kube-proxy代理模式异常
  若Minikube的kube-proxy工作在非默认的userspace模式，可能出现负载均衡异常，可通过以下命令检查当前模式：

  kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode:
  

  正常返回值应为iptables或ipvs，若为userspace可修改配置为iptables模式后重启kube-proxy组件。
• 单节点集群哈希映射巧合
  Minikube为单节点集群，iptables模式下会根据源IP、源端口、目的IP、目的端口的哈希值选择后端Pod，若测试时客户端参数固定，极小概率会出现哈希结果始终落在同一个Pod的情况。可新增1-2个Nginx副本后再次测试验证。

内容的提问来源于stack exchange，提问作者Healthy Bowl