Digital Ocean Kubernetes集群Nginx双节点访问异常疑问求助

嘿，这两个问题其实都和Kubernetes的Service（尤其是NodePort类型）以及负载均衡的工作机制有关，我来一步步给你拆解清楚：

这是NodePort类型Service的核心特性之一：当你创建NodePort Service时，Kubernetes会在集群的所有节点上都打开指定的端口（这里是32134），不管节点上有没有运行对应的Pod。

每个节点上的kube-proxy组件会负责处理这个端口的流量——它会通过集群内部的Service网络，把请求转发到任何一个处于Ready状态的目标Pod上（哪怕Pod不在当前节点）。所以当你访问node02的32134端口时，node02的kube-proxy会把请求转发到node01上的Nginx Pod，自然就能拿到正常的200响应了。

这种情况通常有几个常见原因，你可以逐一排查：

• Pod就绪状态异常：首先检查nginx-002的就绪探针（Readiness Probe）是否正常工作。如果就绪探针失败，Kubernetes会自动把这个Pod从Service的端点列表中移除，不会给它分配流量。你可以用以下命令确认：

  # 查看Pod的详细状态，重点看Events里的就绪检查信息
  kubectl describe pod nginx-002
  # 查看Service的端点列表，看看是否包含nginx-002的IP
  kubectl get endpoints <你的Nginx Service名称>
  

• 会话亲和性（Session Affinity）设置：如果你的Service配置了sessionAffinity: ClientIP，那么来自同一个客户端IP的请求会被固定转发到同一个Pod。如果你的所有测试都是从同一台机器发起的，就会出现所有流量都流向nginx-001的情况。你可以用kubectl describe service <你的Nginx Service名称>查看Session Affinity的配置项。

• 长连接导致的流量固定：kube-proxy默认的iptables模式下，负载均衡是随机/轮询的，但如果客户端和Pod之间保持了HTTP长连接（比如浏览器默认会保持长连接），那么在连接断开前，所有请求都会走同一个Pod。你可以尝试关闭浏览器重新发起请求，或者用不同的客户端（比如另一台机器）访问，看看是否会切换到nginx-002。

• 标签与Service选择器不匹配：虽然是同一个Deployment的Pod，但偶尔也可能出现标签异常的情况。你可以对比Pod标签和Service的选择器：

  # 查看nginx-002的标签
  kubectl get pod nginx-002 --show-labels
  # 查看Service的选择器
  kubectl get service <你的Nginx Service名称> -o yaml | grep -A 3 selector
  

如果排查后还是没找到原因，可以把上面命令的输出贴出来，能更精准地定位问题~

内容的提问来源于stack exchange，提问作者Ronaldo Lanhellas