Kubernetes多Pod服务中gRPC流连接能否始终保持粘性？

是的，在Kubernetes环境下，gRPC流连接可以稳定保持粘性，完全满足你“主实例处理所有请求、备用实例仅故障切换”的需求，但需要满足几个关键条件，同时注意故障切换时的细节。

一、gRPC连接粘性的本质 #

gRPC基于HTTP/2协议，一个HTTP/2连接可承载多个gRPC流。一旦客户端与某个服务实例建立起HTTP/2连接，后续所有新创建的gRPC流都会复用这个连接——除非连接因故障、超时等原因断开。

在Kubernetes中，Service对gRPC的默认负载均衡逻辑是基于连接的：只有在客户端发起新连接请求时，Service才会从可用端点列表中选择后端实例；连接建立后，所有流都只会走这个实例。这正是你可以利用的特性。

二、保证连接粘性的关键配置与条件 #

• 避免客户端主动断开连接：只要客户端不主动关闭现有HTTP/2连接，所有gRPC流都会持续路由到同一个实例。
• 配置Service会话亲和性（可选但更稳妥）：如果希望即使连接断开后重新建立，客户端仍优先路由到原实例，可以给Service添加如下配置：

  apiVersion: v1
  kind: Service
  metadata:
    name: your-grpc-service
  spec:
    sessionAffinity: ClientIP
    sessionAffinityConfig:
      clientIP:
        timeoutSeconds: 3600
  

  这个配置会让同一个客户端IP的连接始终被路由到同一个后端实例，进一步强化粘性。
• 确保主实例的健康状态正常：只要主实例的就绪探针（Readiness Probe）处于正常状态，它就会一直保留在Service的可用端点列表中，客户端重新连接时（比如临时网络波动）大概率会再次选中它。

三、故障切换的逻辑 #

当主实例故障（就绪探针失败，被K8s从Service端点中移除）时，客户端的现有HTTP/2连接会断开。此时客户端发起重连请求，Service会自动将请求路由到备用实例，后续所有gRPC流都会在备用实例上处理，实现快速故障切换。

四、应用侧需要注意的点 #

• 客户端必须实现自动重连逻辑：当连接断开时，能自动触发重新连接，否则会导致请求失败。
• 处理实例切换后的状态一致性：如果你的应用依赖实例本地状态，需要提前通过共享存储、分布式缓存等方式同步状态到备用实例，否则切换后可能引发应用层面的错误。

内容的提问来源于stack exchange，提问作者dilan.sp